Alex Gould wrote:
> On Wed, Jul 4, 2018, at 3:08 PM, deloptes wrote:
>> Alex Gould wrote:
>>
>> > I imagine I will need to fix some settings for initramfs, grub,
>> > crypttab, fstab, or something, but I'm not sure how to proceed.
>>
>> I would compare content of new and old initrd
>>
>> lsinitramfs /boot/initrd-.... > initrd.1.content
>> lsinitramfs /boot/initrd-.... > initrd.2.content
>>
>> diff -ub initrd.2.content initrd.1.content
>>
>> is there something missing?
>
> Thank you,
>
> There were some differences that might be relevant, unfortunately I'm not
> sure what they mean. The first change listed below looks suspicious to me.
>
Extract the initrd and inspect the '+' new files
> +conf/modules
> +lib/cryptsetup/functions
> +cryptroot/crypttab
finally you have to fix initramfs-tools, to be sure it will create proper
image next time - perhaps consider the answer by tv.deb...@googlemail.com
<tv.deb...@googlemail.com>
I stopped using systemd as init process long time ago, though keeping it on
the system still creates problems.
As tv.deb...@googlemail.com <tv.deb...@googlemail.com> reported, it might
be the changes to initramfs-tools.
I do use the stable version to avoid waste of time in such situations,
however I had many times issues with initrd and what I usually do to debug
and solve is to pass to the kernel boot the option init=/bin/sh. When I
enter in the primitive shell I found out what is the problem as I can
manually decrypt, activate lvm and mount root. After this I cd to the mount
point of root and do following (this 3 lines are worth gold)
exec /usr/sbin/chroot . /bin/sh <<- EOF >dev/console 2>&1
exec /sbin/init ${CMDLINE}
EOF
usually this was necessary when swapping drives, so at the end when I boot I
(re)create initrd
Few times a command or two were missing from the initrd, or devices were not
created etc.
regards
