Bug#582342: Let's try to figure out bug #582342 finally

[Cropper, C. A.]

> your Debian bug #582342[2]  has been on my todo list for quite some time
> now - let's try to finally figure this out! I do have a similar setup,
> with / on a luks-encrypted raid6 and /boot on raid1, the only difference
> seems to be that I'm still using MBR while you've already switched to
> GPT. Since my setup works fine I'm confident that we will be able to
> solve your problem together!
> 
> First let's make sure I get the facts right:
> 
>  * You've filed bug #582177[1] against initramfs-tools and #582342[2]
>    against grub-pc

Correct.


>  * For both bugs you are apparently the only one who experiences them

It appears so...


>  * the main symptom of these bugs is that your system doesn't boot
>    anymore

My system would not boot the 2.6.32-5 kernel...
... it would work fine with the 2.6.32-3 kernel using a BACKUP initrd image.


>  * Does your system still have problems booting?

Nope.  I COMPLETELY rebuilt the system using the October 22 Squeeze image.  
The problem appears to have gone away.   I completely rebuilt it because I had 
to get it working (I am more of a power user that tries to use Linux to make a 
living and, accordingly, am not is savvy with programming and hacking in the 
system...)


> 
>  * If so, what problems *exactly* do you have?

I will answer this in the past tense (see above).  The problem had something 
to do with i) grub opening the initrd image, ii) the new UUID naming system, 
and/or iii) the new concurrent-based booting system.


>  I've been
>    reading both bug reports but have been unable to determine
>    in what stage your system fails to boot.
>    So
>    * do you get to the GRUB screen

Yes.

>    * do the kernel and the initramfs get loaded by GRUB

NO, it would fail at this point.  It works now (vide supra).


>    * do the kernel and the initramfs boot correctly

It would never get to this stage.


>    I need the exact error messages to help you. A screenshot might also
>    be a good idea.

The closest I can give you now is the literal message I posted under the 
initramfs bug report (it was exactly what was on my screen except for "..." 
which represent kernel trap/traces that were intelligible to me).

> 
>  * I'd like to merge #582177[1] and #582342[2] so that we can focus on
>    one bug report instead of spreading the information across multiple
>    bugs. Overall this seems to be just one problem and we can always
>    unmerge them later if necessary. Any objections?

No objections.  They are really only one bug; it is probably under GRUB.


>  * You mentioned that your problems have disappeared and then
>    reappeared after some hardware rearrangements:
>    * Do you remember what you did exactly?

Moved SATA DVD-burners OFF the LSI SAS bus (mptsas driver) so only hard drives 
were present on the SAS bus.


>    * Can you make the problem disappear/reappear again?

The problem reappeared after I did some kernel updates via aptitude during the 
summer 2010; it persisted after I moved the SATA DVD-burners back ONto the LSI 
SAS bus.


>    * Are you sure that it's not some HW/BIOS issue?

No, I am not sure except I have THREE other machines with the same hardware 
and they do NOT have any problems.  My machine, however, is the only machine 
with encrypted hard disks.


>  * What method/steps do you currently use to boot your system?

When I has having the problems I would open the grub menu with Ctrl-e and 
modify the multi-user boot line of the 2.6.35-3 kernel to boot a BACKUP image 
(initrd......2.6.32-3.bak) by appending ".bak" to the initrd line.  I had 
already created the backup initrd images previously.
 


>  * Does it help if you run
>     dpkg-reconfigure grub-pc
>    when your system is up and reinstall grub to every harddrive to want
>    to boot off?

No, did this before... multiple times.  No change.



> 
>  * Does it help if you run
>     update-initramfs -u
>    when your system is up to make sure you have a clean initramfs?

No; it made no difference.  I eventually tried
      update-initramfs -c -k all
after backing up the original image to create a new image and then running
      update-grub
I still had to use the steps above to boot the machine.

> 
>  * Is your squeeze system up-to-date?
>  There have been quite some
>    bugfixes recently which might affect your system, for example mdadm
>    bug #583917[3] and friends.

I tried the final time around October 20th.  The machine would still not boot 
kernel 2.6.32-5 at that time.  I backed up may data and erased the system and 
rebuilt it from the ground up around October 25th.



> 
> So, that's all I can think of right now - I'm looking forward to reading
> your detailed answers!

Hope this helps.  I still think what ever was the problem still is in GRUB and 
relates to the UUID names and software raid setups.  Unfortunately, I cannot 
do anymore testing for you now.

Let me know what else I can do.


C. Cropper