--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: itramfs-tools doesn't produce working ramdisk on amd64 with MODULES=list
- From: Ivan Sergio Borgonovo <mail@webthatworks.it>
- Date: Mon, 7 Aug 2006 13:06:44 +0200
- Message-id: <20060807130644.3f6400e7@localhost>
Package: initramfs-tools
Version: 0.73c
Severity: grave
amd64-smp
System doesn't boot. Error message is "Waiting for root file system... device /dev/md3 does not exist".
I've built initramfs by myself to solve some boot module problems and mdadm md device order problem recently, so I know that just the previous version worked.
I just made an aptitude update/upgrade and the only package that could be related to a non booting box is initramfs-tools.
The non smp kernel on this system could still boot but was not updated in the process of updating initramfs-tools.
I tried to rebuilt manually another ramdisk but even the new one (with unchanged setup compared to a working one that was generated with the previous initramfs-tools) didn't work.
The size of the "not working" new one doesn't look as it is missing modules. It is even comparably larger than the one I fortunately left in my /root dir and that I'm currently using.
I've no idea on how I could collect more info to help solving the problem.
105c105
< $message = t("Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your %directory directory which contains the following lines: <code>%htaccess</code>", array('%directory' => theme('placeholder', $directory), '%htaccess' => '<br />'. str_replace("\n", '<br />', check_plain($htaccess_lines))));
---
> $message = t("Security warning: Couldn't write .htaccess file. Please create a .htaccess file in your %directory directory which contains the following lines: <code>%htaccess</code>", array('%directory' => theme('placeholder', $directory), '%htaccess' => '<br />'. str_replace("\n", '<br />', check_plain($htaccess_lines))))
--- End Message ---
--- Begin Message ---
Version: 0.75
On Tue, 22 Aug 2006, Ivan Sergio Borgonovo wrote:
> What happened was:
> a) wrong order of md so /home got mounted in spite of / (somehow fixed, it seems it was a mdadm problem but I can't reproduce it)
> b) devices didn't mount but once left into the busybox shell I was able to mount them manually
> so every time I was drop in busybox ALL the modules needed WERE there I never had the need to modprobe ANY module manually
> *This exclude it was a module related problem*
> What I had to do was just
> mkdir /z; mount /dev/mdN /z
> or
> mkdir /z; mount /dev/md/N /z
> as you may notice device name was different depending on initramfs-tools version
ah ok that makes it clearer.
> > so i really that debug output from an default initramfs
> > with MODULES=most and the output of the following commands
> > after your are dropped into shell
> > ls -l /dev
> > cat /proc/mdstat
>
> > if you trouble are cured in between due to newer mdadm
> > hooks i'd also be happy to know about.
>
> Upgrade to 0.74 didn't solve the problem.
> Commenting out /etc/udev/rules.d/z60_mdadm.rules partially fixed the problem since I got trapped in another bug
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383555
yeah sorry, had not much time to provide a fix for that.
> I did report to you and cc to bugs.debian.org on 19 Aug. My message didn't reach the list. Since I didn't receive any bounce... (or maybe it got filtered too by anti spam or whatever) I thought at least you received news.
> If you didn't receive that mail I can resend it to you so you can track down what the cause of the problem really *was*.
>
> I just did an update/upgrade and these notable packages got in:
> busybox
> udev
> initramfs-tools
>
> I *can* boot with stock kernel and stock initrd.
> Even 383555 seems fixed.
>
> I'd consider the problem solved.
great closing
best regards
--
maks
--- End Message ---