[gentoo-amd64] Re: grub fs support

[Duncan]

Bob Sanders <rsanders@×××.com> posted 20090126230132.GI43269@×××.com,
excerpted below, on  Mon, 26 Jan 2009 15:01:32 -0800:

> Saphirus Sage, mused, then expounded:
>> Beso wrote:
>> > 2009/1/26 Nikos Chantziaras <realnc@×××××.de>:
>> >> Bob Sanders wrote:
>> >>> Morgan Wesström, mused, then expounded:
>> >>>
>> >>>>> I answered that initially. Grub does not support ext3 or ext4.
>> >>>>>
>> >>>> # mount | grep boot
>> >>>> /dev/sda1 on /boot type ext3 (rw,noatime)
>> >>>>
>> >>>> GRUB working fine with ext3 here...
>> >>>> /Morgan
>> >>>>
>> >>> For now.  Grub supports ext2.  It may or may not work properly with
>> >>> journaled file systems, depending upon phase of the moon, current
>> >>> tide level, etc.
>> >>>
>> >> It works 100% with ext3 because ext3 is compatible with ext2, both
>> >> for read as well as write operations.  It's not dependant on tide or
>> >> moon or the super bowl.  It works, all the time, 100% correctly,
>> >> with no side effects, no downsides and no bugs.
>> >>
>> > and also with reiserfs v3. as i've said i've been using it with
>> > reiserfs for more than 3 years and haven't had an issue. saying
>> > that it only supports ext2 sounds a little strange. maybe Bob was
>> > trying to say that the official grub team officially support only
>> > ext2. this is different from saying that grub only supports ext2.
>> >
>> If you try hard enough, you could probably eventually get it to support
>> anything, but the only filesystem I've heard of grub supporting is
>> ext2. Granted, ext3 works, as we've pointed out and as I've checked the
>> configuration on one of my computers has confirmed. But, everything
>> I've heard suggests that grub doesn't officially support other file
>> systems, other than ext2.
>>
>>
> From the Grub online manual -
>
> Support multiple filesystem types transparently, plus a useful explicit
> blocklist notation. The currently supported filesystem types are BSD
> FFS, DOS FAT16 and FAT32, Minix fs, Linux ext2fs, ReiserFS, JFS, XFS,
> and VSTa fs.
>
> I can give examples where is doesn't work with XFS.
>
> I haven't seen it fail with ext3, but I've not tested all configs.

First, Bob, specifically which "online manual"?  Do you mean the manpage, 
the infopages, or a specific manual at the official site, and if it's the 
manpage or infopages, are you talking Gentoo's which may be patched to 
reflect the patches Gentoo applies, or the official versions, and if you 
mean official online, were you looking at the GRUB-2 official or 
GRUB-0.97 official?

Not that I doubt you, but if we're quoting official position, it's nice 
to have a reference to cite, and it makes a difference whether we're 
talking what upstream calls "legacy" grub, 0.97, or grub 2, supposedly 
where all the new work is going.

Unfortunately, grub 2 isn't officially released yet and AFAIK, wasn't 
even frozen to new features until December or so.  AFAIK, there's a lot 
of stuff that isn't "officially" supported in "legacy" grub and never 
will be as it's in strictly maintenance mode, no new features at all, tho 
there's reasonably well tested patches that pretty much all distributions 
apply that add the missing functionality, because grub 2 has been way too 
far from stable to even /think/ about shipping in a "supported" release, 
but "legacy" grub, without patches, simply breaks on a lot of the newer 
installations, including "huge-file" and "huge-fs" ext2/3, the ext3 
journal, ext4 (with extents) and reiser4 entirely, etc.

Meanwhile, what I expect the problem is with ext3, and why most people 
never see it, is that while grub (legacy) has original ext2 support, it 
doesn't replay the journal before trying to use the filesystem.  Normally 
this won't be a problem, particularly on separate /boot partitions that 
aren't mounted by default, because the journal is played back and 
everything merged upon normal unmount.  However, in the narrow case where 
something grub uses at boot was changed and logged, but the system 
crashed before the log was played back and the filesystem fully 
reconciled, THEN there might be a problem, because grub doesn't know 
about the journal and doesn't play it back, so it would be trying to use 
old and outdated information.  If it's just a new kernel and the old one 
wasn't deleted (as should always be the case until the new one's tested, 
but...), grub should still be able to find the old kernel and boot it, no 
harm, no foul.  But if grub can't find something critical like its 
stage-2 because it moved and the log wasn't synced... better hope you 
have an alternate boot method!

AFAIK something similar applies to reiserfs.  Grub supports the basics, 
maybe even the reiserfs log I'm not sure, but last I knew anyway, it 
didn't support reiserfs' default tail-packing.  Officially, one was 
supposed to always mount a reiserfs grub based boot partition with the no-
tail option.

Now I run reiserfs on everything here, even /boot even tho I'd ordinarily 
put ext2 on /boot, because with nothing running ext2/3, I don't have to 
compile or load it.  (In actuality, I do still compile it as a module, 
much like FAT and ISO9660, to use with removable media only.  However, 
none of the three, fat/iso9660/ext2, are loaded by default, only when I'm 
playing with removable media that needs them.)  And, I don't bother with 
no-tail on anything, including /boot.  Most of the time it works just 
fine, but I run the -rc and often git kernels, sometimes rebuilding, 
installing and rebooting to test the new kernel a dozen or more times in 
a day, when I'm doing a git-bisect to trace down a bug, so I do a LOT of 
kernel installs, way more than most people do, and with all those 
installs, twice in the three years or so since I've started using grub, 
I've had it "mysteriously" fail on me.  The first time I had to use an 
old Ubuntu install CD and install to a (luckily) empty partition, in 
ordered to use its grub to boot Gentoo, and reinstall Gentoo's grub, as I 
didn't have anything else available to boot from.  So after that I made 
sure I created a GRUB boot floppy (actually two, since I don't trust 
floppy data integrity, too many bad ones over the years, yes, I still 
have a floppy drive in this machine), and the second time, I simply 
booted from it.  Now I have no way of knowing for sure, but I strongly 
suspect that what actually happened is that the reiserfs tail-packing 
ended up moving some bit of critical data out from where grub could find 
it, thus causing grub to fail to load its stage-2, without which it's 
dead on disk.  I'd guess the failure rate at <1%, not enough to worry 
about really since I do have the grub floppy available now, but it's 
there, very likely because I use reiserfs tail-packing on my /boot 
partition.  It might also be that grub doesn't replay the reiserfs 
journal, but I normally don't have /boot mounted unless I'm working on it 
and immediately unmount it when I'm done, and I don't /believe/ either of 
those failures was after a crash with /boot mounted, so I discount that 
as unlikely for either of the failures I had, and simply don't know, 
otherwise.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman