GRUB fails to resolve canonical path to device, uses invalid partition and fails to detect zfs #5
Comments
|
On Dec 31, 2013, at 5:48 PM, Stanislav Seletskiy wrote:
Better question still: Why is it interested in that device in the first place? The man page for grub-probe say: But for a zfs filesystem, this should be the dataset, not the/a physical device in the pool! I'm specifying the device to write to on the grub-install command line, so it shouldn't even care about PS. I got the same error with the latest grub. Ever since I started trying to use a ZFS root in April, I've been having trouble with grub (mostly grub-probe). I had to resort to a hacked grub-probe (a shell script with hardcoded values. |
Truth! I was experimenting on a single vdev configuration, where this approach to access a device can be somehow doable, but in stripped or raidz configuration this would be utterly wrong... |
|
I can confirm this is still an issue with debian wheezy which grub-mkconfig 2.01-22debian1+zfs3~wheezy Running update-grub with set -x/+x set in grub-probe and /etc/grub/00_header will show that the problem is that grub-probe runs on /dev/sda1 to probe for the filesystem. Which is "unknown" to grub-probe. Some purging and reinstalling later the error still is grub-probe: error: failed to get canonical path of udev. So no booting from a zfs pool for now. |
|
I am also experiencing the behavior of failed grub installations. Ubuntu 14.04 w/ latest (as of 2014-04-30). I am also receiving the "grub-probe: error: failed to get canonical path of 'udev'." error. |
|
i have a similar problem |
|
I use ryao's method of full disk zfs which is a bit different to your approach (will be shown later) anyway this is not an issue for me on raring (more specifically Mint 15), but the error the OP reported cropped up when testing out saucey (Mint 16). I had to use rarings zfs grub ppa as there doesn't seem to be a version specific to saucey. Anyway here's some output on the new system: On the older system grub-probe works fine: |
|
As a workaround I have udev create the required /dev/ata-* symlinks: # cat > /etc/udev/rules.d/70-zfs-grub-fix.rules << 'EOF'
KERNEL=="sd*[a-z]1|cciss*[a-z]1", ENV{DEVTYPE}=="partition", ENV{ID_SERIAL}=="?*", SYMLINK+="$env{ID_BUS}-$env{ID_SERIAL}"
EOF
# udevadm trigger |
|
This workaround doesn't achieve correction of the problem behavior for me. On Thu, May 29, 2014 at 5:38 AM, dasjoe [email protected] wrote:
|
|
The rule above did not work for me, here is a rule, which works for me |
|
14.04 broke for me at an update to kernel 3.13.0-30. Originally I had used the raring zfs-grub version, but it now had failed. After remiving zfs-grub and going back to trusty grub version (see https://groups.google.com/a/zfsonlinux.org/forum/#!topic/zfs-discuss/050qD_mvMAg). I was having problem with the incorrect /dev/..... So, thank you very much for this fix. I am back in business. |
|
recently ran into the same error when using whole devices (on rhel7) |
|
Do anyone know, is this repo even alive? It's get ignored for about an year... |
|
with gpt disks maybe using /dev/disk/by-partuuid helps ? |
|
ok, it didnt help... also when using /dev/sd* and not /dev/disk/by-id the same problems occurs. when using /dev/disk/by-id and @dasjoe 's udev rule it partly works. but fails when the udev rule is not included in the initram image. |
|
+1, I'm running into this trying a 14.04 install. |
|
So for conclusion:
This seems to be true for upstream grub as well. Latest version as of now is |
|
Yeah, it's quite a strange situation, because the GRUB scripts do detect the root is a zfs one by falling back to Also, after manually creating symlinks in /dev as the others pointed out, I still get a failed zfs detection. I don't have complete logs right now (I will post them later), but I suspect that, like some folk in the Arch Linux forum figured out, GRUB's ZFS support is missing features (upstream bug). |
|
I just realized why my workaround doesn't work sometimes, it assumes ZFS is using whole disks and not partitions, # cat > /etc/udev/rules.d/70-zfs-grub-fix.rules << 'EOF'
ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*", ENV{ID_FS_TYPE}=="zfs_member", SYMLINK+="$env{ID_BUS}-$env{ID_SERIAL} $env{ID_BUS}-$env{ID_SERIAL}-part%n"
EOF
# udevadm triggerIt should break when a disk's multiple partitions are used in zpools and you don't boot off the last (queried) zpool, as udev would overwrite |
|
GRUB is actually using GRUB actually does already have logic to look for a device in |
(EDIT) Yes they do [print the name relative to /dev]. |
|
|
The last comment from @danielkza fixed the issue for me. |
|
Did you patch GRUB yourself? I resorted to using the GRUB and zfs-initramfs versions from Wheezy on Trusty. So far they seem to work alright, |
|
Sorry.... I meant @dasjoe. The udev rule worked for me. I just applied manually and will watch every upgrade like a hawk. |
|
The udev rule should work if you don't have a new enough pool: otherwise, even if you fix GRUB looking at the wrong device, it'd probably fail when checking the contained filesystem due to missing some disk format features as I mentioned before. |
|
I ran into this after upgrading from 12.04 to 14.04. A bit of a nasty shock. Adding symbolic links got But, based on the information here I was able to get it to work with the help of the following short perl script: #!/usr/bin/perl
my $ipch;
my $cpid = open $ipch, '-|';
if( $cpid ) {
while( my $line = <$ipch> ) {
$line =~ s{^(\s+)((scsi|ata|wwn)-.*)}{$1disk/by-id/$2};
print $line;
}
}
elsif( $cpid == 0 ) {
exec { '/sbin/zpool_true' } 'zpool', @ARGV;
}
else {
die;
}I moved the original |
|
Just in case someone is using WWNs instead of scsi-xxx, this udev rules does it for me: ENV{DEVTYPE}=="partition", IMPORT{parent}="ID_*", ENV{ID_FS_TYPE}=="zfs_member", SYMLINK+="wwn-$env{ID_WWN_WITH_EXTENSION}-part%n" |
|
It's nice that people is posting workarounds, but it would be nice if someone could take some time to look at the code of grub and see if they could find a way to fix this once and for all... I'm unfortunately very short on time (and the fact that it doesn't happen to me probably isn't helping :). I just have to many more important issues to deal with to look at this any closer. I spend almost a weekend a couple of weeks ago, but didn't get any closer to this. @danielkza have some ideas on this (see #5 (comment)), it just needs to be taken to the next step... |
|
Even writing a patch for GRUB would only fix half the problem: if you create a new pool with ZFS 0.6.3 you will hit another one. The right action would be to build a version of the ZoL GRUB version for Ubuntu Trusty too: right now upstream is not good enough. |
If/when we get it working correctly, we could update the ZoL grub while we wait for upstream to catch up. That's what we've been doing in the past. But that took quite a while to get accepted, because the changes was quite extensive. If we could get a very small patch working (and from your description it should be quite a small patch), it will probably/most likely (?) be accepted quite quickly - the smaller the patch and the smaller the [probable] impact on other architectures , the more likely it is to get accepted. This is usually true in any OpenSource project. I don't expect Grub to be different. Although, it's @dajhorn who've had the most contact with them from the ZoL project... My Debian GNU/Linux Wheezy ZoL grub is apparently to old, but there's little point in upgrading it, because there's to many merge issues to fix (a lot of the extra patches we've added/used is now accepted into upstream - but not all). Better to start with a clean upstream and then add the patch/patches that fixes it the way we want it fixed. |
|
There is another issue which seems related to GRUB missing some pool features. Even if it can successfully detect the correct devices to probe, it may not detect ZFS on them: http://savannah.gnu.org/bugs/?42861 I agree that writing the patches and hoping they get upstream would be the ideal situation, but right now ZFS root is completely broken on Trusty without those workarounds, and possibly even then. The only solution I have found is using the Debian GRUB packages instead. And I have no idea how long the GRUB folks would take to get the fixes in. |
If this is perfectly ok with everyone, by all means. Continue with the workarounds. If you're not interested in getting a package that actually works, then who am I to argue - I have other things to do anyway... |
|
I don't have any particular knowledge of the GRUB code, nor much free time to work on the issue either. It does seem quite simple to fix though, so I'll see what I can do about it, but I can't commit to any time frame. |
|
Don't know if this is helpful or not but current grub for trusty (not On 08/25/14 16:09, Turbo Fredriksson wrote:
|
Yes, that's the whole point. That's a workaround, which I think is very ugly! The ... idea/hope is that we could get it fixed properly so none of that crap is needed... |
|
I don't see a problem with upstream - for me enabling libzfs did the trick |
|
libzfs will never be enabled by default in any distribution, linked statically or not. And it shouldn't really be necessary, since GRUB went all the way to do their own support. If using the default distribution packages is a goal all the small bugs need to be fixed. |
|
|
I somehow feel guilty for starting some kind of argument here, but I'm missing something. |
|
There is no guarantee, by any of the ZFS implementations, about how device names will appear in Considering there is even code to traverse the |
Good idea. We have machine parseable output in other places, but not "status". I have a script where I could really have needed it. Instead, I had to write 146 lines of bash code to make sure I caught all possibilities... I've created openzfs/zfs#2626 where this can be discussed. I'm volunteering to do it even :).
It's also the correct UNIX way - "do not assume" (my favorite quote is something like "If need is the mother of invention(s), then assumptions is the father of all fuckups" :). |
|
@buc0 mooving the original /sbin/zpool to /sbin/zpool_true and then creating a script as /sbin/zpool is quite danger as the next update-initramfs will include the zpool script into initramdisk instead of the original zpool binary and you wont be able to import any pool while in initram. I guess you can alter the /usr/share/initramfs-tools/scripts/zfs to reflect it. |
|
As of today, this bug has manifested in Debian Jessie. |
|
Same here. gdisk -l /dev/sdaGPT fdisk (gdisk) version 0.8.10 Partition table scan: Found valid GPT with protective MBR; using GPT. Number Start (sector) End (sector) Size Code Name zpool listNAME SIZE ALLOC FREE CAP DEDUP HEALTH ALTROOT zfs listNAME USED AVAIL REFER MOUNTPOINT I get the same "canonical path" error into the chroot (details below)... /dev/sda1 (ext4) /boot |
|
I think I am running into this on Ubuntu 16.04.1. I have a ZFS root on an LVM volume, and grub-probe is not finding it. zpool status gives the pool device as Creating a symlink from |
|
For what it's worth, I get a similar behavior on Debian Jessie (installed roughly according to the guide, but with LUKS encrypted root) if I use the I thought at first that I wouldn't need the newer grub version from The versions were like this: With grub-pc from jessie-backports grub-probe is broken: The first problem is that it looks for the devices in the wrong place. Symlinking them causes another After upgrading to grub-pc from Debian The command used by /etc/grub.d/10_linux to find out the pool name for the root also started working when upgrading to grub from -edit-: here is what the partitioning looks like: I boot using the BIOS method with GPT partitioning, but have prepared the efi partitions for future use (unformatted). I'm testing this in VirtualBox as a candidate for a home server install. /boot is on ext4 on mdadm RAID1 on the boot-{a,b} partitions. mdadm and cryptsetup: fstab: |
|
I too had this problem on Ubuntu 16.04.2 LTS, when trying to create a bootable USB using grub-install manually. I worked around it by creating the symlinks in /dev/ +1 for #2626 |
|
FWIW I had a similar problem on latest Ubuntu 16.04, when chrooting into a zfs root (to clone a running system to use zfs on root) and symlinks helped as well. |
|
This answer on askubuntu explains the problem (and the solution) very well. In my case, the symlink trick resulted in a unbootable system. The following fix works for me:
This causes zpool status to output full device paths instead of shortened names. This is what grub uses to determine where to find the block-devices. |
|
Is it possible to add |
|
@Rovanion have you tried adding it to something like /etc/environment or /etc/profile? |
|
Adding it to |
Not setting this results in the output of 'zpool status' being misparsed. See zfsonlinux/grub#5 Closes: #14801 [via git-merge-pr]
|
I'm planning to move my system to ZFS and wonder if all this workarounds are still needed for grub 2.0.6rc1? |
and others
Let's suppose following scenario:
I've want to create zpool that use entire device
/dev/sda:I'm using by-id path to disk while creating zpool:
zrootis mounted into/zroot.So, trying to grub-probe:
Wut? So, GRUB detected that
/zrootis a ZFS (otherwise, how did it know about ata-QEMU stuff?), but if fails to resolve correct path to device.OK, let's try to fix it in a dirty way:
Didn't work. Hmmm... Looks like grub-probe tries to read from
/dev/sda.Take a look:
Indeed!
After that series of hacks I can do
grub-installand it finishes successfully.So, my suggestion is that GRUB uses incorrect device path when zpool is created over entire device.
The text was updated successfully, but these errors were encountered: