After updating from 1.99-r1 to 1.99-r2 to fix #381491, grub fails to identify my / device. /sbin/grub2-probe --target=device / gives: error: cannot find a device for / (is /dev mounted?) This time around though, -r2 correctly finds my /boot, so I only need to hack the mkconfig with a hardcoded / dev. As in the previous bug, I tried both with openrc and systemd, and I get the same result. Reproducible: Always
Just to update the bug with my info from the other bug: raven ~ # grub2-mkconfig /sbin/grub2-probe: error: cannot find a device for / (is /dev mounted?). Here is the mount output: raven ~ # mount rootfs on / type rootfs (rw) /dev/root on / type btrfs (rw,noatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) rc-svcdir on /lib/rc/init.d type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime) udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620) shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) nfsd on /proc/fs/nfsd type nfsd (rw,noexec,nosuid,nodev) Might be related to the btrfs filesystem. Any ideas?
I have the same issue with grub-1.99-r2 and brtfs. I work around it by manually creating a /dev/root symlink. floppym@naomi ~ % sudo grub2-probe --target=device / grub2-probe: error: cannot find a device for / (is /dev mounted?). floppym@naomi ~ % sudo ln -s sda2 /dev/root floppym@naomi ~ % sudo grub2-probe --target=device / /dev/sda2 floppym@naomi ~ % cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / btrfs rw,relatime,ssd 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib64/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev tmpfs rw,nosuid,relatime,size=10240k,mode=755 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0 shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0 tmpfs /tmp tmpfs rw,relatime 0 0 /dev/sdb1 /mnt/data1 btrfs rw,relatime 0 0 /dev/sdb1 /home btrfs rw,relatime 0 0 /dev/sdb1 /usr/portage/distfiles btrfs rw,relatime 0 0 /dev/sdb1 /usr/portage/packages btrfs rw,relatime 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
I too have btrfs on the laptop that fails, but on the other hand I have a second laptop with btrfs where it works great.
Damn i really wonder how to a) reproduce this b) fix this Maybe i should just ignore the releases and create us snapshots, because live version has it working, Could you two verify that live works for you too?
I have the same problem with the live ebuild.
Hmm same issue with live version... Would you mind reporting bug on #grub irc, they are almost non-responsive and don't use any bugzilla i would know off (quite annoying) because i have no idea how to fix your issue, or at least reproduce it :)
I too have the same problem with the live version. I asked in #grub, and after a short discussion got the answer that me missing /dev/root was the problem. ln -s /dev/sda3 /dev/root does indeed make grub work. Currently I can find neither my first bug report (because I can't search properly in here?) nor the grub mail mentioning this problem, so I can't quite put things into context.
Problem is that it should NOT use /dev/root at all
I lied in #3. The laptop where this works, uses ext4 for it's / So this does seem to be btrfs specific.
I will do some digging through the grub-probe code when I have a chance to try and narrow this down. I seem to recall some oddity with a call to stat(2) on btrfs, but I may be mis-remembering.
From grub/util/getroot.c, it seems that grub-probe just reads through /proc/self/mountinfo because st_dev from stat(2) is unreliable for btrfs. Additionally, when I specify root=/dev/sda2 on the kernel command line with no initramfs, the kernel displays /dev/root as the device name. However, if I have an initramfs that actually calls mount /dev/sda2, the kernel reports /dev/sda2 as the device name, and everything just works.
(In reply to comment #11) > From grub/util/getroot.c, it seems that grub-probe just reads through > /proc/self/mountinfo because st_dev from stat(2) is unreliable for btrfs. > > Additionally, when I specify root=/dev/sda2 on the kernel command line with no > initramfs, the kernel displays /dev/root as the device name. > > However, if I have an initramfs that actually calls mount /dev/sda2, the kernel > reports /dev/sda2 as the device name, and everything just works. That could because for initramfs, /dev/root was ramfs. That's what I mostly understood from udev upstream talk about bad /dev/root.
Could anyone experiencing this issue re-test with grub-2.00_beta0? There have been some changes to the way btrfs filesystems are detected in grub-probe.
Sorry, no dice. # emerge -vpq grub [ebuild R ] sys-boot/grub-2.00_beta2-r1 USE="nls sdl truetype -custom-cflags -debug -device-mapper -efiemu -libzfs -mount -static" GRUB_PLATFORMS="-coreboot -efi-32 -efi-64 -emu -ieee1275 -multiboot -pc -qemu -qemu-mips -yeeloong" # grub2-mkconfig -o /boot/grub/grub.cfg /usr/sbin/grub2-probe: error: failed to get canonical path of /dev/root. # ln -s sdc3 /dev/root # grub2-mkconfig -o /boot/grub/grub.cfg Generating grub.cfg ... <snip> Found Gentoo Base System release 2.0.1 on /dev/sdd3 done
I have the same problem with btrfs (udev doesn't create /dev/root symlink). May be it will be useful I found info related to reasons of it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670146
(In reply to comment #15) > I have the same problem with btrfs (udev doesn't create /dev/root symlink). > May be it will be useful I found info related to reasons of it: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670146 It seems that's not only btrfs specific. I use nilfs2 on my rootfs and start nilfs_cleanerd (nilfs garbage collector) by a script in /etc/local.d. It was working fine until someday (don't know when exacly) /dev/root was not created anymore and nilfs_cleanerd failed to start. Not runnig garbage collector ended with "no space left on device". Issue related to missing /dev/root is disscused now on linux-nilfs mailing list [1]. [1] http://marc.info/?t=134182076600003&r=1&w=2
I have the same probleme, qlist -ICv udev sys-fs/udev-188 sys-fs/udev-init-scripts-16 qlist -ICv grub sys-boot/grub-2.00
Have the issue too. My / was converted from ext4 to btrfs, dunno if that matters. Laptop is around 4 months old (clean install), been using btrfs for ~3 weeks now.
All, is this still an issue if you upgrade udev to udev 190?
All, I have been told that upgrading to linux-3.6.2 fixes this issue. Can someone confirm?
(In reply to comment #20) > I have been told that upgrading to linux-3.6.2 fixes this issue. Can > someone confirm? Right. For simple btrfs filesystems, linux-3.6 seems to populate /proc/self/mountinfo with a real device node rather than a silly pointer to /dev/root, which lets grub2-probe work properly.
I'm guessing this commit did the job. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=aa9ddcd4b5557102fa25695c11904f249b4dec49
Re-Visited ? with ! ext4 ! , not btrfs qlist -ICv gentoo-sources sys-kernel/gentoo-sources-3.8.2 qlist -ICv udev sys-fs/udev-197-r8 sys-fs/udev-init-scripts-23 virtual/udev-197-r1 qlist -ICv grub sys-boot/grub-2.00-r2 grub2-mkconfig -o /boot/grub2/grub.cfg : ############################################################################# /usr/sbin/grub2-probe: error: failed to get canonical path of PARTUUID= ... . ############################################################################# gdisk -l /dev/sdc: ############################################################################# GPT fdisk (gdisk) version 0.8.4 ... Number Start (sector) End (sector) Size Code Name 1 2048 2099199 1024.0 MiB EF00 EFI System 2 2099200 4196351 1024.0 MiB EF02 BIOS boot partition 3 4196352 6293503 1024.0 MiB 8300 Linux filesystem 4 6293504 79693823 35.0 GiB 8200 Linux swap 5 79693824 1953525134 893.5 GiB 8300 Linux filesystem ############################################################################# /dev/sdc3: ext2 /boot /dev/sdc5: ext4 / <root> HINT 1: Just updated to 3.8.2 HINT 2: no /dev/root , but: df -h / ############################################################################# Filesystem Size Used Avail Use% Mounted on PARTUUID=3FAC7BF3-749E-410F-BDE9-0ED8BC991470 880G 9.7G 826G 2% / ############################################################################# HTH. Thanks.
ll /dev/disk/by-partuuid/ ... lrwxrwxrwx 1 root root 10 10. Mär 14:58 3fac7bf3-749e-410f-bde9-0ed8bc991470 -> ../../sdc5 ... NOTABENE: This link is in _lowercase_ letters - can't judge yet if that may matter.
HINT: https://bugs.gentoo.org/show_bug.cgi?id=438380
(In reply to comment #20) > All, > > I have been told that upgrading to linux-3.6.2 fixes this issue. Can > someone confirm? (In reply to comment #22) > I'm guessing this commit did the job. > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit; > h=aa9ddcd4b5557102fa25695c11904f249b4dec49 This can now be closed?
> This can now be closed? Hi, Samuli, unfortunately not. /etc/devault/grub: A) #GRUB_DEVICE ( commented ) (= /dev/sdc5 ) : "grub2-mkconfig -o /boot/grub2/grub.cfg" works just fine. B) GRUB_DEVICE="PARTUUID=3FAC7BF3-749E-410F-BDE9-0ED8BC991470" : "grub2-mkconfig -o /boot/grub2/grub.cfg" still fails: Generating grub.cfg ... Found background: /boot/grub2/bgi.jpg /usr/sbin/grub2-probe: error: cannot find a GRUB drive for PARTUUID=3FAC7BF3-749E-410F-BDE9-0ED8BC991470. Check your device.map. Found linux image: /boot/vmlinuz-3.8.3 /usr/sbin/grub2-probe: error: cannot find a GRUB drive for PARTUUID=3FAC7BF3-749E-410F-BDE9-0ED8BC991470. Check your device.map. done So the main reason why "PARTUUID=" was introduced (working with multiple installations / kernel/system partitions) is still corrupted. Kind regards Manfred
(In reply to comment #27) > > This can now be closed? > > Hi, Samuli, > > unfortunately not. As I see it, you are the only one in this bug with that specific problem. Or can you point out to me how do you draw the conclusion your problem is the same? I just don't see the required similarity in the condition and the errors. I believe you should open a new bug report.
(In reply to comment #28) > (In reply to comment #27) > > > This can now be closed? > > > > Hi, Samuli, > > > > unfortunately not. > > As I see it, you are the only one in this bug with that specific problem. Or > can you point out to me how do you draw the conclusion your problem is the > same? > I just don't see the required similarity in the condition and the errors. > I believe you should open a new bug report. Unless the maintainers don't mind diverging the bug to this issue now of course, or if I'm wrong :-)
(In reply to comment #28) > I believe you should open a new bug report. Agreed. Re-considering, I feel that's better as well, and perfectly fine with me. (But tomorrow, preferred - too tired for a clean write-up.) Thanks! P.S.: Should I mark this as a possible "blocker" to BUG 438380 then, too ? At least to me the cause seems to be related ...
(In reply to comment #26) > (In reply to comment #20) > > All, > > > > I have been told that upgrading to linux-3.6.2 fixes this issue. Can > > someone confirm? > > (In reply to comment #22) > > I'm guessing this commit did the job. > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit; > > h=aa9ddcd4b5557102fa25695c11904f249b4dec49 > > This can now be closed? ^ Point 1 and 2(In reply to comment #30) > (In reply to comment #28) > > I believe you should open a new bug report. > (But tomorrow, preferred - too tired for a clean write-up.) ^ Point 3, bug 462748, was closed as RESOLVED, UPSTREAM, turned indeed to be different issue than in this bug. So with these points, I don't see anything left to do here.
