[ale] initramfs capable of a multi-device btrfs / new initramfs with dracut help?

[Michael B. Trausch]

On Mon, 2010-07-19 at 23:29 -0400, Pat Regan wrote:
> On Mon, 19 Jul 2010 00:32:40 -0400
> "Michael B. Trausch" <mike at trausch.us> wrote:
> 
> > but I am pretty sure it was the OS/2 bootloader program) that had as a
> > requirement a dedicated partition just for it.  I think that the ideal
> > bootloader would keep this requirement.  You could then afford to
> > have a slightly larger bootloader that understood things like the
> > types of software RAID used by various operating systems such as
> > Linux and the BSD family of operating systems, and be able to boot
> > from them all without a terribly large amount of effort.
> 
> How is putting the bootloader on a separate partition significantly
> different than putting the kernel and initrd on a separate partition?  

The idea would be that the bootloader has no dependency on the OS, nor
the OS' filesystem.  That would also make it amenable to be placed on a
truly read-only device, such as a ROM chip, a locked SD card, or
whatever.

The second added bonus is that would mean that you don't have the
inherent limitations that bootloaders have.  A truly portable bootloader
running on the IA-32, AMD64, or Intel 64 platforms can only make the
assumption that it has 446 bytes of space at sector zero in any given
partition.  Unless the bootloader has a partition for itself, that is.

GNU GRUB gets around this, as an example, by installing itself on the
Linux /boot partition.  That means that the filesystem that
houses /boot, whether that is the root filesystem or a dedicated
filesystem, must be able to be read by GRUB.  For those who remember
and/or still use the LILO boot loader, it solves that problem by being
very tiny and using a block list, so that it can be filesystem agnostic.
That is, IMHO, another nasty way to solve that problem.

Perhaps really what I would like to see is not having a bootloader even
be required anymore.  We can fit enough stuff on chips these days that
we ought to be able to have computers themselves do the bootloading for
operating systems.  Oh, imagine what a world that would be... A
"multiboot computer" that would be able to boot any operating system
that adheres to the multiboot specification, possibly making exceptions
for individual and well-known operating system kernels like NTOSKRNL.EXE
or Linux.

> > This would make it possible to do something like have a read-only SD
> > card or similar flash device contain the bootloader (or, for that
> > matter, for the bootloader to be placed in a decently sized firmware).
> > It could afford to understand a wide variety of filesystems and
> > storage formats, including LVM2, BSD disklabels, and the various
> > types of software RAID used by different operating systems.
> 
> Then it becomes a single point of failure.  I'd rather have my
> bootloader on all my drives and my kernel and initrd on a raid 1, like
> we already do.
> 
> I've always been one to champion the durability of flash but I had to
> RMA my X25-m twice in the first 6 months.

Eh.  A 128 MB SD card would be sufficient (as a Linux /boot partition,
that is) if you don't keep too many dusty old kernels around or aren't
someone who rebuilds the kernel frequently without sweeping up the
cruft.

But for a bootloader?  I can't imagine that you'd need anything much
larger than 8 MB for its storage (GNU GRUB 2 is ~4 MB and supports a
*lot* of filesystems, as an example), unless you are talking about a
much heavier environment like EFI.  However, we've seen how well *that*
has caught on in the x86 world... well, who am I kidding, this thread
isn't going to change anything, anyway.  ;-)

> > Anyway, this particular email has gotten to be far too long, so I'll
> > end it now... later!
> 
> I'll take this as my turn to voice my complaint about software raid...
> 
> I'm never certain what is going to happen when a disk dies, especially
> if it is the first disk.  Is the drive dead enough that the BIOS is
> going to skip it during the boot process?  Is it alive enough that the
> BIOS might try to boot it?

Personally, I don't RAID the operating system itself.  I will backup the
operating system partition on occasion, but it's not a critical thing
since it can be regenerated; it's more important to me to ensure that I
can bring the system back to an identical state from install media and
data in my ${HOME}.  I keep the data as separate as possible, and that
is always backed up.  At this point, the only mode of failure that I'm
vulnerable to is a nuclear bomb hitting Atlanta and wiping out all of
the life in the metro area---obviously, if something that catastrophic
happens, I have more important things to worry about than my client's
data.  Or rather, I'll not have anything to worry about at all.

If I *must* have a very reliable boot-up process, the only thing I have
used for that is on-board "fake raid" to mirror the drives.  Nobody I
service is willing to pay big bucks to keep the operating system
protected from disk failure that way, since it isn't critical business
data.  For that matter, the chance of a disk failure being über-critical
isn't all that great, at least not on the machines I run.  If the system
boots up, the system/boot drive can die and everything I need is already
running in memory---and reboots *never* happen during critical hours.
(That is to say, if a power outage lasts long enough for a reboot to be
required, then there's already downtime...)

> If I'm using software raid it is very likely to be in a lower end
> machine.  It probably doesn't have swappable drive cages, so I'm going
> to have to bring it down to replace that boot drive.  If I put a blank
> drive in there is the BIOS going to tell me no OS found?  It will
> likely depend on the machine...
> 
> I only mention this because I've been thinking about it today.  I'm
> planning to drive out to replace the boot drive in a colocated machine
> of mine.  I saved a few bucks buying a server with no hot swap cages.
> If I could hot swap, I could just pop the drive in an reload grub.

I always go with an Ubuntu Live CD and a server install disc---and a
duplicate of the most recent data backup, when possible in a
drop-in-ready form.

> I'm being paranoid, I dd-ed down a copy of the drive up to the end of
> the /boot partition and dd-ed it onto the replacement drive.  :)

You could keep a local mirror, rsync'd daily... wouldn't change that
much, but worthwhile if you forget to run a backup immediately after
changing it (or automatic updates of any fashion are enabled, which I
should think not, but that's just my own opinion).

	--- Mike