Grub rootfs

[gpotter2]

Hey, I really though that error would have been reported somewhere but i can't find a dupplicate... (maybe i'm just blind ?)

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [version 10.0.16176]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

sudo apt-get install linux-generic

In tons of cases, during installation processes, the error:
grub-probe error failed to get canonical path of rootfs
appears, especially during linux core upgrades.

Stack trace:

Setting up linux-image-4.4.0-70-generic (4.4.0-70.91) ...
Running depmod.
update-initramfs: deferring update (hook will be called later)
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.0-70-generic /boot/vmlinuz-4.4.0-70-generic
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.0-70-generic /boot/vmlinuz-4.4.0-70-generic
update-initramfs: Generating /boot/initrd.img-4.4.0-70-generic
run-parts: executing /etc/kernel/postinst.d/unattended-upgrades 4.4.0-70-generic /boot/vmlinuz-4.4.0-70-generic
run-parts: executing /etc/kernel/postinst.d/update-notifier 4.4.0-70-generic /boot/vmlinuz-4.4.0-70-generic
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 4.4.0-70-generic /boot/vmlinuz-4.4.0-70-generic
/usr/sbin/grub-probe : error : failed to get canonical path of « rootfs ».
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-4.4.0-70-generic.postinst line 1052.
dpkg: error processing package linux-image-4.4.0-70-generic (--configure) :
 subprocess installed post-installation script returned error exit status 2

That simply makes the install fail.

[fpqc]

Grub is not going to work bc there isnt any raw device support atm.

[aseering]

Relatedly, grub doesn't need to work, because WSL doesn't actually boot :-)

It would be nice if package installations didn't fail as a result of this.

[gpotter2]

@aseering Yes it would :)

[linlinchn]

WSL doesnot actually boot，may be you can just uninstall grub to avoid these errors.

[therealkenc]

Setting up linux-image-4.4.0-70-generic (4.4.0-70.91) ...

I am not sure how linux-image-4.4.0-70-generic is getting into the apt database here in the first place. AFAIK that package does not come down with the stock WSL userspace tree. If you do an sudo apt-get purge linux-image* what, if anything, complains?

That question notwithstanding, an strace is still valuable here (as always). Even though grub sure ain't going to fly, that error message "failed to get canonical path of rootfs" looks like something WSL should (for some value of should) be able to do. A few filesystemy packages expect libblkid-dev to behave. See for example #1492. And if had to bet, one of those packages is eventually going to be systemd or one if its many dependents (because, systemd). It would go a long way if some of the block device surface were stubbed enough to make such packages blissfully unaware we don't actually have any working block devices.

[josephby]

Is there a workaround for the "failed to get canonical path of rootfs" error?

[lsytj0413]

@josephby
I have the same issue, my solution is remove the grub-pc package with command:

sudo apt -f remove grub-pc

[SpencerMKSmith]

@lsytj0413 That worked for me, thanks!

[therealkenc]

This issue tracker is sort of by-design, because grub is just n/a on WSL. That said, the user experience for installing packages (mostly package dependencies) that think they need grub-probe should probably be improved. That is, stubbed enough to make grub-probe happy, even if it doesn't do anything. Closing for now, but if one was really motivated a new issue along the lines of "stub grub-probe's system surface" or something like that might make sense.

[therealkenc]

Would it not be possible to make grub, systemd, and others like they normally would on Linux

grub, no, because WSL has no block devices by design. Indeed, I suspect this is behaving exactly like it would on Real Linux without a rootfs block device. systemd is unrelated to this issue (grub-probe error failed to get canonical path of rootfs). The shutdown ask is #2533, and is also unrelated.

[jon2180]

@josephby
I have the same issue, my solution is remove the grub-pc package with command:

sudo apt -f remove grub-pc

i have run this command, but not working.

Setting up friendly-recovery (0.2.31ubuntu1) ...
/usr/sbin/grub-probe: error: failed to get canonical path of `rootfs'.
dpkg: error processing package friendly-recovery (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 friendly-recovery
E: Sub-process /usr/bin/dpkg returned an error code (1)

how could i solve

[zags]

@jon-zhang I also got the error failed to get canonical path of rootfs'when runningsudo apt -f remove grub-pc`. I was able to fix it with the following:

sudo apt-get purge grub-pc

[disrvptor]

@josephby
I have the same issue, my solution is remove the grub-pc package with command:

sudo apt -f remove grub-pc

i have run this command, but not working.

Setting up friendly-recovery (0.2.31ubuntu1) ...
/usr/sbin/grub-probe: error: failed to get canonical path of `rootfs'.
dpkg: error processing package friendly-recovery (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 friendly-recovery
E: Sub-process /usr/bin/dpkg returned an error code (1)

how could i solve

I ended up using dpkg to remove grub-pc then apt could continue with normal operations.

sudo dpkg --force-all --purge grub-pc
sudo apt remove --purge grub-pc
sudo apt autoremove

[gpotter2]

Most likely solved by WSL2

[BClev]

@gpotter2 I'm running Ubuntu 20.04 on WSL2 and receiving a similar issue (albeit I migrated it from WSL1). Not re-opening, just noting. Will try removing grub-pc.

[therealkenc]

Most likely solved by WSL2

Any missing kernel syscall surface is now there. There's a block device (/dev/sda). But there is still no GRUB (the thing that lives in the boot sector) on WSL2 either. Ubuntu/Debian makes the (perfectly reasonable) assumption that they are shipping the kernel, but in WSL2 (and also Docker, LXC, etc) that isn't the case.

Someone super motivated could look at the exact details of the fail in the postinstall script and make the script (and possibly grub-probe etc) more container friendly for users do end up with grub-pc installed. Make the install succeed, but not do anything (ie skip the non-applicable parts).