On Wed, May 19, 2010 at 02:50:42PM -0400, crop...@acm.org wrote: > > > Ok, more data... old school capture (pen and paper!)
thanks a lot that made the picture much clearer. > _____________________________________________ > Preparations: > > 1) Reinstalled most recent initramfs-tools version > 2) executed "update-initramfs -c -k all" > 3) executed "update-grub" > > _____________________________________________ > GRUB menu at boot: > > linux /vmlinuz-2.6.32-3-amd64 root=/dev/mapper/md1_crypt ro debug=vc > rootdelay=12 > echo Loading initial ramdisk > initrd /initrd.img-2.6.32-3-amd64 > > _____________________________________________ > Kernel output (LITERAL DATA, except for "... area below"): > > [1.185516] rtc_cmos 00:0a: setting system clock to 2010-05-19 18:18:27 UTC > (1274293107) > [1.185628] Waiting 12sec before mounting root device > [1.199432] input: AT translated Set 2 keyboard as > /devices/platform/i8042/serio0/input/input1 > [12.992053] List of all partitions: > [12.992128] No filesystem could mount root, tried: > [12.992221] kernel panic - no syncing: VFS: unable to mount root fs on > unknown wn-block(0,0) > [12.992287] Pid: 1, comm: swapper Not tainted 2.6.32-3-amd64 #1 > [12.992340] Call Trace: > [12.992397] [<ffffffff812ed349>] ? panic+0x86/0x141 > ... ... ... > ... ... ... > [12.992880] [<ffffffff81011ba0>] ? child_rip+0x0/0x20 aboves says that linux-2.6 is not getting the initramfs. thus indeed blaming GRUB seems the current state of affair. > _______________________________________________ > Observations and opinions: > > This output format really has NOT changed in the days we have been messing > with this problem. > > 1) the RAID is NOT starting > 2) it never gets to the crypto (not started either) > 3) no USB/firewire devices are detected (no evidence of drivers loading) > 4) no block devices (Hard disks, CDROMs, etc) are detected (no evidence of > drivers loading) indeed 1-4 can't happen if initramfs is not unpacked. strange that size seems not the issue: ls -lrt img-2.6.32-3-amd64.* -rw-r--r-- 1 maks maks 9458502 May 19 04:32 img-2.6.32-3-amd64.working -rw-r--r-- 1 maks maks 9665786 May 19 04:32 img-2.6.32-3-amd64.broken also qemu just unpacks fine the "broken" one and it's good for file too: file img-2.6.32-3-amd64.broken img-2.6.32-3-amd64.broken: gzip compressed data, from Unix, last modified: Wed May 19 01:49:38 2010 > _______________________________________________ > > Questions: > 1) Could this be grub? > 2) Could "resynchronizing" md0 fix this problem? I seem to remember doing > something like this and the problem went away in March... :-/ > 3) Any other suggestions? adding GRUB maintainers to Cc as this new bug report seems to be a recurring trend. #578473 seems to be duplicate of that one. GRUB maintainers can you advise? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org