3

I have GNU/Linux (currently Fedora 26, but previously Linux Mint 18.2 Sonya) installed on an external hard drive alongside an NTFS partition I use for storage – and it boots perfectly on the computer I used to install it. However, when I try booting on a different computer with a different hard drive configuration it can't find the OS partitions and dumps me into GRUB Rescue with the error message error: unknown filesystem.

I suspect this is because GRUB searches for the partitions using labels such as hdX,msdosY (X and Y being integers seemingly corresponding to sXY labels such as sda1 with X being a letter and Y being an integer), as the menuentrys in my grub.cfg uses them when setting the root variable – assuming that grub.cfg is the source for what's put in the MBR. My /etc/default/grub does not contain GRUB_DISABLE_LINUX_UUID=true.

Could the solution to my problem be making GRUB search for the partitions using UUID – and if so: How would I go about making it do so?


EDIT: Here is the full menuentry for booting Fedora from my grub.cfg:

menuentry 'Fedora (4.11.8-300.fc26.x86_64) 26 (Twenty Six)' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-4.11.8-300.fc26.x86_64-advanced-c1bcc95a-66a8-4bd3-ae64-42be8d83137e' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd1,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd3,msdos2 --hint-efi=hd3,msdos2 --hint-baremetal=ahci3,msdos2 --hint='hd1,msdos2'  3483e8e8-38ab-4b47-aec4-1cb475c285d8
    else
      search --no-floppy --fs-uuid --set=root 3483e8e8-38ab-4b47-aec4-1cb475c285d8
    fi
    linux16 /vmlinuz-4.11.8-300.fc26.x86_64 root=UUID=c1bcc95a-66a8-4bd3-ae64-42be8d83137e ro rhgb quiet LANG=en_GB.UTF-8
    initrd16 /initramfs-4.11.8-300.fc26.x86_64.img
}

I would also prefer any solution not involving manual editing of grub.cfg as any changes made would be overwritten upon updating GRUB.


EDIT 2: After I got everything to work with GPT and Fedora 26 I decided I would switch back to Linux Mint as that was my original distro of choice. This, however, turned out not to work. After testing with several different distros (Debian, Ubuntu, CentOS and openSUSE). All RPM-based distros worked, while none of the Debain-based ones did. openSUSE provides an option to enable/disable SecureBoot support, and when it was installed with this disabled I got the same results as I did with the Debian-based distros.

This does not make any sense to me, as I can verify that at least two of the computers I tested on had SecureBoot explicitly disabled, yet I couldn't boot neither the Debain-based distros nor openSUSE without SecureBoot support.

(To clarify: the RPM distros didn't boot either before I changed my hard drive to use a GPT.)

  • My guess is you have a /boot partition on an internal disk on the computer (and grub-install was done when that partition was mounted on /boot). Go to grub shell (press c on grub menu; not rescue shell so boot it in the computer where it works for this) and run probe -u $root. Jot down the UUID and then boot to the system and list UUIDs of all filesystems with blkid (as root) or lsblk -f, and see which drive the filesystem that has the UUID from grub shell is on. – Tom Yan Aug 26 '17 at 8:30
  • The file system that has the UUID I got from GRUB Shell is on my external hard drive. – Jaxon Aug 26 '17 at 9:05
  • Does any of the computers (work or not work) has UEFI instead of BIOS? Is there a vfat EFI system partition on the external drive? – Tom Yan Aug 26 '17 at 9:10
  • Also, if you explicitly choose to boot from the external drive on the BIOS/UEFI boot menu, does the probe command give you the same UUID? – Tom Yan Aug 26 '17 at 9:12
  • @TomYan Both computers have UEFI, with support for legacy devices enabled. – Jaxon Aug 26 '17 at 9:12
1

error: unknown filesystem.

It worked on one system, not on the other, this means your grub probably does not search partitions by uuid.

I suspect this is because GRUB searches for the partitions using labels such as hd0,msdos5, as the menu entries in my grub.cfg uses them – assuming that grub.cfg is the source for what's put in the MBR. My /etc/default/grub does not contain GRUB_DISABLE_LINUX_UUID=true.

This confirms my first impression. BTW, hd0,msdos5 is NOT a lable, but a disk specification that is outdated, now ... depending on many factors, hd0 could be any drive in your system ... more so, when you switch computers.

I have the following:

linux   /boot/vmlinuz-3.16.0-4-amd64 root=UUID=<someUUID> ro  quiet nomodeset

I use nomodeset because some motherboards don't like Linux changing modes.

Check to see if the root partition has uuid and use that in grub, as mentioned above.

  • The menuentry for booting Fedora 26 already uses the UUID. I have updated my question with the full menuentry. I would also prefer a method not involving manually editing grub.cfg. – Jaxon Aug 26 '17 at 0:32
0

Thanks to @TomYan bringing EFI partitions to my attention a relatively simple solution became apparent.

First, I backed up all the data on my external hard drive before completely reformating it and making a GPT with fdisk instead of an MBR which it had previously. After doing this all that was left was to reinstall the distro in UEFI mode. It now boots perfectly on all the computers I have tried so far.


EDIT: This only solves the issue when booting RPM-based distros.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.