[SOLVED] Debian's GRUB doesn't get along with other distro's

[p.H]

If grub-mkconfig were to set Manjaro's GRUB as the default in the machine it would work, but it didn't

Of course not. This is not the purpose of grub-mkconfig. Its only purpose is to generate a config file for the GRUB instance installed by the distribution it is run on.

Whatever command the Debian updates ran it was not grub-install

Yes it is. Only grub-install (NOT grub-mkconfig) can install a GRUB bootloader and overwrite the boot loader previously installed in the same location.

bootinfoscript is broken.

At least the version available in Debian stable does not handle properly current versions of GRUB 2.x. But I have seen reports from bootinfoscript (I don't remember which version, but it was newer than Debian's) which contain the correct information about the /boot location.

Another way to get the info is hit 'c' at the grub menu, then type 'set' and look for 'prefix' and that should? tell you what partition the core.img is looking for

But it is far from showing as much information as bootinfoscript. I was specifically looking for Manjaro's and Debian's grub.cfg to try to understand what is wrong.
Manjaro's grub.cfg contains the following initrd line :

Code: Select all

initrd   /boot/intel-ucode.img /boot/initramfs-4.14-x86_64.img

It is the first time I see two arguments in an initrd command. GRUB documentation mentions only one argument. It seems that Debian's update-grub/grub-mkconfig cannot handle it properly and the line in Debian's grub.cfg becomes :

Code: Select all

initrd /boot/intel-ucode.img

The second argument, which is the initramfs in charge of mounting the root filesystem, is missing.

I guess I will run Manjaro in a live session, mount the drive where it is installed and do something like in Arch (I imagine there is an equivalent to arch-chroot and run grub-install

You do not have to run Manjaro or chroot anything. You can run grub-install with --boot-directory to specify the /boot location.

how the heck do you remove Debian's GRUB? All of you have said that as if it were a matter of running

Code: Select all

sudo apt-get autoremove grub

Your request "remove Debian's GRUB" was ambiguous. I first thought you meant to erase the GRUB boot loader installed by Debian's grub-install. Just installing Manjaro's GRUB in the same location does this. But I understand now that you want to uninstall grub* packages. All you need to do to prevent Debian updates from overwriting the installed boot loader is to remove the package grub-pc. Note that is will also remove scripts which automatically update Debian's grub.cfg when a kernel is installed or removed (which Manjaro's grub-mkconfig relies upon to add proper menu entries for Debian in Manjaro's grub.cfg).

Code: Select all

apt-get remove grub-pc

If I were you I would keep other grub-* packages. They can be useful.

[bw123]

...
Manjaro's grub.cfg contains the following initrd line :

Code: Select all
initrd /boot/intel-ucode.img /boot/initramfs-4.14-x86_64.img


It is the first time I see two arguments in an initrd command.
...

ah... I seem to recall that some people are using this to preload the ucode for the spectre/meltdown issues. I think HoAS wrote something on the board here about it. So that means debian will need an entry in 40_custom to boot manjaro correctly?

[quote=""p.H"]
...If I were you I would keep other grub-* packages. They can be useful.
[/quote]

Yes, you're right again. I should not recommend this to new users, because without the other pkgs os-prober from other distro will not find and create the debian entry? I use custom entry on debian without os-prober to boot /vmlinuz with /initrd.img to keep things very simple.

On the bootinfoscript, I tried it and got the same results. Looked around a little and the issue seems pretty old, there's a dead fourm here https://sourceforge.net/p/bootinfoscrip ... on/905692/

I looked at the script, and found the right section, but wihtout the right offsets for the core.img I didn't even try to fix it. Maybe someone could fix that up, it's a pretty useful tool.

[p.H]

So that means debian will need an entry in 40_custom to boot manjaro correctly?

I'm afraid so. The custom menu entry could contain a simple 'configfile' command loading Manjaro's grub.cfg, provided that Debian's GRUB handles correctly the initrd syntax with two arguments. Otherwise, use the 'chainloader' command to load Manjaro's GRUB.

without the other pkgs os-prober from other distro will not find and create the debian entry?

os-prober itself does not care about other GRUB installations. grub-mkconfig/update-grub only uses os-prober to find other GNU/Linux installations. Then if grub.cfg is present in a found installation, it relies on its contents to build the menu entries for that installation. It does not rely on GRUB packages and utilities to be present on the other installation.

grub-pc (as any other grub-$ARCH package) provides hook scripts which automatically update grub.cfg when a packaged kernel image is installed or removed :
/etc/kernel/postrm.d/zz-update-grub
/etc/kernel/postinst.d/zz-update-grub

The other grub* packages only contain what is needed to run grub-install and update-grub/grub-mkconfig manually.

If you remove grub-pc, grub.cfg won't be automatically updated any more, so update-grub run from another system may rely on an outdated grub.cfg to build menu entries. To avoid this you need to run update-grub manually after kernel changes, or reinstall the hook scripts by hand. They are quite simple.

IIRC, there is another alternative : run

Code: Select all

dpkg-reconfigure grub-pc

and leave the boot device field empty, so that grub-pc package updates won't reinstall the GRUB boot loader. This works only with grub-pc for BIOS/legacy systems, not with grub-efi* for EFI systems because it does not use a boot device.

[Isakku]

You may have different pkgs because different versions are for different hardware. Aptitude is good at things like this. If there is another grub installed and configured correctly from another linux installation then this should be safe. BE SURE AND READ AND ANSWER QUESTIONS CORRECTLY. DON'T JUST HIT YES. iT UNINSTALLED FINE ON KDE PLASMA, BUT I GUESS SOME DESKTOPS MIGHT DEPEND ON GRUB? Be careful.

Maybe I made some mistakes such as assuming that a tutorial that says that "it is simply the latest installed GRUB the one which is in control" is the entire reality when it turns out to be much more complex. Complex specially when I'm also dealing with installing at least 4 distros in the same hardware, wouldn't you agree?

If you choose 'grub' then it will probably uninstall grub-legacy, not grub2. Nobody on here knows how you have things setup. This is not necessary to keep debian's grub from messing you up, but maybe it will get you to mark the thread solved?

*SIGH* OK, maybe. I will try that later.

Debian or manjaro or any other distro does not decide to do anything, you do. You are the one that runs commands, you answer questions from the os. It's your computer, get it under control.

Really? Don't tell me automated scripts don't do things according to their pre configured programming. Discover NEVER asked me if I wanted to make changes to GRUB. All it did was show a bunch of updates, so I clicked the "update" button, and all it asked for was for Root's password, nothing else.

If grub-mkconfig were to set Manjaro's GRUB as the default in the machine it would work, but it didn't

Of course not. This is not the purpose of grub-mkconfig. Its only purpose is to generate a config file for the GRUB instance installed by the distribution it is run on.

Whatever command the Debian updates ran it was not grub-install

Yes it is. Only grub-install (NOT grub-mkconfig) can install a GRUB bootloader and overwrite the boot loader previously installed in the same location.

Whatever command was run when running the updates, by that logic it should have been grub-install. Then, why run grub-install if it's merely some packages being updated? It's beyond me right now. The list that Discover showed didn't seem to be anything else but updates for many things, nothing else.

how the heck do you remove Debian's GRUB? All of you have said that as if it were a matter of running

Code: Select all

sudo apt-get autoremove grub

Your request "remove Debian's GRUB" was ambiguous. I first thought you meant to erase the GRUB boot loader installed by Debian's grub-install. Just installing Manjaro's GRUB in the same location does this. But I understand now that you want to uninstall grub* packages. All you need to do to prevent Debian updates from overwriting the installed boot loader is to remove the package grub-pc. Note that is will also remove scripts which automatically update Debian's grub.cfg when a kernel is installed or removed (which Manjaro's grub-mkconfig relies upon to add proper menu entries for Debian in Manjaro's grub.cfg).

Code: Select all

apt-get remove grub-pc

If I were you I would keep other grub-* packages. They can be useful.

Yeah, I didn't realize it. Ambiguous indeed it was, because turns out I understand now GRUB is at least two things in a machine:

1) The program and it's configuration usually stored in the system in folders such as /boot/
2) The actual GRUB boot loader stored in the MBR or EFI partition.

It was quite confusing at first, now I think I get it.<

I have run some tests in a virtual machine. I indeed got the "install GRUB" menu, opted it out and installed Manjaro later. It seems to be working just fine, Manjaro boots OK, but for some reason Debian boots to a black empty desktop. I can switch to tty, login and issue a startx command, with the exact same result. Maybe a bug with Virtualbox (yeah, I'm on 5.2.10 I have to update)

EDIT.
OK.
I booted Manjaro and ran

Code: Select all

# sudo grub-install /dev/sda
# sudo grub-install --recheck /dev/sda

as suggested here.
https://howtoubuntu.org/how-to-repair-r ... tu-live-cd

Then I rebooted, GRUB finally showed up the way I had configured it with Manjaro. Manjaro boots fine. Then I rebooted into Arch, it boots fine as well. Finally I rebooted into Debian.
The first thing I did was run

Code: Select all

# sudo apt-get remove grub-pc

I hope with that it will never bother to install itself without saying anything again anymore.
I rebooted Debian. Everything seemed fine. I updated the system, (Discover showed new updates in the panel, so I simply opened it and clicked on Update, and just like before all it did was ask for root's password)
After updates finished, I rebooted. Everything is still fine! OK, I guess this machine won't give more trouble. I think it is safe to add Antergos to this machine. I can delete my testing virtual machine as well. I guess I can set this as solved. I'm changing the thread's title adding a [solved] mark.
Thanks a lot for everything!

[milomak]

i would say the best thing for you to do is to install the debian grub to the specific partition (eg /dev/sda1 - but of course to the one that has debian)

then in your manjoro grub create a custom point to the debian grub

[p.H]

Then, why run grub-install if it's merely some packages being updated?

grub-install is run during grub-* package updates to upgrade the actual GRUB boot loader in order to :
- apply security or bug fixes provided by the new version to the actual GRUB boot loader ;
- keep the boot loader part in sync with the new system programs ; if update-grub/grub-mkconfig generates a grub.cfg file using a new syntax, then the actual GRUB boot loader must be upgraded to understand it.

I understand now GRUB is at least two things in a machine:

1) The program and it's configuration usually stored in the system in folders such as /boot/
2) The actual GRUB boot loader stored in the MBR or EFI partition.

Actually the contents of /boot/grub is also part of the actual GRUB boot loader.

[p.H]

i would say the best thing for you to do is to install the debian grub to the specific partition (eg /dev/sda1 - but of course to the one that has debian)

GRUB does not support installing the boot image on all partition types. Also it may need to rely on block lists to access the file containing the core image, which is less reliable.

ext* : supported but must use block lists
btrfs : supported and does not need block lists
LVM : not (yet) supported