Boot problem after kernel update on 10/15/2018 - additional from another thread

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?

isofrom=/dev/disk/by-label/UUI:/openSUSE-Leap-42.3-NET-x86_64.iso isofrom_device=/dev/disk/by-label/UUI isofrom_system=/openSUSE-Leap-42.3-NET-x86_64.iso loader=syslinux resume=/dev/sdb1 showopts fastboot

BTW, That same information is in the ‘linux’ line after clicking ‘e’ in the Grub menu.

Kernel is:

localhost:~> uname -r
4.12.14-lp150.12.22-default

This line from dougdeep’s ‘Slow Booting&found problem’ is what my HP desktop was ding just prior to it stopping the boot process completely.

A Start Job is running for DEV-DISK-BY\X2UUIDTD733AD84\X2D5F44~LordyThisIsALongString~.DEVICE 1min 30sec

I can remove fastboot from the ‘linux’ line in grub and try to capture the actual disk name(UUID?) if needed.

My system is starting very much slower the past few weeks so I am interested if dougdeep’s problem relate to mine.

With ‘fastboot’ remove from the grub ‘linux’ line.http://susepaste.org/17547598
Grub-boot-options

http://susepaste.org/18268708
Start-Job-screen showing the job sequence and disk UUID

http://susepaste.org/80640724
Boot-stop-screen - where it just stops doing anything.

I should add, that when I get tired of waiting and press the power button, It runs my Optic Drive as if I am first starting the machine.

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.

Bill, I don’t understand your disk layout or boot loader setup. Why is the openSUSE 42.3 net ISO in your (openSUSE 15) grub entry?

Can you show more details about your disks?

sudo /sbin/fdisk -l
/usr/sbin/blkid

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.

I will look closer to your recommendations when I climb those mountainous stairs again this day to get to the desktop.

In response to deano-ferrari’s request for more details about disk information:

sudo /sbin/fdisk -l
**Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors**
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xfb30b87c

**Device****Boot****    Start****      End**** Sectors****Size****Id****Type**
/dev/sda1       245457135 312577711 67120577  32G  7 HPFS/NTFS/exFAT


**Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors**
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000001

**Device****Boot****    Start****      End****  Sectors****  Size****Id****Type**
/dev/sdb1  *           64    204863    204800   100M  7 HPFS/NTFS/exFAT
/dev/sdb2          208845 660242866 660034022 314.7G  7 HPFS/NTFS/exFAT
/dev/sdb3       660244480 661202943    958464   468M 27 Hidden NTFS WinRE
/dev/sdb4       661203270 976769071 315565802 150.5G  7 HPFS/NTFS/exFAT


**Disk /dev/sdc: 149 GiB, 160000000000 bytes, 312500000 sectors**
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd0f4738c

**Device****Boot****    Start****      End****  Sectors****Size****Id****Type**
/dev/sdc1            2048  16771071  16769024   8G 82 Linux swap / Solaris
/dev/sdc2  *     16771072 100663295  83892224  40G 83 Linux
/dev/sdc3       100663296 205518847 104855552  50G 83 Linux
/dev/sdc4       205518848 312498175 106979328  51G 83 Linux

AND

/usr/sbin/blkid                                                                                                                                      
/dev/sda1: LABEL="WesternDigital IDE 160" UUID="D2E8C97CE8C95F7B" TYPE="ntfs" PARTUUID="fb30b87c-01"                                                               
/dev/sdb1: LABEL="System Reserved" UUID="1A0CB3280CB2FE37" TYPE="ntfs" PARTUUID="00000001-01"                                                                      
/dev/sdb2: LABEL="Windows 10 Home Release" UUID="0FCB1B290FCB1B29" TYPE="ntfs" PARTUUID="00000001-02"                                                              
/dev/sdb3: UUID="40888E43888E3804" TYPE="ntfs" PARTUUID="00000001-03"                                                                                              
/dev/sdb4: LABEL="Windows 7 64 Home" UUID="ACB2B4EEB2B4BDE0" TYPE="ntfs" PARTUUID="00000001-04"                                                                    
/dev/sdc1: UUID="0f558cfc-c8f3-4c78-93a8-cc4a7acba25d" TYPE="swap" PARTUUID="d0f4738c-01"                                                                          
/dev/sdc2: UUID="4e8d4f1f-f98f-4e94-adfc-bdf649be2f0f" TYPE="ext3" PTTYPE="dos" PARTUUID="d0f4738c-02"                                                             
/dev/sdc3: UUID="4a8eefe9-5576-4315-b7a2-9837e9957b42" TYPE="ext3" PARTUUID="d0f4738c-03"                                                                          
/dev/sdc4: LABEL="data" UUID="6e1e2ac3-d36d-40f9-913d-b4e7fd194c12" TYPE="ext3" PARTUUID="d0f4738c-04"   

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…

/dev/sdc1: UUID="0f558cfc-c8f3-4c78-93a8-cc4a7acba25d" TYPE="swap" PARTUUID="d0f4738c-01"
/dev/sdc2: UUID="4e8d4f1f-f98f-4e94-adfc-bdf649be2f0f" TYPE="ext3" PTTYPE="dos" PARTUUID="d0f4738c-02"

So your grub boot entry should look more like this IMHO…

resume=/dev/disk/by-uuid/0f558cfc-c8f3-4c78-93a8-cc4a7acba25d splash=silent quiet showopts

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?

That is a kernel boot parameter that is used to specify the partition used for hibernation.

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

Yes, good idea to make it ‘minimal’. No resume needed if not using hibernation.

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:

#cat /proc/cmdline
BOOT_IMAGE=/boot/x86_64/loader/linux
#

I certainly get nothing like if from using Grub.

Additionally, for certain on a 15.0 installation there should be no kind of reference to 42.3.

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp150.12.22-default **root=UUID=4e8d4f1f-f98f-4e94-adfc-bdf649be2f0f** **isofrom=/dev/disk/by-label/UUI:/openSUSE-Leap-42.3-NET-x86_64.
iso isofrom_device=/dev/disk/by-label/UUI isofrom_system=/openSUSE-Leap-42.3-NET-x86_64.iso **loader=syslinux **resume=/dev/sdb1** showopts fastboot

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.