8.04-1 won't boot from degraded raid

[Soren Hansen]

On Tue, Aug 26, 2008 at 04:22:18PM -0600, Sam Howard wrote:
> Thanks for the follow up ... I suspected that you had just typeo'd
> your example scenario, but wanted to clarify it for me and everyone
> else following along.

Sure. Thanks for catching it and pointing it out.

>> I hear you. All my servers are, in fact, remote. I'm however in the
>> happy situation that if a machine fails to come online after a
>> reboot, I can boot up a RAM-based rescue system from whence I can
>> diagnose the system. I realise you might not be as fortunate.
> I'd like to hear more about this ... your own, proprietary, or open
> source, or ???

Not my own. It's offered by my hosting provider. They have a web
interface, from whence I can reboot the system,  either sending a
ctrl-alt-delete or by pressing the reset button. Both happen
automatically. I have no idea how they implement it. On that
webinterface, I can also choose to have my server boot a rescue system
the next time it starts up. This presumably sets up their DHCP server to
offer this RAM based system to my server, which then goes on to PXE
boot. The RAM based system is Debian Etch, by the way.

My previous hosting provider had a similar service, so I actually
thought this was wide spread.

> For these new Hardy servers I'm building, I'm playing with the idea of
> booting off of a USB stick, but USB is _slow_ and the read-write
> nature of a running system (even just the Xen server host) would
> likely cause rapid failure of the USB sticks.  My next wild idea was
> to build a 3-way RAID1 for the root disk (USB + 2 internal HD
> partitions of 2.1GB), sync everything, then pull the USB ... plug it
> in weekly to sync up and then yank it again.

Heh :) Well, yes, that would work :)

> I was hoping to avoid a situation we had a few months ago where an apt-get
> (or some function in a post-install) "fixed" the grub menu.lst and caused
> the server to not be bootable anymore.

I'd very much like to hear more of this incident? Do you remember in
what way the menu.lst was changed?

>> I understand. The perfect solution for me would be an ssh server in
>> the initramfs so that I could ssh into the server and take a look
>> around, reassure myself that the faulty disk has been properly
>> identified, etc., etc. and then take appropriate action.
> yeah, having network smarts and ssh (on an alternate port since you
> might not be able to read the ondisk password file?) would be great!

I imagine an initramfs hook would take care to copy /etc/{shadow,passwd}
entries for members of the admin group to the initramfs (possibly
changing their uid to 0 to avoid sudo in initramfs).

>> This is all very valuable input. It's good to have some leverage when
>> we engage in the discussion about perhaps getting this functionality
>> pushed back into hardy.
> My big push to my customers for Ubuntu *is* the LTS feature ... many
> of them have been burned by un-supported, and un-upgradable RH systems
> (I've got a few 6.2 systems out there still ... ugh).  Getting what I
> would consider a mission critical feature for a SERVER pushed back
> into the LTS server release would be very valuable to the argument
> that Ubuntu is "Enterprise Ready" and willing to add the necessary
> features to run "Mission Critical" applications on.

Thanks for your input.

-- 
Soren Hansen               | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd.             | http://www.ubuntu.com/