Re: [gentoo-user] problems debugging a systemd problem

[Canek Peláez Valdés]

On Thu, May 28, 2015 at 12:09 AM, <covici@××××××××××.com> wrote:
>
> Hi folks.  I spent a very frustrating time last night trying to figure
> out why my systemd would not boot using systemd.  I am using dracut and
> its version is 041r2.  Now what was happening is  that the system would
> get to the pre-init-queue -- and I even set the rd.break there, but
> after that the system would not boot -- when I used debug it endlessly
> said calling setl forever.  Now it turned out that the problem was that
> I had mistyped an rd.lv= line -- instead of ssd-files/usr I had
> ssd-files/-usr .  Now, what I would like to know is how could I tell
> that it was trying to look for a non-existent lv?  At the point of the
> break. no lvm volumes were active, although strangely enough I saw a
> e2fsck for the real root file system which  was an lvm volume.  I am
> finding its generally hard to debug systemd problems, several other
> times the system just sat there till I figured it out some other way.
>
> Any observations on this would be appreciated, but I don't want to get
> into  a flame war, I just want to minimize the down time.

Usually if you can get an emergency shell by adding "emergency" to the
kernel command line (both GRUB and Gummiboot allow you to edit the kernel
command line), then is easy to see what the problem is. My experience with
LVM has been consistently pretty awful, which is why I don't use in any of
my machines, but I suppose a systemctl --all --full will tell you what unit
files have failed, and then you can journalctl -b -u them. Also journalctl
-b by itself would tell you many times what the problem is.

The only problem with the emergency shell is that sometimes is too early in
the boot process for the keyboard drivers to have been loaded, but that is
easily solved by adding a drivers+="" line to a conf file
in /etc/dracut.conf.d.

Also, and I cannot stress this enough, you never delete your old (and
working) kernel+initramfs until you have tested the new one. I would also
recommend to leave the entries for the old kernel+initramfs in the
GRUB/Gummiboot menu, but you can manage without them.

Finally, and this is tooting my own horn, maybe you could try kerninst[1]?
It's a little script I started a couple of years ago to automatically
compile and install my kernels and generate my initramfs'. I use it in all
my machines, and now my kernel update is just a matter of eselecting the
new version, and running kerninst. I follow ~amd64 vanilla-sources, so this
is roughly every week or two.

Beware, though, that I don't use LVM nor RAID nor Luks, but in theory if
you have a working kernel+dracut+[grub|gummitboot] configuration, it should
also work with them.

Regards.

[1] https://github.com/canek-pelaez/kerninst
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México