Ext4 support in RHEL Server 5.4 GRUB
 

On a computer with 6 internal SCSI disks, RHEL was installed
on Disk #0. The contents of /etc/redhat-release are:

Red Hat Enterprise Linux Server release 5.4 (Tikanga)

The installation consumed the entire disk (although the file
systems that were created have plenty of available space)
but left the other 5 disks untouched. So, to put some of
the remaining disk storage to educational purposes, I
proceeded to install a couple of other operating systems on
Disk #1 -- specifically, Solaris, and OpenSuse 11.4. The
contents of /etc/issue on the latter system are:

Welcome to openSUSE 11.4 "Celadon" - Kernel \r (\l).

Except for brief periods while installing on other disks,
the Adaptec SCSIUtils (or whatever the bloody thing is
called) has been instructed to keep Disk #0 as the boot
disk, with an MBR, you will recall, that was populated by
the RHEL installation. The appropriate stanzas were added
to /boot/grub/menu.lst on the RHEL system. With respect
to the Solaris system, a rootnoverify and chainloader line
are sufficient (parenthetically, I heard that the RHEL grub
now understands Solaris subpartitioning, just as it for a
long time has understood FreeBSD subpartitioning, but I
have not tested that hypothesis, as the rootnoverify and
chainloader technique continues to work quite adequately).
With respect to the OpenSuse system, the lines added to
/boot/grub/menu.list were the standard root, kernel, and
initrd lines.

As it turned out, the boot loader on Disk #0 was unable to
find the kernel and initrd files for OpenSuse 11.4. As it
further turned out, this was because the root filesystem
(no /boot filesystem in OpenSuse 11.4) was installed as an
ext4fs, and the RHEL 5.4 grub cannot find files in an ext4fs,
even though the RHEL 5.4 kernel (which is 2.6.18-164.el5)
has no problem with ext4fs. Specifically, the OpenSuse 11.4
root filesystem is installed on /dev/sdb6 and when you tell
grub "root (hd1,5)" it does not, at the point, complain,
but, on the contrary, cheerfully reports an ext2fs on
partition type 0x83. However, when you then tell it, e.g.,
"kernel /boot/vmlinuz" or use any other grub command that
requires grub to have knowledge of the filesystem, like,
e.g., file, or cat, grub displays no such knowledge
whatsoever.

The diagnosis of failure to understand ext4fs was confirmed
by creating an ext2fs on /dev/sdb7, mounting both it
and /dev/sdb6 on two different directories on the RHEL
system, and copying all the files from sdb6 to sdb7. A
stanza was then added to /boot/grub/menu.lst telling grub
to find its root at (hd1,6) but otherwise identical to the
failed stanza. Now grub can find the kernel and the initrd,
and it can boot the OpenSuse 11.4 system. It fact, it
boots the kernel with an argument of root=/dev/sdb6, so,
although grub boots the kernel from sdb7, the kernel, once
booted, cheerfully finds its root filesystem on sdb6, which,
you will recall, is an ext4fs.

Well, if the author may, at this point, be permitted a small
departure from the professorial narrative tone, this is
totally lame. It is totally lame for RHEL grub not to
understand ext4fs, in an era when a standard Linux
installation can place /boot/vmlinuz on an ext4fs.

Incidentally, the RHEL grub, when invoked from the
filesystem with the --version argument, claims to be version
0.97, although one cannot, technically, assert with
certainty that the version installed as the bootloader is
the same as the version in /sbin.

Other than telling me to update my version of RHEL (which is
not an option -- I must keep my system at Tikanga, because
the official Red Hat JBoss curriculum, which I teach, is
taught on the Tikanga platform), and other than telling me
to downgrade my OpenSuse root filesystem to ext2fs, what is
your advice? The current work-around is totally bogus, I
refuse to be content with a work-around that requires me to
keep an ext2fs on sdb just so the bootloader can find the
kernel and the initrd. Is there a Redhat-supported
bootloader that understands ext4fs that I can grub-install
onto sda? Rpmseek.com and rpmfind.net do not find any rpm's
that are newer than 0.97 (in fact, the newest rpm's they
find are several versions older). I hesitate to download
the latest source and build from source, for fear of losing
Redhat-specific extensions that I may currently have, but if
you tell me that there is no other solution, that is what
I shall do, even though it would be totally bogus.

Thank you in advance for your replies. If you wish to reply
to me personally rather than, or in addition to, this
forum, you may reach me at jay at m5 dot chicago dot il dot
us, or at +1 773/7613784.

(And if anyone knows anything about installing Haiku on
SCSI disks, which as far as I can tell is impossible, I'd
appreciate hearing something about that too, and thank you
in advance for that also.)

The entire point of RHEL is to bite off a chunk and support it for years, only adding security patches and minor improvements. Complaining that a stable release like RHEL (released Mar 2007 btw) is behind the bleeding edge of Linux (OpenSUSE 11.4 - Mar 2011) is, in my opinion, lame. What do you expect?

Your choices are:
(A) Fresh install of RHEL 6
(B) Upgrade to RHEL 5.6, which officially supports ext4 (I don't know exactly what Tikanga refers to, though)
(C) Use ext3 as the OpenSuSE root. ext2 would be silly, but what's wrong with ext3?
(D) Install grub from OpenSuSE, because it supports all exts.

('ext4dev' is supposedly in RHEL 5.x, x < 6, but from what I can see, ext4 and ext4dev are not compatible)

Installling GRUB from OpenSuse didn't fix the problem
 

Installing GRUB from OpenSuse didn't fix the problem, unless I did it wrong.

I booted into OpenSuse (using the totally lame technique described above,
by booting a kernel from the ext2fs on /dev/sdb7, albeit with the argument
root=/dev/sdb6). Once in OpenSuse, I mounted the root filesystem from RHEL
onto /mnt/sda (which I had to create), and then the boot filesystem onto
/mnt/sda/boot (which I of course did not have to create, because once the
root RHEL filesystem was mounted on /mnt/sda, an empty mountpoint /mnt/sda/boot
already existed). I then issued the command

grub-install.unsupported --root-directory=/mnt/sda /dev/sda

in which the only thing that may need to be explained is that OpenSuse has renamed
grub-install to grub-install.unsupported, something about encouraging people to
use yast2 instead of the CLI (but yast2, which I looked into, lacked the flexibility
to do what I wanted). After the above command ran, and claimed to run successfully,
even though at one point it complained about a program not being found, the timestamp
for /mnt/sda/boot/grub/stage2 was updated, suggesting that it had just been
rewritten. The timestamps for stage1 and stage1.5 had not been updated, although
I only looked at the modification time, which can be faked, I did not look at the
inode-change time, which cannot be faked unless you bypass the filesystem.

I then rebooted the computer, but there seems to be no change in its behavior, even
though I am supposedly now using the stage2 from the "bleeding edge" OpenSuse 11.4
rather than from RHEL 5.4 -- the boot loader, after being told

root (hd1,5)

still claims, as before:

Filesystem type is ext2fs, partition type 0x83

rather than acknowledging that it is ext4fs, and after the kernel command, it still
reports, as before:

Error 2: Bad file or directory type

and I still have to boot the OpenSuse kernel from a non-ext4 filesystem.

So, what did I do wrong? How do I get a bootloader that can boot a kernel from an
ext4fs? Thank you in advance for your replies.

jay at m5 dot chicago dot il dot us
+1 773 7613784

Must be a teacher - plenty of waffle.

Classic grub (as in 0.9?) is no longer developed. ext4 (and ext3 created after ext4 was released) uses a larger inode size that (classic) grub is unaware of.
Some distros released a patched grub to handle this - I'd be mighty surprised if OpenSuse didn't. In fact I'm sure I've used theirs somewhere along the road. Do the grub-install from OpenSuse (i.e. without pointing to RH) - else you'll just keep getting the unpatched version.

grub-1.99~rc1 replaces grub 0.97; some problems remain
 

Since, as stated earlier, a grub-install from OpenSuse onto the root directory
of the RHEL system did not solve the problem of booting from an ext4fs, I took
the only course of action that seemed open to me: I downloaded the source code
for the latest version of GRUB, built it from source, and then installed it
onto /dev/sda and the root directory of the RHEL system. I now have a functioning
multiboot system where I can boot either Red Hat Enterprise Linux Server release
5.4 (Tikanga), or OpenSuse 11.4, or Solaris 9 (but not, ironically, Solaris 11,
which refuses to install itself onto my SCSI disks -- go figure). Several problems
remain, but at this point this thread should perhaps migrate to another forum,
since the questions are no longer Redhat-specific, except the question of why there
is no Redhat-supported RPM for the new GRUB, when it is so much better than "Legacy
Grub". Just the "ls" command alone, I think, should be reason enough for Red Hat
to upgrade to the new GRUB -- have you not cursed the old GRUB countless times for
lacking an "ls" command? -- and yet, RedHat, for some inscrutable reason, has not
done so.

Did I say "so much better"? Pas tout-à-fait. "Better' it may be, in the sense that
it has more features, but it is not easier to configure. After building and
installing the new GRUB, I found that I had to write a grub.cfg file to take the
place of the menu.lst file, and it took hours of trial and error to do so (e.g.,
the open-curly-brace that begins a menu had better be at the end of the menuentry
line, not the beginning of the next line, and the title of the menuentry had better
be surrounded by quotes, even though there's nothing in the documentation that says
so). Nearly all the commentary on the World Wide Web -- or, at least, all the
commentary that can be found by search engines -- is not about writing a grub.cfg
file at all, but, rather, about writing some other file, e.g., /etc/default/grub,
from which a grub.cfg file can be partly generated, and there is no discernible
relationship between what a blogger advises you to put in /etc/default/grub, and
what you actually have to put in /boot/grub/grub.cfg to get your desired results.
The official documentation is, in some places, almost useless. Thus, the official
documentation will tell you that there is a "set" command, and tell you its syntax,
but it does not list any of the predefined variables that you can set, nor tell you
the meaning of their values. Since half the functionality of a grub.cfg file lies
in setting variables to the right values, this is an egregious lacuna in the
documentation.

As promised in the title to this posting, some problems remain, and I pray that
the gentle reader will be able to help me solve at least one of them: How do I
set the background image? With the old, legacy grub, whatever its limitations,
the answer was simple: all you needed to say was

splashimage=(hd0,0)/grub/splash.xpm.gz

and that was that. With the new grub, you must use the background_image command
rather than the splashimage command, and it also seems that you must convert your
xpm file to either jpg or pnm format, but that is not enough, nor even close to
enough. With the new grub you have to maybe load some modules, and maybe set
the type of terminal output, and maybe activate a video mode, and maybe load some
fonts. I have gone back to the search engines again and again, and I can find nothing
that works. When I issue the command

background_image (hd0,1)/grub/splash.ppm

(yes, I incremented the slice number, thank you for asking), GRUB issues the diagnostic:

error: no video mode activated.

and even after typing

insmod gfxterm
insmod vbe
background_image (hd0,1)/grub/splash.ppm

the diagnostic message is unchanged.

If, after typing the two "insmod" commands, I type

terminal_output gfxterm

so as to activate a video mode, the screen goes dark, and, despite having
received only a "terminal_output" command, GRUB no longer reads from the keyboard,
as typing "reboot" at that point has no effect, there seems to be nothing to
do but power-cycle the computer. Perhaps a font should have been loaded prior
to the "terminal_output" command, but I tried loading a font that was mentioned
on some page to which a search engine had directed me, and was unable to do so.

How, then, does one set the background image using the new GRUB? If you are using
the new GRUB, and you have a background image, what does your grub.cfg file look like?
I thank you in advance for your replies.

jay at m5 dot chicago dot il dot us
+1 773 7613784