e.waelde wrote: >> Hello, >> >> my main workstation runs its root-filesystem on lvm >> on crypt_luks on raid1 (software raid). Everything >> works flawless with kernel-image-3.2.0-4-amd64 >> >> However, all later kernels that I tried fail to boot, >> e.g. kernel-image-3.10-3-amd64 >> + grub2 starts the kernel >> + the kernel starts quering all hw. >> It somehow fails to assemble the raid, it seems. At least >> I do not see any raid related messages (even after adding "verbose >> debug" to the kernel argument list. >> >> I inspected the contents of the initial ramdisks (3.2 and 3.10) and did >> not find anything sufficiently different in conf, etc, scripts. >> >> Can anyone confirm this setup is working on amd64 with kernel 3.10 say? >> >> Any pointers, on how to better debug this? I once managed to get a shell >> in the initramfs stage. I could load raid1, assemble the raid manually, >> luksOpen the crypted partition, start lvm ... but the I did something >> which locked the system (unfortunately I cannot remember, how I got >> there). Unfortunately all further attempts to drop into a shell in >> initramfs have failed on me. >> >> FWIW: I was able to reproduce this problem by installing wheezy on two >> empty disks, then upgrade to unstable and trying to boot the newer kernel. >> So I suspect I missed something during the upgrade ... >> >> cpu: AMD Phenom(tm) 9550 Quad-Core Processor >> disks: connected through SATA >> OS: Debian unstable >> >> >> Any ideas on how to proceed? >> >> Erich >> >> > Hi no one answered for a while so I will try to help > > I had similar issues but lets get a common ground > > I assume you have a plain boot partition and encrypted lvm on raid where > your other partitions reside. This would be the recommended setup. > > So after installing a new kernel (and initramfs file) there are few cases > where it can go wrong. > > 1. the initramfs is not recreated or not recreated properly. > -> check for this your /etc/initramfs-tools config files > -> make sure the modules (md etc) are included in the initramfs > (In my setup the raid modules are compiled in the kernel) > > /etc/initramfs-tools/modules > # List of modules that you want to include in your initramfs. > # > # Syntax: module_name [args ...] > # > # You must run update-initramfs(8) to effect this change. > # > # Examples: > # > # raid1 > # sd_mod > dm-mod > loop > > -> boot with a working kernel and recreate the initramfs file for the 3.10 > kernel > > 2. It can fail because of switching from /dev/sd* to UID > -> check here the grub.cfg or menu.lst files in /boot/grub > > 3. I was getting frequently > root (hd0,msdos1) > > -> changed to (hd0,1) or whatever value matches your disk drive and > partition solves > > > > For fixing issues with initramfs change the kernel command line in grub by > pressing 'e' to execute /bin/sh instead of init and debug > > linux /vmlinuz-3.10.9eko2 root=UUID=d48838a6-4c46-452a-xxxx-1fa624eb1c6e > ro init=/bin/sh > > you usually will load md-mod &friends, activate the lvm and mount the root > partition. You would then need to init the system > > mount -t ext3 -o ro /dev/mapper/root /new > cd /new > exec usr/sbin/chroot . /bin/sh <<- EOF >dev/console 2>&1 > exec /sbin/init ${CMDLINE} > EOF > > If you fail better press CTRL+ALT+DEL instead of exit > > I hope this helps > > >
I also have this problem I am running testing with a raid1 root fs (no crypt or lvm). If I do a system upgrade then kernel 3.10-2-amd64 fails to boot completely with a message that it can't find the root file system. In the busybox shell the raid devices don't appear to be created. If I do a "dpkg-reconfigure linux-image-3.10-2-amd64" after the failure (and booting into the still working 3.2.0-4-amd64 kernel) it will boot successfully into 3.10 until I do another upgrade. I have told grub not to use uuids and still no go. I just assumed that a fix would filter through eventually so I just muddle through by using the dpkg-reconfigure command. I am actually in 3.10 now. ...Bob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/523f08f9.2080...@gmail.com