grub-probe error: unknown filesystem #19
Comments
|
|
To duplicate the issue: Install Jessie in VirtualBox (tested in RAID 10) EFI will already be install by select the option in Debian Jessie, cat > /etc/udev/rules.d/70-zfs-grub-fix.rules << 'EOF' reboot Since "/" is not on zfs at boot time, would it matter if it is efi? |
|
Yes you are right. I was running a quick test with grub-probe and only one folder. It should have been
With the current Debian version of grub-efi-amd64 I can confirm success with the zfs non-daily. I think more people are having success these days, but there isn't a clear document on the web outlining each step of the process to achieve the goal. To be fair to yourself, in the past it was a lot more difficult and they were many more bugs to work through that perhaps made it impossible/impractical in many situations. A lot of progress has been made that perhaps now allows for a different perspective other than the horizon approach where the goal is still out of reach. On a more tangible note, my next comment may have some clues at to why this issue is occurring. |
|
I created a pool with only one dataset mounted:
I then use grub probe's verbose output (version: 2.02~beta2-10)
For both the, They are some difference between the two outputs that I hope will help to sort out the current issue. What stood out to me is that at an initial level grub-probe detects zfs on the dailies before there seems to be a failure: _Is there a mismatch in the order or sequence of features (between the dailies and non-daily) that is causing grub-probe to fail?_
Full Output of Dailies v0.6.3-24
|
Could you edit that post, and use the 'triple back ticks markdown' to distinguish the code segments. The post is very long and very difficult to read/overview as it is now. See https://help.github.com/articles/github-flavored-markdown/#syntax-highlighting |
|
I believe I have the same issue. I have been running a ZFS root installation with Debian Jessie for months with no issue. Then, I installed the nightly builds, and now I am unable to upgrade the kernel. I receive the following error: dpkg: error processing package linux-image-3.16.0-4-amd64 (--configure):
subprocess installed post-installation script returned error exit status 2
Setting up grub-efi-amd64 (2.02~beta2-20) ...
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?). |
|
@FransUrbo I couple days again, I created bug reports with Debian as I had mentioned I would.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776676 This also addresses: Debian Bug 777191 requests that they look into applying the following patches to upstream grub-efi-amd64: LIST OF PATCHES: blacklist_1440x900x32.patch
core_in_fs.patch
default_grub_d.patch
disable_floppies.patch
dpkg_version_comparison.patch
elf_bi_endian.patch
feature_flags.patch
first_device.patch
fix_variable_redeclarations.patch
gettext_quiet.patch
gfxpayload_dynamic.patch
gfxpayload_keep_default.patch
grub-shell-no-pad.patch
grub-tester-zfs.patch
grub.cfg_400.patch
grub_legacy_0_based_partitions.patch
ignore_grub_func_test_failures.patch
install_efi_fallback.patch
install_locale_langpack.patch
install_powerpc_machtypes.patch
install_stage2_confusion.patch
linuxefi.patch
linuxefi_amd64_only.patch
linuxefi_debug.patch
linuxefi_non_sb_fallback.patch
linuxefi_require_shim.patch
maybe_quiet.patch
mkconfig_loopback.patch
mkconfig_mid_upgrade.patch
mkconfig_nonexistent_loopback.patch
mkconfig_recovery_title.patch
mkconfig_signed_kernel.patch
mkconfig_ubuntu_distributor.patch
mkconfig_ubuntu_recovery.patch
multiple-raidz-device-detection.txt
no_insmod_on_sb.patch
no_redefine_MIN-MAX.patch
probe_fusionio.patch
quick_boot.patch
restore_mkdevicemap.patch
series * Add support for spacemap_histogram, enabled_txg, extensible_dataset.
skip_gettext_strings_test.patch
sleep_shift.patch
uefi_firmware_setup.patch
vt_handoff.patch
wubi_no_windows.patch
|
|
See Debian Bug#775395 - partman-zfs in d-i jessie image does not create grub-compatible /boot ZFS mirror Workaround:
|
|
@toobuntu I was able to install with no issues using, ZoL version
Even had Pool was created with,
The same success was not achieved with the ZoL dailies version where I simplified pool creation to
I have not tested with the
I agree there is an issue with grub, but there seems to be more to it? as i got it working with LZ4 and the non-daily ZoL code.
I would rather a fix be implemented so grub2 and ZoL can work with all the features. I certainly don't want to lose out on LZ4. Thanks for pointing out your findings. I will link it to my Debian Bug Report. |
|
A recent upgrade caused an unsuccessful boot. I chrooted into my system and I upgraded to a grub version from the experimental branch. Within the chroot, initramfs completed successfully. I then tried to boot again but I was stalled in busybox. I use the following commands to continue: zpool import rpool -R /root
exit
exitThe first exit returns an error the original error but the second proceeds to boot successfully. I can now update initramfs within my install, but still get stuck in busybox. This is my /etc/default/grub file: # If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n 'Simple configuration'
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash init=/bin/systemd"
GRUB_CMDLINE_LINUX="boot=zfs rpool=rpool rcutree.rcu_idle_gp_delay=1"
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1600x900
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1" |
This sounds like a problem with the initrd script, not grub. |
|
So... is this the right place to ask when com.delphix:hole_birth will be supported by grub? |
Regarding 'all other' distributions, somewhere between 'in a year or two' to 'never'… The 'problem' is that no-one (except me) is willing to carry the patch(es) that @tsoome did for Illumos. They're CDDL and Grub2 is GPL and they 'clash'. Or at least that's the general opinion. I'm not a lawyer, so I can't say for sure but there you are… @tsoome is currently in the process of rewriting the patch(es) and pushing it to Grub upstream. But your guess is as good as mine when that will be accepted. Until then, no-one is willing to do the work. |
|
check out the upstream git on savannah;) only one missing at the moment is extensible dataset feature, its posted but they are probably still testing it, poke grub-devel’s. rgds,
|
|
Thanks for your fast response! # wget http://ftp.de.debian.org/debian/pool/main/g/grub2/grub-common_2.02~beta2-22_amd64.deb
# dpkg-deb --extract grub-common_2.02~beta2-22_amd64.deb /tmp/
# /tmp/usr/sbin/grub-probe /zfs
/tmp/usr/sbin/grub-probe: error: unknown filesystem.
# /tmp/usr/sbin/grub-probe -vvv /zfs 2>&1 | grep birth
grub-core/fs/zfs/zfs.c:1123: str=com.delphix:hole_birth
grub-core/fs/zfs/zfs.c:1126: feature missing in check_pool_label:com.delphix:hole_birth
grub-core/fs/zfs/zfs.c:1123: str=com.delphix:hole_birth
grub-core/fs/zfs/zfs.c:1126: feature missing in check_pool_label:com.delphix:hole_birthSame effect. Any further hint for me? |
I said I did, not that Debian GNU/Linux did :). In my Debian GNU/Linux for ZoL repositories, I have 2.02-beta2.9-ZOL11-7aa9f6-wheezy (and 2.02-beta2.9-ZOL11-7aa9f6 for Jessie) which supports all new features of ZoL. |
|
Ahhh... stupid me! Reading the content is better than just reading the letters ;-). |
|
also note, the upstream grub did apply the commits just few days ago (and as I wrote, it is still missing the extensible dataset one, which is needed for large_block support), so the distro maintainers probably haven’t picked them up yet. rgds,
|
|
To build the savannah clone was a good hint! # git clone git://git.savannah.gnu.org/grub.gitI build it from source (yes, I should have packaged it...) and installed it over my grub isntallation... quick and dirty. Then I did grub-install and now I am online again with my Linux on ZFS! |
|
Just want to chime in again; I no longer have any issues with grub and I'm off daily builds and back to the latest release. |
|
I was stuck on this for 2 days but finally managed to be able to boot into ubuntu 14.04 again, instead of getting stuck in initramfs or something else I updated/enabled com.delphix:hole_birth and 2.02~beta2-9ubuntu1.7 was no longer able to detect zfs with grub-probe I ended up building grub from git://git.savannah.gnu.org/grub.git but I ended up getting stuck in initramfs I edited my new grub.cfg by hand and modified the linux lines (since I don't really know what I'm doing) to use my original grub.cfg and I was able to boot without issue not working git grub.cfg original grub cfg: hope this saves someone from a headache |
|
There you see 2 different issues - one is about old grub in ubuntu not recognizing zfs features, and second one is how (new) grub is generating configuration entry for grub menu. If ubuntu is needing specific parameters for initramfs, you can not just replace grub in place, but need to bring over the configuration generation scripts tailored for the needs of ubuntu. I’d suggest to poke ubuntu devs to update grub in their base - those zfs updates have been in grub for quite some time. rgds,
|
|
Problem persist on Ubuntu 16.04 with all the latest update from official repo as well. It works initially when booting up the server, few days later i got this. grub-probe / |
|
I'm now running into something similar on gentoo, ZFS 0.6.5.8, with both grub git HEAD and grub-2.02_beta3-r1 This didn't use to happen, even on the same system. I'm wondering if a recently activated feature on my pool could be causing this. If it helps: |
|
It is my understanding that grub doesn't support feature@large_blocks, however that shouldn't cause this error, but something along the lines of "error: filesystem 'zfs' doesn't support blocklists." (I could be wrong on this) However, is this system gentoo? If you get "unknown filesystem" it might be possible that you didn't enable the libzfs use flag. I would possibly recommend making a new bug since this one is quite old, and also from a debian/ubuntu system. |
|
libzfs is enabled. It really is a used to work / doesn't work anymore situation without any change in grub itself. That's why my logical interpretation was that an active feature flag may be getting in the way of grub's FS recognition. The pool has evolved. The software? Not so much |
|
To be clearer maybe: I only started playing with reinstalling various versions of the grub code after the problem became appearant. |
|
Relevant output of grub-probe: |
|
I'm seeing this problem on debian 8. update-grub creates unbootable zfs entries. |
|
you can add -d -or -v to add more verbosity for grub-probe (I can't remember which switch it was;) - so you can get very detailed output to see which feature is missed from your grub. From presented feature list it seems you just do have too old grub, as all listed features should be supported by grub HEAD over an year now... |
|
this version of grub-probe is the latest in debian jessie. |
|
this log is telling "grub-core/fs/zfs/zfs.c:5374: zfs_mount failed: missing devices", you need to present on command line at least minimum amount of devices depending on pool layout, for mirror its 1 disk, for 2+1 raidz, its 2 disks etc. for hint, either grub-probe or grub-testfs did need the -c X to tell it how many disk devices are you providing (again sorry, its some time since I did use grub2;) |
|
I'm just using the command that is executed by |
|
yes it should; also I only now noticed you have posted the pool layout - you have raidz from 5 disks, so you need to provide at least 4 (better all 5), grub-probe is basically user space file system reader, but it will need devices specified on command line, it wont pick them by itself. Thats easy to test anyhow. |
|
indeed. also, which means the following line in ...along with all the logic that assumes a single device... is obviously broken. |
|
yap, well, at least thats simple to fix and would be good to notify debian devs as well:) |
|
looks like they've known about this for over 7 years now... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540786 |
|
Ran into the same issue with current xenial: All info from inside chrooted installer |
|
Yea, and the diagnostics is all the same use --target=device and verbose/debug options if this is not enough. And if this is the same issue, bug your vendor till they fix it... |
|
Ok, not bothering this one ...for the record: openzfs/zfs#5448 |
|
I'm having the same (or similar) problem. Where for a striped pool (no mirrors, no raidz) with as only enabled feature lz4 compression Unfortunately for me this is more problematic than just the config files for grub not getting auto-generated properly (I can edit those if need be). It seems I've got similar problems when trying to unlock the LUKS disks before GRUB starts. Specifically the Edit: this is the exact output I get: When trying again: Both were run when this was the load.cfg: End edit As a result my current boot procedure consists of using a live USB stick, installing This is the relevant part of grub.cfg (for some reason at runtime it executes the For But only for the disk that works do I ever see this line following it: Additionally for that disk I see it detecting the lz4 feature, which I don't for the disk failing detection: |
|
The unknown compression (or checksum failure) hints that the zfs reader is reading wrong blocks for some reason - so it did read something and trying to make sense what it got - but the compression type bits do not match the list of supported compression algorithm. |
|
@tsoome maybe the problem is that I'm using a multi-disk setup and the pool as a whole shouldn't be expected to be readable until both disks are decrypted? Because it always gives this error after entering the passphrase to unlock the first disk but never after the second. Unfortunately after the second it just drops into the rescue prompt. Hmm, maybe the prefix is the problem? Because that looks like this: I'm not seeing the second disk in there. Should it be? Or if it's decrypted should it be smart enough to figure out to use one of those on its own? |
|
Some more experiments from within GRUB at the bootprompt give me this (I have to record a video and manually enter it so I'm restricting myself to what I believe is most useful): Apparently the cryptomount commands work. But trying to access the pool of 2 disks afterwards fails: Running the same command with debug=all: I find it strange that with more debug output I never find the original The checksum message is still strange because A: I've got Any ideas how to debug this more? Get more info that can help with a solution? PS: This didn't happen before I added my second disk (i.e. before I had a single-disk pool). |
|
Just faced an another "unknown filesystem" case. GRUB detection does not support ashift=14. Simplest test case is With ashift 13 grub-probe works. |
|
I just had this issue on Focal after following the guide. Not sure how to debug this. |
Hi,
Regarding the dailies version of zfs: 0.6.3-22
2d9d57jessieMounted zfs files systems are not detected by grub-probe with "error: unknown filesystem" being returned. No such issue found with version v0.6.3-766_gfde0d6d (non-dailies). I am running Debian Jessie of VirtualBox.
All packages below are version: 2.02~beta2-19 amd64
grub-efi
grub-efi-amd64
grub-efi-amd64-bin
grub2-common
Thanks for all that you do,
Azeem
The text was updated successfully, but these errors were encountered: