[gentoo-amd64] Re: grub and maximum kernel file size

[Duncan]

Branko Badrljica <brankob@××××××××××.com> posted
49DE51A0.7010408@××××××××××.com, excerpted below, on  Thu, 09 Apr 2009
21:50:56 +0200:

>> Yes, for LVM, no, for RAID, at least md/mdp kernel RAID.
> In theory, yes. In practice, it is unpredictable and flakey. I lost more
> than a day with a system that used to be able to autoassemble the RAID
> in kernel and boot it and then simply "changed its mind" and no matter
> what I did, it wouldn't boot from RAID. No available diagnostics is
> another hamper, since dmesg can tell you little about what exactly went
> wrong.
>
> In all those cases starting RAID manually went fine.

Hmm... perhaps I've been lucky.  Here I'm as much verifying my own setup 
based on your experience as discussing yours.

Did you try md-mod,start_dirty_degraded=1 (AFAIK this applies to 
RAID-4/5/6 only)?

What about listing the appropriate component devices, as so:
md=d1,/dev/sda1,/dev/sdb1,/dev/sdc1... ?

Since I use mdp (partitioned), I've never relied on the kernel autodetect 
and have always fed it the devices to assemble into the partitioned RAID 
device root is on (the second question).  I've never had to use the magic 
in the first question, but noted the documentation on possibly needing it 
if the RAID-4/5/6 device is both dirty AND degraded, so put it (along 
with various other "magic" incantations) in a file I can access from grub 
for help, should it be necessary.  (FWIW I used to have them all as grub 
entries directly, but decided that was getting unmanageable.)

If you had both those ideas where you could get at them and tried them, 
and they didn't work, perhaps my setup isn't as good as I think it is, as 
I've always assumed that even if I couldn't get in with one kernel, I 
could always reboot and try the previously working kernel, and along with 
the various associated kernel commandline RAID options, could get it 
working.  If for whatever reason that failed, I figured the disks would 
be forensic recovery material.  I have indeed always been able to boot 
without serious issue so far, but if I have just been lucky...

> It is nice to be able to use initramfs as some sort for
> backpack/first-aid-kit/MCGuyver's_toolshed when all else fails.
>
> It isn't always simple to boot from another media, especially if you
> need that particular kernel etc.
>
> That's why initramfs is cool. If the system is in good enough shape for
> grub to grab kernel and initrd, it can run diagnostics and maybe offer
> some fundamental services ( like named,dhcpd, routing, firewalling etc).

That's true, but my point is, by the time you setup all that complexity, 
you're almost setting up AND CONFIGURING a whole little mini-distribution 
inside your initramfs/initrd.

What I've chosen to do instead is do without the initrd, and effectively, 
make my whole working system (sans user config and data), not just some 
subset of it, available as my troubleshooting toolbox.

What I mean is that periodically, I snapshot/copy off my root (which 
includes everything that portage installs and its database so most of /
usr and some of /var, all installed system binaries, scripts, and config) 
to an identically sized rootbak partition.  (In this case it's another 
partition on the mdp/RAID, thus the weakness implied above if it should 
not be bootable by any available kernel, even with the appropriate 
options.)  I can then continue updating the working root partition as I 
normally would.

When things go wrong and I'm unable to boot the main partition, I can 
thus boot to rootbak and get the system, fully configured and functional 
as it was at the time I took the snapshot, and use it to recover the main 
system.  Since it's fully functional, as long as I've not let it get
/too/ outdated, it loads the LVM and mounts /home and all the usual 
partitions (or I can reconfigure it to mount the backups instead), and 
while I might be stuck with a KDE say a minor release or so back due to 
the age of the backup snapshot, I get full X and everything I had then, 
plus mail, bookmarks, etc, I've saved since then, full net access, etc.  
That's far better from my perspective than the limited toolbox an 
initramfs/initrd would provide, particularly since invariably, I'd find I 
was missing the ONE tool I needed if I WERE running a limited one.

I've actually used this from time to time as well.  When a new ~arch bash 
failed to boot was one such time; the time the new glibc combined with a 
new portage to screw symlinks, thus glibc, thus the entire working 
system, was another.  Running the then very new OpenRC and having it 
screw up was yet another.  In all cases, I was able to simply boot to my 
backup snapshot (using the root= kernel commandline parameter) and use it 
to recover my normal working partition.

There was /one/ time I got caught without a working grub and had to 
install an old version of Ubuntu (5.something!) off an old CD I had 
floating around, and point its grub at the normal Gentoo grub.conf, but 
that's the only time I've had to boot from an actual CD to rescue things, 
and you can be sure I keep several tested-working GRUB floppies around 
now, should I need them.

But, there's a couple things I'd do differently now if I were arranging 
my setup with what I know now.  (1) I'd create three root partitions, 
working and two backups instead of just one, so if the system happened to 
crash when I was updating one and neither it nor the normal working copy 
would boot, I'd have a second fallback.  (2) I'd also put those 
partitions on separate RAID devices, not just separate partitions on the 
same RAID device.  That way, if one RAID device was entirely 
unrecoverable, I'd use another. (3) /boot is currently on a single 
RAID-1, of course the only RAID grub understands.  I have four spindles 
and would create two, two-disk RAID-1s or even four separate /boot 
images, so screwing one wouldn't automatically screw the others as it 
does now.  (That's the other take-away from the Ubuntu rescue episode.)  
(I'd also probably use more but possibly lower capacity spindles, but 
that of course doesn't really apply to the rescue context.)

>> user-vesa-framebuffer, I take it?  FWIW, I'm running radeonfb here.
>>
> Well, I have nVidia and have _never_ seen any card on which rivafb
> works. vesafb did work on some older cards, but not on 8800GT ( which is
> getting into age also). So uvesafb is only thing that works for me, at
> least until nvidia unifies linux driver or something like it...

Ugh!  Back when I first switched to Linux, I had done my research well 
enough and had been considering it and vetting my hardware purchases 
against it long enough that I knew all my hardware was Linux compatible, 
had Linux drivers, etc.  Unfortunately what I did NOT grok at the time 
(researching it from MS Windows BEFORE the switch) was the difference 
between "Linux" drivers and "native Linux", aka "freedomware" drivers.  
As a result, I purchased an nVidia card shortly before I made the switch.

I quickly groked my mistake, but didn't have the budget to fix it for 
awhile.  But since then, every upgrade has been a Radeon, as the best 
native/freedomware supported hardware available as an add-on card.

I won't be doing nVidia any time soon.  Not until they come around to 
properly cooperating with the FLOSS community.  YMMV and I know a lot of 
gamers especially value their games above their freedom.  That's not my 
life and not my systems and therefore not my call, but what I run here 
IS, and if I wanted to be stuck with proprietaryware, I'd have not 
bothered dumping a decade's worth of experience on MS to start over with 
Linux!

Besides, since I don't sign EULAs and can't agree to the damage waivers 
pretty much all software (including freedomware) comes with if the code 
isn't free for me to actually examine and/or have a coder I trust examine 
to make that decision (/that's/ the freedomware difference), then it's 
either illegal or not affordably defensible to run proprietaryware even 
if I DID want to.  Thus, I don't run them, and can't run nVidia drivers, 
since they fall in that category.

Anyway, if you're stuck with it having known no better when you got it, I 
was there for a time and can certainly sympathize.  I hope you find the 
budget for an upgrade to something with better freedomware support soon.  
However, if it's a choice you made knowing the consequences, well, what 
can I say but it's your choice, for better or for worse, and this appears 
to be one of the "for worse" bits.

Plus, I can blame you and those like you for holding up progress on xorg 
and the desktop environments, among other things, since there's a 
continual drag placed on further progress due to the delay in support 
from the proprietaryware graphics vendors.  It's not my system and not my 
decision, and I know people have their reasons, but I also know the 
delays the popularity of the proprietaryware vendors means, and believe 
in calling it as I see it -- due to their popularity, they hold 
freedomware progress ransom to their whims.  Honestly speaking but 
nothing personal, if I had my way, freedomware would NOT hold up its 
progress for them, even if it meant they were stuck back with xfree86 
vintage X because that's all the proprietary folks decided to support.

-- 
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