On Mon, Jan 12, 2009 at 07:57:44PM +0000, Robert McQueen wrote: > I didn't test that, I was basing on my experiences of installing GRUB > manually. I usually do: > > mkdir /boot/grub > cp -a /usr/lib/grub/i386-pc/* /boot/grub > vi /boot/grub/device.map > grub --device-map=/boot/grub/device.map > # doesn't work because XFS hasn't put /boot/grub onto disk ... > # swear a bit > xfs_freeze -f / > xfs_freeze -u / > grub --device-map=/boot/grub/device.map > # works > update-grub > # makes me a menu.lst file > > This never froze for me.
I wasn't aware you were running xfs_freeze by hand. But I don't trust that this won't hang the kernel. See the link I pasted in the previous mail. This situation is very unfortunate. If we call xfs_freeze, we risk hanging Linux. If we don't, we risk the file being inaccesible. As you point out, an error message is preferable to hanging the kernel, but it's a certain error message against a possible but unlikely hang. Maybe we should go with the latter then? In any case, both are better than a certain hang which is what we have now. > > And if we _really_ need xfs_freeze, it means we're doing something wrong. > > I thought the wrongness was well known: the GRUB shell tries to read the > block device directly and traverse the filesystem directories itself to > to find which blocks on the disk are where the stage* files are located. No, this is a missunderstanding (which I got misled with, too). GRUB only tries to verify that the file will be readable later on (that is, when Linux isn't running). stage1 is the MBR. stage1.5 is supposed to be embedded after the MBR. stage2 is in the filesystem, and only accessed using the filesystem driver in stage1.5. > XFS considers putting the metadata into the journal an acceptable > implementation of sync(), but grub's filesystem reading code ignores the > journal, so can't find the files. If the shell used FIBMAP ioctl to find > the blocks when running under the OS, it'd always find them and all > would be sweetness and light. We can't do that. Using kernel facilities to find the blocks would defeat the point of verifiing that GRUB can read the file. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
