Opensuse leap 42.1 warning boot has failed. Add rd.debug to the kernel command line

Seems I am not the only one to see this message but for me it is the first time.
My main workstation is running 42.1 and has been rock solid until my last restart. I have no idea or recollection why a restart was done.

Now the boot process stalls and I get the captioned warning message.

The trouble is I cannot now copy the log and post it here for obvious reasons.

I seek help on how and where to add the instructed kernel options. Should there be a comma or space between them? I think space, am I right?
I have found how to edit the booting script during boot and assume I add to the line which starts “linuxefi”

Hopefully when I restart the process will all be logged and I will have info which I hope will mean something to somebody.

If I then live boot I should be able to get a copy off the broken system which I can then post here.
My last question for now therefore is; where should I look for the log file and which file will it be?


[QUOTE=Budgie2;2805252]I think space, am I right?[/correct]

If I then live boot I should be able to get a copy off the broken system which I can then post here.

No, with those options you will be stopped in initrd which is entirely in memory, so no logs will be preserved. You will need to copy them somewhere while working in initrd shell.

My last question for now therefore is; where should I look for the log file and which file will it be?

Output of journalctl would be good start.

Hi and many thanks for the reply. I proceeded as indicated and loh and behold, I now have dracut shell prompt and several instructions about saving a file, in particular /run/initramfs/rdsosreport.txt and looking at logs with journalctl. I didn’t find much on Google that I understood about dracut so would appreciate some help with mounting a USB stick so I can save the files, including if possible the logs from journalctl.

Plug in USB stick, check kernel messages (with dmesg) which disk name gets assigned (sda, sdb etc); mount it with “mount /dev/sdXn /mnt”. Here `n’ is partition number, USB sticks usually have just one partition.

linuxefi ?
Why EFI ?
Are you booting your system from a live medium in (U)EFI mode?
From the fdisk listing in your first post in the other thread (see you have partition tables/disk labes of type (ms)dos, which work for booting in “legacy” mode, not (U)EFI mode.

Different thread for different machine and different problem. The boot failure (this thread subject) is on my main workstation. The other thread concerns my multi booting machine. It never rains but it pours.

Plugged in USB stick and message came up at dracut prompt. Same message as from kernel with dmesg. No disk name as in sda, sdb, etc. but:-

usb 2-5: new high-speed USB device number 3 using ehci-pci

There are several lines starting usb 2-5 but none with assigned name in form you suggest. I assume 2-5 is equivalent to sdb5 but really am not sure. It is the 3rd usb device as nos 1 & 2 are keyboard and mouse but they are at usb 6-1. Grateful for your guidance once more please.

Oh sh…! :open_mouth:

I installed openSUSE on an USB stick some time ago, in order to have a live system for a case like yours.

A bit of information about where the journal goes, I just found here:

Good luck

Found another thing searching for ‘ rd.debug’:

Under ‘Identifying your problem area’ you find there:
2. Add rdshell to the kernel command line. This will present a shell should dracut be unable to locate your root device

If this would apply for openSUSE as well, which isn’t that unlikely, then something really went bad on your main workstation.

Hi and thanks for that. I have read up all the relevant google hits already and achieved the dracut prompt in debug mode. Unfortunately all the dracut advice tells me is I have to mount the USB stick manually but I have no idea how since dracut on btrfs system does not put drives on /dev/sxn etc. See my last post.

I checked the system using the built in diagnostics (it is an IBM server after all) and all checked out OK.

Then tried a live Ubuntu 16.10 which worked perfectly. (Very easy on the eye and at this rate I may move over to Ubuntu after having been on openSUSE since version 7 or 8.) I concluded that my system was OK.
I then booted 421. using the earliest of the kernel versions available in advanced tab which was version 4.1.31-30 and everything went as it should have so I guess the last upgrade is to blame.

Overall I have been very disappointed by all this which has cost me a couple of days in total, but many thanks for your stoic assistance.

If you can boot from a live USB stick then you may not need to bother with dracut.
The use of ‘journalctl’ then isn’t possible in a direct way, of course, but perhaps with the information in
the log data may be copied and evaluated on another system.

That all reads very good.

There is one thing from your first post in this thread, which however isn’t clear yet:

A drop in power supply could be one reason.

A hardware error doesn’t seem to have been the reason.

If you opened SSH port or started Network services then there would be further possibilities.


Is there a reason that you stick to 42.1?
I was a bit reluctant to install it when came out, because 13.2 was rock solid (almost always, except for one update of systemd), and 42.1 was a fresh approach.
But I’m happy with 42.2 now.
I’m conservative in general, and thus still prefer ext4, which won’t have many bugs anymore, instead of btrfs which still is under development.

Hi and thanks once again. The restart that caused the boot failure must have been required following an update, sorry I had forgotten in all the excitement. That is what it seems to be from my sniffing around in the machine.

Whatever the cause I thought the failed boot message to add and rd.debug was helpful. What was not helpful and is causing me annoyance is that the dracut manual advice is to save the log files on a USB stick which “must be mounted manually” but nobody has yet told me how I may do this. Since the device is not shown in a recognisable way and commands like fdisk do not run in dracut I shall only know when somebody here tells me. Meanwhile I shall keep a lookout for postings from others about a possible kernel bug.

I am still running 13.2 x64 on a “retired” server and 13.2 32 bit on my laptop. I only changed because support is going to be withdrawn. I note your advice concerning 42.2 and will try it. At the risk of boring you with a rant, I actually hate all the changes, other than those needed to accommodate hardware improvements, which keep appearing, especially in KDE. They are thrust upon us with little or no introduction and frequently turned on by default thereby sucking up performance. If they would just do a small announcement with each release about what is new stuff is available and its purpose then we as users could decide if we want it or not and then turn it on. Akonadi, Nepomuk come to mind and now we have Snapper, which is great but not once mentioned as a possible solution to my recent problem, only a possible cause! I use computers for work, not to play with and just need fast and reliable machines. End of rant.

Wishing you a Happy Christmas and Prosperous New Year.

Hi again!

Hm, openSUSE/Linux is not windoze, and I never experienced that a restart has been triggered automatically under openSUSE, but one usually has to trigger a reboot/restart intentionally and actively.

dracut isn’t something that is a feature specific to openSUSE.
And the dracut prompt probably is something hardly seen by many users.

When openSUSE switched from KDE3 to KDE4, I was asking myself why, because KDE3 just did what I needed.
Now under Leap 42.2 we have KDE5.
But that feels more responsive than KDE4.
I can well understand your rant.

But tell me, is there some OS where things are unfolding in a really different way?

Do you prefer windoze 10 compared to windoze 7?
And you as a “usual” user - are you asked if you would have liked to have a new unity desktop under ubuntu?
I liked the desktop of MacOS 7 - do I have to like MacOS X?
Do you really have a choice in that respect, whichever OS you choose?
Which desktop or OS you choose, it won’t stay forever, but it will change, and the old one will no longer be supported after s certain time.
If I would have the time, I might even enjoy to code my own desktop, but …

How are things going with your server, besides?