Hello, Currently, grub has no way to know which /dev/ entries corresponds to /boot and /. Its detection mechanism is to run stat /, which on Linux notably gives
Device: 306h/774d Inode: 2 Links: 29 i.e. st_dev is (3,6), and it also runs stats on /dev/*, notably /dev/hda6: Device: eh/14d Inode: 6385 Links: 1 Device type: 3,6 i.e. st_rdev is (3,6) too, thus the match between / and /dev/hda6. On GNU/Hurd, stat / gives Device: 3h/3d Inode: 2 Links: 24 i.e. st_dev is 3, that's the pid of ext2fs (aka fsid). and stat /dev/hd0s1 gives Device: 2f4eh/12110d Inode: 33554 Links: 1 Device type: 0,0 i.e. st_rdev is always zero. Mismatch. A good thing in using the pid for the st_dev is that it's indeed unique even if there are plenty of translators. However, there is no relation between the storeio process's st_rdev and the fs process's st_dev. Even worse, there is even less relation between the storeio process of / and the / fs process since the latter doesn't talk to the former but to GNU Mach. The only link that POSIX seems to make between them is their description: “dev_t st_dev Device ID of device containing file” and “dev_t st_rdev Device ID (if file is character or block special).” I can see two solutions: - Either we align more on POSIX to manage to get the st_dev (aka fsid) of filesystems equal to the the st_rdev of their underlying /dev entries. An easy way is to have storeios expose their own pid as st_rdev, and have filesystems use the underlying storeio st_rdev for their st_dev (aka fsid). One issue is for the / ext2fs, since it doesn't use a storeio, and a storeio could be started later. - Or we make grub use a more hurdish interface, i.e. file_get_storage_info, e.g. storeinfo -n / . I have however observed a disturbing behavior: $ dd < /dev/zero > foo bs=1M count=1 $ /sbin/mke2fs -o hurd foo $ settrans -c bar /hurd/ext2fs $PWD/foo $ storeinfo foo/ device (0x200): hd2: 512: 8: 4096: 11848072+8 It is indeed true that the file is actually stored in hd2, but before that it's stored in the foo file and wouldn't be available by just mounting hd2. Samuel
