Hello, On Tue, Mar 25, 2014 at 6:15 PM, André Nunes Batista <andrenbati...@gmail.com> wrote: > On Mon, 2014-03-24 at 12:36 +0000, Darac Marjal wrote: >> On Mon, Mar 24, 2014 at 12:17:17PM +0000, Joe wrote: >> > On Mon, 24 Mar 2014 11:17:53 +0000 >> > Darac Marjal <mailingl...@darac.org.uk> wrote: >> > >> > > >> > > >> > > Now, I'm not certain about this, but I suspect that either the >> > > initramfs hasn't recognised that I'm using LVM, or it just isn't >> > > starting the LVM on its own. >> > > >> > > I haven't actually investigated this, but it might be related to bug >> > > #616689. >> > >> > Except... both the OP's initramfs and mine do recognise the swap >> > partition within LVM, but not any others. >> > >> > And my system is (apparently) OK after downgrading grub from the latest >> > version. >> >> Ah. Sorry for the noise, then. >> > > Your answer proved not be noise at all. I tried to follow Joe's steps > and downgraded grub2-common, grub-common, grub-pc and grub-pc-bin all to > jessie (2.00-22), ran update-grub2 and then grub-install /dev/sda and > lost my grub.cfg. > > I've restored it using supergrubdisk, which, when booting, gave me > access to that previous initramfs shell. Then I ran vgchange -ay ^D, ^D > and was able to boot the system. > > One thing caught my eye through the process: grub says it's generating > configs for i386 only, but this machine uses amd64 kernel. As soon as I > get the chance I'll read #616689 and try to investigate it further on > this machine. Currently it only boots through this forced activation > method you taught me. This thread remember me what happens to me last week:
I had a grml installation (which I expect to have a behaviour exactly like a debian system now that I installed all the packages that I needed from debian sid). That installation was without lvm, all contents to one partitioin. So the last week I wanted to change that installation and move to lvm style. So I backed data, created partitions, and tried to update grub / etc/fstab .. from chroot I knew about #741342 Debian Bug, so I workaround about it with GRUB_DISABLE_LINUX_UUID="true" hack The result of that movement was a unbootable system (grub rebooted the system) After researching grub or kernel parameters, like panic, I find about where was the error: initramfs generated inside the chroot was failed and lsinitramfs list an empty initramfs empty (after research I hit another bug [1]) Compressing initramfs generated, lsinitramfs show only this file: kernel/x86/microcode/GenuineIntel.bin So finally I copied an initramfs from other sid machine, and it worked. Then I tried to regenerate initramfs from scratch in the machine, and like I didn't know about [1] bug, I think it was erroneus. I didn't report any bug because it was a grml system when it was installed. Then I tried to install dracut (which is an alternative to initramfs-tools) and it worked like a charms. lsinitr* worked again, and I could boot without any problem So, how do you extract your initramfs content ? There is a patch at [1], but it is not being accepted by the maintainer. (I guess dd and offset commands illustrated at the bug will work) I will try to return to initramfs-tools and see if the generated initramfs is working (like it seems) Regards, [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717805 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cal5ymzqovouebx5yqjvbgqvkkc-myv_lfjb+gya_sc-ae9b...@mail.gmail.com
