i noticed that the 4.4 upgrade broke LILO on Raid...
it gave errors on partitions not on the primary disk
along the lines of "/dev/dis: no such device"...
even explicitly installing the boot sector on each
device in the array, while it allowed the system
to boot, gave errors at boot time and did not
display the CentOS boot screen anymore...
i solved the problem by creating a package for the
most recent version of LILO and installing that...
with a few minor changes to "lilo.conf" everything
was kosker for LILO install and boot...
i even made a nice new 640x480x256 CentOS boot
screen for it...
there is one caveat to using the new LILO...
the new version (or at least one above 22.x) must be
booted once (text-mode) before LILO can correctly
probe the video BIOS...
so, the boot screen needs to be installed after
an initial priming boot...
afterwards, i did some thorough testing before deploying
on any production servers... and noticed only one problem...
the new version of LILO broke the "grubby" probe...
primarily because "/boot/boot.b" is no longer needed...
but also because the comparisons between "boot.b"
and the actual boot sector aren't accurate anymore either...
since i'd noticed that "grubby"'s probe for GRUB itself
has been broken for a while... i decided a quick
patch-job for the "mkinitrd" package was in order...
my new package correctly identifies whether either
LILO or GRUB has been installed at all, but lacks the
careful byte comparisons that were the core of the
breakage of the original "grubby"...
it's possibly problematic... but i doubt it... and it
solves more problems than it creates...
anyways... that solved my 4.4 upgrade breakage...
and... since i was writing to the list... i figured i should
mention a rather serious, but extremely unlikely to happen,
bug i noticed in "e2fsprogs" (specifically "e2fsck")...
with the version on CentOS... "e2fsck" will cause some big
problems and potential data loss on directories containing
more than 1.2 million inodes...
the first 1.2 million inodes will be ok...
the next 1.2 million (max) will be saved to /lost+found
as unidentified files... before it too fills up...
and then everything else will just "vanish"...
this problem is due to some incorrect math in the handling
of the maximum inode size... and has already been fixed
in e2fsprogs 1.38...
so, my solution was to take the 1.38 Fedora Core sources
and build a package for CentOS...
if anyone is particularly interested... i have the SRPMS
for my lilo, mkinitrd, and e2fsprogs packages...
also, i have the pretty new CentOS boot screen (and a few
others i made) and some working lilo configurations for
switching over to them...
all of which i could probably post somewhere public...
but if they are really useful, i'd rather ship them along to
someone more closely involved in maintaining CentOS...
so as to "contribute" as best i could to everyone's future
well-being as well...
B. Karhan
simon@xxxxxxxxxxx
PRI/SSRI Unix Administrator
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
