Canek Peláez Valdés <can...@gmail.com> wrote: > On Thu, May 28, 2015 at 12:09 AM, <cov...@ccs.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 cov...@ccs.covici.com