From a thread started by pier_andreit, that I sort of hijacked yesterday.
OK adding the ‘fastboot’ parameter got me back into a working Leap 15. But that is a panacea in my new user mind.
I won’t belabor how long the boot process has grown, and seems to get longer.
My question(s) now are why it did what it did after the kernel update? And **what/where **to begin to start analyzing that WHY.
There are only one disk listed in YaST ‘Edit Disk Boot Order’, so it wasn’t AFAIK looking at another of the disks in the machine.
Or possibly something in this Kernel Parameter line needs to be tweaked?
In a single HD system, the resume device should not be sdb. Your /etc/fstab, /etc/default/grub and /boot/grub2/grub.cfg all need to be in sync WRT your swap space. I find it easiest to use labels, which are humanly memorable, rather than the lengthy random UUIDs the installer creates. So, start by reformatting your swap (this assumes that your swap partition is the first partition on your only HD):
mkswap -L d1p1swap /dev/sda1
Next, edit /etc/default/grub to include resume=LABEL=d1p1swap in place of resume=/dev/sdb1. Do the same with /etc/fstab. Finally, use YaST2 to update your bootloader by changing the timeout value up or down by 1, confirming that the resume=value remains as you just edited. Next boot should not have the timeout delay from non-existent resume device.
You can test that the resume= parameter is your problem by using the e key at the grub menu to remove the entirety of resume=blahblahwhatever before proceeding to boot.
That mess in the ‘linux’ line has been in the grub 'e’dit mode since I installed 42.3, and it was carried over to Leap 15 during the update from 42.3 to leap.
It also is in YaST kernel settings.
I asked once before about it, and never got a response as to why it is what it is.
And /dev/sdb/ is not the in the fdisk. it was the USB stick at the time of 42.3 install. Again, I will get fhe full fdisk -l later.
I will get the other things you asked for when I get back to the desktop later this day.
Also. the fsck disk check in the one of the images I posted appears to be the ‘/’ root partition.
What happens if I remove all the garbage before the ‘showopts fastboot’?
There IS a /dev/sdb1 , which happens to be on my Windows drive.
Leap 15 is on it’s own HDD.
See the fdisk -l posted above.
The disk information you’ve shared shows that /dev/sdc1 is where swap is located, and your root partition is /dev/sdc2. The blkid output shows the pertitnent UUIDs…
However, wait for others to comment further as I’m not sure about where syslinux fits into this here (and whether or not ‘loader=syslinux’ is needed). IIRC you’re chain-loading EasyBCD/GRUB4DOS >> GRUB2???
O S I R
And I will wait to see if others comment before taking a chance an borking things up again.
Question?>>> why should it ‘resume’ the swap partition?
On a healthy installation, boot will succeed. The entirety of the cmdline that follows the kernel name is found just a few lines down from the top of each /var/log/Xorg#.log. The entirety of the current boot’s cmdline can be seen via:
# cat /proc/cmdline
Thus on my current boot:
# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz
#
That’s right, none needed!
On a normal installation booted from its default Grub2 stanza, /proc/cmdline will match the content of GRUB_CMDLINE_LINUX_DEFAULT= in the file /etc/default/grub.
If you can get to a Grub menu without any USB stick inserted, I’d hit the e key on the default stanza to remove it all and see what happens. The worst to happen would be just another failure.
When you’ve booted from the USB stick, yes, UUID=“D2E8C97CE8C95F7B” is indeed sdb1. That the BIOS of your PC causes it when you boot a stick complicates the processes of both troubleshooting, and trying to both respond to and understand a response to a thread such as this. When you boot normally (no USB stick), sdb1 is almost certainly your openSUSE swap partition, UUID=“0f558cfc-c8f3-4c78-93a8-cc4a7acba25d”. That’s why using UUIDs for booting was invented (over a decade ago), to avoid unpredictable partition names interfering with booting.
LABELs are another booting option that avoids the problem, one that’s better suited for troubleshooting, and human computer administrators generally. Computers don’t care that normal humans can’t remember UUIDs or correlate them to the location of various partitions and volumes.
resume=/dev/sdb1 does not belong on the cmdline of a USB boot on the PC here under discussion. In most situations, better there be no noresume at all rather than /dev/sd<anything>.
I neglected to warn not to be mislead by the existence of BOOT_IMAGE=/boot/vmlinuz. When BOOT_IMAGE does not appear on an actual kernel cmdline or in a Grub stanza, it nevertheless gets auto-generated by I I know not what for inclusion in /proc/cmdline, and for what purpose neither do I know. The actual grub kernel line used for the comment 14 boot was:
linux /boot/vmlinuz
WRT cleaning the cmdline, I’m of the opinion that until this mess gets straightened out, resume=blahblahblah should have not mere removal, but replacement with:
noresume
This will force a genuine boot each time rather than allowing a bad resume specification to possibly prevent boot. AFAICT, without any form of resume on the cmdline, the kernel will always attempt to resume as long as the initrd contains a resume specification, which by default dracut seems always to include. The resume= normally included in a grub stanza overrides the dracut built-in specification.
When normal boot finally gets restored, I recommend going into BIOS and eradicating USB as a boot option, so that an inadvertent stick insertion while booting will not enable disruption of a normal boot, keeping Windows on sda and openSUSE on sdb, regardless that with UUID (or LABEL) boot and mount specifications no such disruption should ever occur.
The above really has me bothered. I’ve never encountered anything like it using any openSUSE installation media or installation. It looks as though something has replaced Grub2 with Syslinux as the operational bootloader. When I boot the burned to DVD 15.0 .iso in UEFI mode all I get is:
1 - SO, I assume (hopefully not wrongly), that I can remove everything in the above that is in BOLD text?
2 - Could the ‘loader=syslinux’ have been put thereby the creation of the USB install stick, OR by EasyBCD>Grub4DOS?
You should be able to boot with all of it removed.
Showopts is completely irrelevant on every system not using Grub Legacy. Why the openSUSE installer and YaST continue to include it is a mystery explained only by either affiliation with SLE long term support, of lack of interest in expending the effort to excise the code that includes it.
2 - Could the ‘loader=syslinux’ have been put thereby the creation of the USB install stick, OR by EasyBCD>Grub4DOS?
Regardless how it got there, it’s past time for it and any reference to 42.3 to go.