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

Canek Peláez Valdés <caneko@×××××.com> wrote:

> 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.

Thanks for your quick reply, but I do have rd.shell=1, but it did not
drop to a shell,it just hung, so I could not do journalctl or anything
-- the nearest break point was pre-initqueue which was maybe too early
and the next one is pre-mount which it never got to.  Unfortunately, I
was in a position where I could not use an older kernel, because the
older ones didn't have the configs to read gui type partitions-- I
always keep several kernels around normally, but this was one of those
transitional times when I was stuck.  So do I need emergency aswell as
rd.shell andis there  any way to get a shell when the system appearsto
be in some kind of a loop, like calling setl over andover again?

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@××××××××××.com