175243 2007-04-19 16:27 0000 /proc/mounts references /dev/root for / but /dev/root does not exist 2007-11-19 20:42:30 0000 1 1 1 Unclassified Gentoo Linux Ebuilds 2006.1 All Linux RESOLVED FIXED P2 normal --- 1 cardoe@gentoo.org udev-bugs@gentoo.org brebs@sent.com cgwaldman@gmail.com gentopia@gentoo.org ikelos@gentoo.org kernel@gentoo.org nospam@dolney.com teidakankan@gmail.com cardoe@gentoo.org 2007-04-19 16:27:33 0000 Basically if you look at /proc/mounts on a system booted with or without our initramfs, you will see that in /proc/mounts that the kernel says /dev/root is mounted as the / device. However there is no /dev/root device. Straight from the mount(8) man page... When the proc filesystem is mounted (say at /proc), the files /etc/mtab and /proc/mounts have very similar contents. The former has somewhat more information, such as the mount options used, but is not necessar- ily up-to-date (cf. the -n option below). It is possible to replace /etc/mtab by a symbolic link to /proc/mounts, and especially when you have very large numbers of mounts things will be much faster with that symlink, but some information is lost that way, and in particular work- ing with the loop device will be less convenient, and using the "user" option will fail. zzam@gentoo.org 2007-04-19 16:57:12 0000 my suggestions are: A: In hal init-script (or before: like end of udev-start): read major/minor of dir "/" and mknod /dev/root if it does not exist B: let code search inside /dev for the device with that major/minor and link to it. getting major/minor cannot use program stat (at least not in udev) as stat is in /usr. We need a small helper call syscall stat and extract the info from there. C: Adding a udev rule similar to this: SUBSYSTEM=="block", PROGRAM=="check_if_i_am_root", SYMLINK="root" and that program (check_if_i_am_root) compares major/minor of the device to that of "/" directory. something like: major=getenv("MAJOR"); minor=getenv("MINOR"); dev_t dev=stat("/"); if (major/minor == dev) return EXIT_SUCCESS; else return EXIT_FAILURE; D: Patching hal to do this: if (device=="/dev/root") { device=lookup_real_name; } dsd@gentoo.org 2007-04-19 17:11:32 0000 I feel that hal shouldn't be relying on the devices listed in /proc/mounts existing. As /proc/mounts is kernel-space but filesystem contents are controlled in userspace (and operations are not really filtered by the kernel), there's no way consistency can be guaranteed. Some examples for when these devices nodes might not exist: 1. When the kernel mounts the root filesystem during boot. There is no userspace here and no /dev. The kernel has to choose a name for the node, or not list it at all. There is no guarantee that userspace will create the same name later. 2. When a mounted usb flash drive is unplugged, the device goes away but the mount does not. 3. The user could remove a mounted node, or /dev might be replaced by another layout entirely (this happens during initramfs pivot, for example). 4. Many things in /proc/mounts don't correspond to device nodes anyway, e.g. sysfs The kernel documentation does not comment on the accuracy of the device nodes listed in /proc/mounts. Neither does the mount documentation. FWIW, I also think a kernel documentation patch would be accepted to add some comments pointing out the obvious that device nodes referred to in /proc/mounts may not actually exist in userspace (because what userspace does in this sense is not kernel business). Maybe this would change your views on the solution here. IMO hal should do something different. Even though creating /dev/root would workaround the majority of problems, I don't feel that it is a solution, and given our crazy user-base you'll probably get that one guy who files an obscure bug later for a different device node. zzam@gentoo.org 2007-04-19 17:28:54 0000 Created an attachment (id=116745) blockdev_is_root.c calling the attached program from that udev-rule will create /dev/root: SUBSYSTEM=="block", PROGRAM=="blockdev_is_root", SYMLINK+="root" wolf31o2@gentoo.org 2007-04-19 18:28:52 0000 I'm just curious why genkernel is on here. We don't use udev (anymore) at all in our initramfs stuff, as we've replaced it with mdev from busybox to reduce size and complexity. Of course, I might just be missing something important. ;] cardoe@gentoo.org 2007-04-19 21:01:51 0000 Because the initramfs needs to create the proper node as well.. whatever that's getting populated as. SuSE and RedHat's initramfs is doing the right thing and mounting the device for the kernel so it's a non-issue. But I don't know if your initramfs does this... brebs@sent.com 2007-04-20 02:51:27 0000 Arch Linux creates /dev/root by calling root-link.sh in /etc/udev/rules.d/udev.rules $ grep root /etc/udev/rules.d/* /etc/udev/rules.d/udev.rules:# fix /dev/root symlink /etc/udev/rules.d/udev.rules:SUBSYSTEM=="block", RUN+="/lib/udev/root-link.sh" The script and udev patches are at: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/base/udev/?cvsroot=Current&only_with_tag=CURRENT christophe@saout.de 2007-04-20 22:02:31 0000 My system doesn't show /dev/root in /proc/mount (because in my case it's mounted by initramfs, not the kernel itself), so the warning is bogus on my machine. cgwaldman@gmail.com 2007-04-20 22:17:39 0000 An even better way to get the root device, rather than getting it from /proc/cmdline (which may not work, since if you use LILO the root device gets turned into a number), is to do mount -fv / | cut -d' ' -f1 or equivalently, mount -fv / | awk { print $1 ; } zzam@gentoo.org 2007-04-21 06:24:28 0000 Discussion on hotplug-ML about that topic/suggested udev patch can be found here: http://thread.gmane.org/gmane.linux.hotplug.devel/11277 kfirufk@gmail.com 2007-04-21 11:13:41 0000 thanks for your comments. i added this to /etc/conf.d/local.start ROOT_DEVICE=`mount -fv / | cut -d' ' -f1` ln -s ${ROOT_DEVICE} /dev/root do i need to create the device before hal is started, or is this a good method ? cardoe@gentoo.org 2007-04-21 17:28:30 0000 I personally feel this is a kernel bug. Since we're instructing the kernel via root= what dev device it should use. It should respect that, after all it does for initramfs so why not for root=. Attached is a patch to do such with the kernel. cardoe@gentoo.org 2007-04-21 17:29:36 0000 Created an attachment (id=116919) use root= rather then hardcoding to /dev/root The other advantage of this is that we don't have to search and compare every block device. It's also not a userspace hack to fix a kernel space bug. mycroes@zonnet.nl 2007-04-27 19:37:16 0000 I was just wondering... What's the exact goal of this /dev/root thing? Because if I'm using an initrd, my kernel command line option will be root=/dev/ram0, if I'm not, it will be /dev/sda6. I don't see the use for a /dev/root that is based on the way I boot, but I guess I'm missing something... For me the warning is bogus too right now, there's no /dev/root in my /proc/mounts, the only references are: rootfs / rootfs rw 0 0 /dev/sda6 / reiserfs rw,noatime 0 0 Please enlighten me... cardoe@gentoo.org 2007-04-27 20:40:43 0000 Michael, When you use an initramfs (initrd), the kernel does the right thing. As you can see there, your device for / is /dev/sda6. This bug is for when there is no initramfs. agaffney@gentoo.org 2007-11-17 02:59:32 0000 Since this bug is for behavior that occurs when there is *not* an initramfs, I'm removing genkernel. zzam@gentoo.org 2007-11-19 20:42:30 0000 This is fixed. udev handles it fine now so /dev/root will exist. 116745 2007-04-19 17:28 0000 blockdev_is_root.c blockdev_is_root.c text/plain Ly8gY29tcGFyZSBNQUpPUi9NSU5PUiBpbiBlbnZpcm9ubWVudCB3aXRoIHRoZSBkZXZpY2UKLy8g LyBpcyBtb3VudGVkIG9uCi8vCi8vIEF1dGhvcjogTWF0dGhpYXMgU2Nod2Fyem90dCA8enphbUBn ZW50b28ub3JnPgoKI2luY2x1ZGUgPHN5cy90eXBlcy5oPgojaW5jbHVkZSA8c3lzL3N0YXQuaD4K I2luY2x1ZGUgPHVuaXN0ZC5oPgoKI2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIu aD4KCi8vIEdldHRpbmcgbWFqb3IvbWlub3IKI2luY2x1ZGUgPHN5cy9zeXNtYWNyb3MuaD4KaW50 IG1haW4oaW50IGFyZ2MsIGNoYXIgKiphcmd2KQp7CglzdHJ1Y3Qgc3RhdCBzdGF0X2J1ZjsKCXVu c2lnbmVkIGludCByb290X21ham9yPTAsIHJvb3RfbWlub3I9MDsKCXVuc2lnbmVkIGludCBkZXZf bWFqb3I9MCwgZGV2X21pbm9yPTA7CgljaGFyICp0OwoKCXQ9Z2V0ZW52KCJNQUpPUiIpOwoJaWYg KCF0KQoJCXJldHVybiBFWElUX0ZBSUxVUkU7CgllbHNlCgkJZGV2X21ham9yPXN0cnRvbCh0LCBO VUxMLCAxMCk7CgoJdD1nZXRlbnYoIk1JTk9SIik7CglpZiAoIXQpCgkJcmV0dXJuIEVYSVRfRkFJ TFVSRTsKCWVsc2UKCQlkZXZfbWlub3I9c3RydG9sKHQsIE5VTEwsIDEwKTsKCQoKCWlmIChzdGF0 KCIvIiwgJnN0YXRfYnVmKTwwKQoJCXJldHVybiBFWElUX0ZBSUxVUkU7CgoJcm9vdF9tYWpvcj1t YWpvcihzdGF0X2J1Zi5zdF9kZXYpOwoJcm9vdF9taW5vcj1taW5vcihzdGF0X2J1Zi5zdF9kZXYp OwoKCgkvLyBwcmludGYoIlJPT1Q6ICVkIC8gJWQgXG4iLCByb290X21ham9yLCByb290X21pbm9y KTsKCS8vIHByaW50ZigiREVWOiAgJWQgLyAlZCBcbiIsIGRldl9tYWpvciwgZGV2X21pbm9yKTsK CglpZiAoIXJvb3RfbWFqb3IgfHwgIWRldl9tYWpvcikgewoJCXByaW50ZigiTUFKT1I9PTBcbiIp OwoJCXJldHVybiBFWElUX0ZBSUxVUkU7Cgl9CgoJaWYgKCAocm9vdF9tYWpvcj09ZGV2X21ham9y KSAmJiAocm9vdF9taW5vcj09ZGV2X21pbm9yKSkKCQlyZXR1cm4gRVhJVF9TVUNDRVNTOwoKCXJl dHVybiBFWElUX0ZBSUxVUkU7Cn0KCg== 116919 2007-04-21 17:29 0000 use root= rather then hardcoding to /dev/root dev-root-real-root.patch text/plain LS0tIGxpbnV4LTIuNi4yMC1nZW50b28tcjYvaW5pdC9kb19tb3VudHMuYwkyMDA3LTA0LTE3IDAx OjI3OjI3LjAwMDAwMDAwMCAtMDQwMAorKysgbGludXgtZGV2LXJvb3QvaW5pdC9kb19tb3VudHMu YwkyMDA3LTA0LTIxIDEzOjAwOjMyLjAwMDAwMDAwMCAtMDQwMApAQCAtMzU0LDcgKzM1NCwxMCBA QAogCXZhX3N0YXJ0KGFyZ3MsIGZtdCk7CiAJdnNwcmludGYoYnVmLCBmbXQsIGFyZ3MpOwogCXZh X2VuZChhcmdzKTsKLQlmZCA9IHN5c19vcGVuKCIvZGV2L3Jvb3QiLCBPX1JEV1IgfCBPX05ERUxB WSwgMCk7CisJaWYgKHNhdmVkX3Jvb3RfbmFtZVswXSkKKwkJZmQgPSBzeXNfb3BlbihzYXZlZF9y b290X25hbWUsIE9fUkRXUiB8IE9fTkRFTEFZLCAwKTsKKwllbHNlCisJCWZkID0gc3lzX29wZW4o Ii9kZXYvcm9vdCIsIE9fUkRXUiB8IE9fTkRFTEFZLCAwKTsKIAlpZiAoZmQgPj0gMCkgewogCQlz eXNfaW9jdGwoZmQsIEZERUpFQ1QsIDApOwogCQlzeXNfY2xvc2UoZmQpOwpAQCAtMzk3LDggKzQw MCwxMyBAQAogCX0KICNlbmRpZgogI2lmZGVmIENPTkZJR19CTE9DSwotCWNyZWF0ZV9kZXYoIi9k ZXYvcm9vdCIsIFJPT1RfREVWKTsKLQltb3VudF9ibG9ja19yb290KCIvZGV2L3Jvb3QiLCByb290 X21vdW50ZmxhZ3MpOworCWlmIChzYXZlZF9yb290X25hbWVbMF0pIHsKKwkJY3JlYXRlX2Rldihz YXZlZF9yb290X25hbWUsIFJPT1RfREVWKTsKKwkJbW91bnRfYmxvY2tfcm9vdChzYXZlZF9yb290 X25hbWUsIHJvb3RfbW91bnRmbGFncyk7CisJfSBlbHNlIHsKKwkJY3JlYXRlX2RldigiL2Rldi9y b290IiwgUk9PVF9ERVYpOworCQltb3VudF9ibG9ja19yb290KCIvZGV2L3Jvb3QiLCByb290X21v dW50ZmxhZ3MpOworCX0KICNlbmRpZgogfQogCg==