4

Up until yesterday, everything was working find and os-prober was successfully generating menu entries for the Arch Linux install. However today when I tried to boot into Arch, I got an error that the root file system could not be found at the UUID it was trying to use. After some tinkering I was able to get Arch to boot by manually changing the root to the actual partition "/dev/sda7" as opposed to using UUID.

I was wondering what might cause os-prober to be generating this invalid configuration just for the Arch Linux install. It does fine still for the openSUSE and Windows 7 installs. One other thing to note is that it has added "rw quiet" to the end of the boot line for Arch Linux. That is not something it previously did, and I am wondering if whatever changed that has to do with why the UUID is incorrect.

Below I will post the menu entry for Arch Linux. As you can see os-prober has the --set-root= 'some UUID' part with the correct UUID, but later on when booting linux it has -root=UUID='some other incorrect UUID'.

Just to clarify, I have Ubuntu, Arch Linux, openSUSE, and Windows 7 on this machine, but I am using Ubuntu as the main OS and allowing it to manage GRUB and its configurations. All of the operating systems are at their most up-to-date versions.

menuentry 'Arch (on /dev/sda7)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-b9522736-878c-49e3-b30d-ad65589aa1d9' {
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos7'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7 --hint-baremetal=ahci0,msdos7  b9522736-878c-49e3-b30d-ad65589aa1d9
    else
      search --no-floppy --fs-uuid --set=root b9522736-878c-49e3-b30d-ad65589aa1d9
    fi
    linux /boot/vmlinuz-linux root=UUID=ad4103fa-d940-47ca-8506-301d8071d467 rw quiet
    initrd /boot/initramfs-linux.img
}

As you can see the first two UUIDs are different from the last one. The first two are correct and the last one is wrong. If I replace the last UUID with '/dev/sda7', Then it boots without problem. I have manually edited the grub.cfg to do this, but I would like os-prober to get back to working automatically. Thanks.

migrated from askubuntu.com May 11 '14 at 6:05

This question came from our site for Ubuntu users and developers.

  • 1
    os-prober's first choice is to read another installs grub.cfg or other config type files for booting. Does grub entry in Ubuntu compare to grub entry in Arch? Or if not found may create its own. With multiple installs it sometime is just easier to turn off os-prober and copy correct entries into 40_custom. Disadvantage is that some manual maintenance may be required on updates. If you have a separate /boot then different UUIDs would be correct. – oldfred May 10 '14 at 16:37
  • 1
    Can you check which if any of those UUID corresponds to an existing drive? You should be able to see this with blkid. Also check whether the blkid output is the same on Arch and Ubuntu (I'd be very surprised if not, but check anyway, just in case). – terdon May 10 '14 at 18:11
4

Ok, so the information about how os-prober looks into different grub.cfg files for each operating system's respective /boot directory even if that OS is not the one that installed grub to the MBR/EFI is what helped me to solve this issue.

Turns out that a previous update to Arch Linux stuck a grub.cfg file in the /boot directory. With out getting too detailed I did not have the proper things installed under Arch for its grub-mkconfig to run, so instead I got some sort of a template in the grub.cfg. This was the file that os-prober was scanning, and it was the file which had the improper UUID. What I had to do was turn off os-prober under the Arch linux /etc/default/grub. Then I ran sudo grub-mkconfig -o /boot/grub/grub.cfg, that built a proper grub.cfg file for Arch which Ubuntu's os-prober now uses properly. I will be using the same technique for openSUSE.

One thing to note is that instead of allowing os-prober to generate these menu entries all on its own, instead having it pull from each OS's respective grub.cfg file allows you to have different defaults for each distribution which therefore allows for different parameters to have quiet boot with splash, or to show the entire boot process etc..

Thanks for the help guys!

  • I have the same problem. A simpler fix, which may not be as good, was to just delete file grub.cfg from the Arch system. Then, it setup Arch to boot to the device, instead of the UUID. But, it works. – Tim Jun 2 '14 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy