[gentoo-amd64] Re: RAID1 boot - no bootable media found

[Duncan]

Mark Knecht posted on Tue, 30 Mar 2010 06:56:14 -0700 as excerpted:

> 3) I LOVE your idea of managing 3 /boot partitions by hand instead of
> using RAID. Easy to do, completely testable ahead of time. If I ensure
> that every disk can boot then no matter what disk goes down the machine
> still works, at least a little. Not that much work and even if I don't
> do it for awhile it doesn't matter as I can do repairs without a CD.
> (well....)

That's one of those things you only tend to realize after running a RAID 
for awhile... and possibly after having grub die, for some reason I don't 
quite understand, on just a kernel update... and realizing that had I 
setup multiple independent /boot and boot-backup partitions instead of a 
single RAID-1 /boot, I'd have had the backups to boot to if I'd have 
needed it.

So call it the voice of experience! =:^)

Meanwhile, glad you figured the problem out.  A boot-flag-requiring-
BIOS... that'd explain the problem for both the RAID and no-RAID version!

100% waits for long periods...  I've seen a number of reasons for this. 
One key to remember is that I/O backups have a way of stopping many other 
things at times.  Among the reasons I've seen:

1a) Dying disk.  I've had old disks that would sometimes take some time to 
respond, especially if they had gone to sleep.  If you hear several clicks 
(aka "the click of death") as it resets the disk and tries again... it's 
time to think about either replacing the old disk, or sending in the new 
one for a replacement.  

1b) Another form of that is hard to read data sectors.  It'll typically 
try to read a bad sector quite a number of times, often for several 
minutes at a time, before either giving up or reading it correctly.  
Again, if you're seeing this, get a new disk and get your data transferred 
before it's too late!

2) I think this one was fixed and I only read of it, I didn't experience 
it myself.  Back some time ago, if a network interface were active using 
DHCP, but couldn't get a response from a DHCP server, it could cause 
pretty much the entire system to hang for some time, every time the fake/
random address normally assigned from the zero-conf reserved netblock 
expired.  The system would try to find a DHCP server again, and again, if 
one didn't answer, would eventually assign the zero-conf block fake/random 
address again, but would cause a system hang of upto a minute (the default 
timeout, AFAIK), before it would do so.  Again, this /should/ have been 
fixed quite some time ago, but one can never be sure what similar symptom 
bug may be lurking in some hardware or other.

3) Back to disks, but not the harbinger of doom that #1 is, perhaps your 
system is simply set to suspend the disks after a period of inactivity, 
and it takes them some time to spin back up.  I've had this happen to me, 
but it was years ago and back on MS.  But because of the issues I've had 
more recently with (1), I'm sure it'd still be an issue in some 
configurations.  (Fortunately, laptop mode on my netbook with 120 gig SATA 
hard drive seems to work very well and almost invisibly, to the point I 
don't worry about disk sleep there at all, as the resume is smooth enough 
I basically don't even notice -- save for the extra hour and a half of 
runtime I normally get with laptop mode active! FWIW, the thing "just 
works" in terms of both suspend2ram and hibernate/suspend2disk, as well.  
=:^)

4) Kernels before... 2.6.30 I believe... could occasionally exhibit a read/
write I/O priority inversion on ext3.  The problem had existed for 
sometime, but was attributed to the normal effects of the then default 
data=ordered as opposed to data=writeback journaling, until some massive 
stability issues with ext4 (which ubuntu had just deployed as a non-
default option for their new installs, the problem came in combining that 
with stuff like the unstable black-box nVidia drivers, which crashed 
systems in the middle of writes on occasion!) prompted a reexamination of 
a number of related previous assumptions.  2.6.30 had a quick-fix.  2.6.31 
had better fixes, and additionally and quite controversially, switched 
ext3 defaults to data=writeback, which with the new fixes, was judged 
sufficiently stable to be the default.  (As a reiserfs user who lived thru 
the period before it got proper data=ordered, I'll never trust 
data=writeback again, so I disagree with Linus decision to make it the 
ext3 default, but at least I can change that on the systems I run.)  So if 
you're running a kernel older than 2.6.30 or .31, this could potentially 
be an issue, tho it's unlikely to be /too/ bad under normal conditions.

Those are the possibilities I know of.

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