Home | News | Download | Packages | Forum | Wiki | Github

Installation error: failed to install grub to /dev/sda

(Masato the Empty) #22

it’s odd that you’d need to do it, but disabling legacy support would certainly rule out any issues you might get with mixing legacy and efi systems on the same disk.

There’s no boot flagging or anything like that on UEFI/GPT. You simply have the ESP which is searched by the firmware for EFI executables. mounting it to /boot/efi is so Linux tools have a path to deal with…

(Alex) #23

Disableing CSM resulted the system not getting my sandisk extreem usb3 on usb3 port.
swithing flashdrive to usb2, i could start to boot system, but very soon only black screen and after a while 2 yellow lines of error code… =/

Ok… I have never tried to manually install grub or any other boot loader… could it be an option to try to install grub manually? What info would you suggest that I read to get basic knowledge to try that approach?

(Masato the Empty) #24

Perhaps your firmware doesn’t have UEFI drivers for the USB 3 chipset.
Is this your install medium? If it’s not booting with CSM disabled, then either the firmware relies on the CSM for some functionality which should be in its core (reading MBR partitions) or the things isn’t correctly bootable in UEFI mode.

But the error you mentioned before, where grub complained about /boot/efi should suggest that it was booted in EFI mode.

There’s an easy way to check though. Go ahead and boot with CSM enabled, and once nto the installer, you can check for the existence of /sys/firmware/efi directory. If it’s there and populated, then the installer is booted in EFI. If not, then the installer is booted in compatibility mode, andthe install script won’t know what to do.

However, if that’s the case, then a targeted grub install should be possible. grub-install --help should show you a lot of useful options for installing grub to a target system. What I’m not sure of is whether os-prober will correctly pick up your installations in this environment, which means the next step (of updating the grub menu, etc) will also need some manual intervention.

EDIT: Note the installer does it from chroot, but you can ‘less /usr/bin/void-installer’ in the install environment, and find its grub commands for comparison’s sake.

EDIT2: looks like we cross posted. Go with what you have first, and we can come back to this if necessary. Will wait.

(Alex) #25

I now made Void live to boot in to DE no errors, on Disable-CSM! :grinning:

I have seen that. Checked for it several times on several boots,
was in directory tree in nemo every time ( AND populated).

Yep, My install-medium is a Sandisk Extreeme, 16GB USB3 flash.
I burned the Void ISO to it from Windows7, with a program called Win32DiskImager
When CSM-Disable first failed to boot, I remember I chose “load to RAM”.
Then I tried again just the “top option”, the default one.
Seems in this case… load to ram failed on this UEFI system.

Any how, still failed to install GRUB to /dev/sda !
Switching to tty8 ( Ctrl Alt F8 ) same as in post long above:

glibc-locales: configured successfully.
Running grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=void=grub --recheck /dev/sda…
Installing for x86_64-efi platform.
grub-install: error: failed to get canonical path of ‘/boot/efi’.

Hmm… now what?

(Alex) #26

Heeeey… I see some thing strange there…

Running grub-install --target=x86_64-efi --efi-directory=/boot/efi –bootloader-id=void=grub --recheck /dev/sda…

bootloader-id =void=grub

Should it be “=” in both places? Maybe void-grub ?

Just guessing…

(Alex) #27

I think I found some thing…

I entered lsblk in cli
sda1 was mounted on /mnt/target/boot/efi

Installer was trying /boot/efi

So, i entered this in cli:
grub-install --target=x86_64-efi --efi-directory=/mnt/target/boot/efi --bootloader-id=void=grub --recheck /dev/sda
Installing for x86_64-efi platform
Installation finished. No error repported.

Rebooted the system and this is on the screen:
Welcome to GRUB!
error: no such device: c7b1a1e8-541f-499d-a2d7-a7735609c03e.
error: unknown filesystem.
Entering rescue mode…
grub rescue>

(Masato the Empty) #28

are you sure it actually output void=grub and that wasn’t a typo? the void-installer script assigns grub_args as: “…--bootloader-id=void_grub…” - it’s hard coded.

You can always less the install script to make sure (from within less, type /grub_args= and you’ll find the line assigning it)

I haven’t figured out what that error means yet. It shows up a lot on the internet but I’m not finding a cause other than wrong commands (entered manually).

The installer unmounts the target partitions before exit, regardless of whether it succeeded or failed, so we can’t exactly see what the real state of things is when that command fails.

But what we can do is try to do that stage ourselves. Since it’s the very last thing the installer does, then we can hope everything up to that point is good, and we only have to get grub installed ourselves.

Here is what the installer should run in your case:
chroot /mnt/target grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=void=grub --recheck /dev/sda
and then
chroot /mnt/target grub-mkconfig -o /boot/grub/grub.cfg

(In your case, we’re failing on the 1st command, so it’s unknown whether the 2nd will have problems or not.)

In order to run those commands yourself, you need to get things set up again. First start with nothing else mounted other than the live-image (so don’t have any of your HDD partitions mounted.) This is based on your stated layout (with separate boot partition)

mkdir /mnt/target if it doesn’t exist.
mount /dev/sda5 /mnt/target
mount /dev/sda4 /mnt/target/boot
make sure that /mnt/target/boot/efi exists now. If not, then that would certainly have caused problems (your efi partition would not have been mounted at that location…)
mount /dev/sda1 /mnt/target/boot/efi

now, pseudo-filesystems
mount --rbind /dev /mnt/target/dev
mount --rbind /sys /mnt/target/sys
mount --rbind /proc /mnt/target/proc

Once those commands are all successful, you’re ready to try the chroot commands above. Optionally, you can chroot into /mnt/target first, and run those commands without the “chroot /mnt/target”. This will allow you do possibly do some troubleshooting from within the chroot. Such as “realpath /boot/efi” or other commands to try and see the state of things.

(Alex) #29

All your first three instrctions were executed in cli successfully.
So I doublechecked with lsblk
sda1 8:1 0 300m 0 part (no mounting point)
mount /dev/sda1 /mnt/target/boot/efi
mount: mount point /mnt/target/boot/efi does not exist

Now I am sad. (And happy, narrowing down failure.)
I remember I made that first partition more than mandatory 100mb in Installer-Fdisk
Selected type VFAT / Fat32
Wrote table to disk.

fdisk -l /dev/sda

/dev/sda1 start end sectors 300m EFI System

[EDIT 2]
void=grub was my typo. Sigh… void_grub is correct one. I guess I should edit my previous posts…?

(Masato the Empty) #30

Make it. (mkdir /mnt/target/boot/efi).

When I said make sure it existed that the implication was clear enough. Sorry about that.

(naturally, I mean make it once you’ve got /mnt/target/boot populated)

(Masato the Empty) #31

I’ve duplicated your issue, and this is the source of the problem.

For some reason I don’t yet understand, when you don’t use a separate /boot partition (it’s just a subdirectory on rootfs) you get a /boot/efi directory made. However, when you do upt /boot on a separate partition, the efi directory doesn’t get created in that partition.

I suspect that this is the answer to one or two other threads I’ve seen on this forum as well.

Make the efi directory on your /boot partition, and problem is solved (you have to install grub manually in that case, since the installer isn’t creating the directory).

I won’t recommend not using a separate boot partition, since there are good reasons one might want to do so, mostly revolving around certain encryption schemes (filesystem considerations are not a good reason unless you’re booting without an initrd).

EDIT: and now I know why; it has to do with the order in which filesystems are created and mounted, which matches the order they are entered into the void-installer config file. The script does a single for-loop in order, without considering nested mount order. But in real life, /boot needs to be mounted before creating the mount point /boot/efi, or you lose it when you subsequently mount /boot partition over /boot directory.

If you actually do them in order at the “Filesystems” stage, (first pick /, then /boot, and finally /boot/efi) then you won’t have a problem since they get put into the configuration in that order.

(Alex) #32

@masato , ok. I´ll try that tomorrow, brain wants to sleep now.
oooh… sounds like a cool hack! =) So…

creating mount pints in the installer:
@masato … you are a Jedi-wizard! :wink:

(Masato the Empty) #33

Not really. Just a fresher set of eyes, which caught a bug nobody noticed/anticipated.

Just make sure you read the EDIT in my previous post; you won’t have to do anything manual if you mind the order in which you configure your partitions. (i.e. make sure you tell it that sda4 is /boot before you tell it that sda1 is /boot/efi)

(Alex) #34

Oh, an other thing. Regarding
(and other alike combinations)

Maybe it would be a good thing if this “discovery” would be edited in say https://wiki.voidlinux.eu/Disks#Partitioning ?

(I feel that I am not confident enough in Void yet to undertake even a small edit in Void-Wiki… :neutral_face:)


Making a /boot/efi directory THEN mounting the boot partition on /boot!!! Oh where has the efi directory gone and now the entire installation fails…
I’d think that was more a case for a bug report (and hope someone knows how to fix it.) :smiling_imp:

(Masato the Empty) #36

@Alex I meant to do that, but then got thinking about splitting the notes section on the EFI page to a separate page and it just got away from me… I decided not to do that, and went ahead and added a note to the existing UEFI page on the wiki (just the one for using the installer).

@hralgmir I opened an issue a few days ago (in void-mklive). Not sure how they’ll handle it. Fixing it would require something like multiple passes over the mount point list and determining if one mount depends on another, so that they get done in order, even if you don’t assign them that way. It may be easier just to make a note (“if you do x, then be sure to do y and z last!”)

Anticipating and handling exception scenarios can be a PITA in a program/script…


That’s good, sounds like you have covered all the bases then. Finding the source of the problem is certainly an achievement in itself, and installers are not easy to deal with when it means repeatedly installing Void - not so easy to test at all. Anticipating all possible cases and responding to them all is difficult, and it has to be written as fully functioning code.