Hi Masaru! On Fri, 2023-10-06 at 17:10 +0900, Masaru Nomiya wrote:

AG> No and since the issue could be worked around by switching to lightdm, AG> I don't think it's related to the graphics stack.

In sddm, do you use auto-login?

No, never. Adrian

On Saturday 07 October 2023, Fritz Hudnut wrote:

In my case changing log in managers didn't adjust the problem of just seeing wallpaper and cursor for 3 to 4 minutes. And going to auto-login also didn't work.

And, then this morning both my TW and Gecko rolling partitions booted to emergency mode.

Now fully operational in Leap 15.6.

I'm not sure whether your situation is the same as mine, but I'll input my 2c in case it helps: After a recent TW dup I saw a huge delay in arriving at the login screen which I could only fix by disabling NetworkManager-wait-online.service systemctl mask NetworkManager-wait-online.service As described in this forum post: https://forums.opensuse.org/t/networkmanager-seems-to-fail-at-boot/168560/16 After an even more recent dup I was dumped into emergency mode. I guessed it had something to do with some recent changes mentioned in the mailing that might affect the consistency of the assignment of device names such as sda. Sure enough, my /boot/grub2/grub.cfg was setting root to /dev/sda2. I tracked that back to /etc/default/grub where at some time in the past I had set GRUB_DISABLE_LINUX_UUID=true I commented that out, used yast to update the bootloader and all has been well since. I had probably turned off UUID's during past repairs as a shortcut when moving root to a new disk, or maybe it carried through from past use of OpenSUSE over the last decade or so. Michael

Fritz Hudnut composed on 2023-10-07 00:41 (UTC):

Leap seems to have switched sdc drive for sdd internal drive

It was a common problem two decades ago, called "inconsistent device enumeration". Even though all my many PCs are multiboot, it has been a rare problem here since a modest time after I began using SUSE around 20 years ago. For "internal" (SCSI, SATA, PATA & PCIe connected) drives, the problem of "external" drives (USB, Firewire, anything removable except SCSI/SAS) intercepting drive name assignments can be minimized in several ways: 1-do not use legacy drive names sda, sdb, sdc, sdd, sde...sdX for configurations. 2-do use UUID and/or LABELs and/or the assignments in /dev/disk/, not what they link to. 3-keep BIOS set to ignore external boot devices except for specific boots needed. 4-exclude USB storage device support in initrds: omit_drivers+=" usb_storage " in dracut cfg. 5-connect removable storage devices only after boot completes. 6-retire use of both PATA & SATA bootable storage devices in the same PC. Use one or the other, not both. 7-put all operating systems on the same storage media. Most PCs here have only one internal storage device. Most with more are RAID components. There are probably others I'm forgetting. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On 10/7/23 09:29, Fritz Hudnut wrote:

Mr M:

Thanks for the exposition . . . I guess I'm hitting the "perfect storm" . . . ??? To try to boot TW I felt compelled to use my SuperGrub2 disk, but, as mentioned somewhere, this "disordered grub" thing was happening before I plugged in that usb drive.

I have all SATA internal drives, two HDD, and two SSD . . . none of that has changed recently.

@Michael, et al: I did check my /etc/default/grub file and the "UUID=true" line is commented out in Leap . . . the /grub.cfg file is quite large, it does seem to show uuid data for each OS . . . quite a large file.

One of my systems has 4 SATA drives configured as RAID 5 and one SSD attached to port 2 of the motherboard. With drive names in fstab and grub config, sometime that SSD was attaching as /dev/sdb, and sometimes as /dev/sda, depending whether the first rotating rust drive responded before or after the SSD. After I switched to UUID identification, everything is fine. I hate those long labels, but it just works! :) Larry

Fritz Hudnut composed on 2023-10-07 14:29 (UTC):

I did check my /etc/default/grub file and the "UUID=true" line is commented out in Leap

None of mine have any such "line" "UUID=true".

the /grub.cfg file is quite large, it does seem to show uuid data for each OS . . . quite a large file.

"Large" by what measure? 10k? 100k? 1M? 1G? Its size is proportional to the number of installed kernels found when it's generated. The more OSes found, the bigger the result must be. The current TW boot here has 40,819 byte /boot/grub2/grub.cfg, and os-prober isn't even installed. I just now installed it, changed GRUB_DISABLE_OS_PROBER="true" to GRUB_DISABLE_OS_PROBER="false". Then: # os-prober | wc -l 20 # grub2-mkconfig -o /tmp/grub.cfg ... done # ls -gG /tmp/grub.cfg -rw------- 1 297017 Oct 7 11:46 /tmp/grub.cfg # zypper rm os-prober ... Is yours bigger? Your expository technique of speech fragments, brevity and dots typically makes you difficult, sometimes impossible, to understand, thus to respond to usefully. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

On Sat, 2023-10-07 at 17:38 +0000, Fritz Hudnut wrote:

After trying grub to boot other systems and only two of the 7 were "found," for the third time in Leap I ran "sudo grub2-mkconfig" and this time it showed each of the OSs in their proper sdx location. I then ran sudo update-bootloader" for extra insurance and shut the machine down. On cold boot I selected the TW option and it booted back into the original problem of 3.5+ minutes to get to the GUI. So, skating from one banana peel to the next, back to the "slowness of TW to achieve GUI."  If grub is working to boot selected OS, then that is my only concern there.

If you think you're facing a bug, please submit a report. For slow boot, "systemd-analyze blame" or "systemd-analyze critical-chain" are good starting points. Thanks Martin

On Sunday 08 October 2023, Joe Salmeri wrote:

...

I know that the /dev/sdX drive mappings are not guaranteed to be the same at every boot, however, this is the first time they have have mapped out differently on my system ( which has had no HW updates or any updates other than TW for quite a while ).

It would seeem that either something in TW20231001 or probably kernel 6.5.4-1 is the source of this.

I think the cause may be sg3_utils moving to v1.48. I tracked down the mailing list post that I took to describe the reason I was dumped into emergency mode at boot. The mailing list archive does not seem to contain this post and an important follow up post. I could neither locate the posts by browsing or searching the archive, but perhaps I'm doing something wrong. Anyway, I'll quote both posts here (I will also reply to the original to bump it up): --- Original quoted post --- SCSI device identification and SCSI symlink generation in sg3_utils 1.48 Date: 2023-09-22 10:22 From: Martin Wilck via openSUSE Factory <factory@lists.opensuse.org> To: "opensuse-factory" <opensuse-factory@opensuse.org> CC: Hannes Reinecke <hare@suse.de>, Franck Bui <fbui@suse.com> Reply to: Martin Wilck <mwilck@suse.com> With the forthcoming update of sg3_utils to v1.48 (currently in Base:System, to be submitted to Factory soon), SCSI device identification and SCSI symlink generation by udev will change. TL;DR: unreliable device identifiers will not be used by default any more, and /dev/disk/by-id symlinks for such identifiers will not be created by default, either. The policy can be changed by editing the udev rules in 00-scsi-sg3_config.rules. Please file bugs and / or notify me if you have trouble with this new identification scheme. Of course, while this is still in Base:System, we can also discuss the general approach for Factory, and the defaults to be applied. Long version: It is well known that referring to disk devices by their device node (like /dev/sda) is unreliable. In most situations, it is recommended to refer to devices by their content, i.e. using file system UUIDs or labels. Sometimes, however, the devices must be referred to by hardware properties. For this purpose, udev maintains various symlinks under /dev/disk/by-id. This post is specifically about SCSI symlinks, which have the format /dev/disk/by-id/scsi-XYZ. If you don't use dm-multipath, and don't use hardware IDs to refer to any disks or partitions anywhere, you can stop reading here. SCSI devices can be identified in different ways by the contents of SCSI VPD (Vital Product Data) pages. In PVD 83 (device identification), the following identifiers may occur (see SCSI spec SPC-6 §7.7.6 for details): a) NAA registered extended: 36... (+ 31 hex digits) b) NAA registered: 35... (+ 15 hex digits) c) NAA extended: 32... (+ 15 hex digits) d) EUI-64: 2... (+ 16 hex digits) e) SCSI name string: 8... (+ utf-8 string) f) NAA local ("L"): 33... (+ 15 hex digits) g) T10 vendor-ID ("T): 1... (+ string) h) vendor-specific ("V") 0... (+ string) Furthermore, we have i) serial number ("S"): S... (+ vendor/product/serial string) The list above is sorted roughly top-down by the reliability (uniqueness) of these identifiers. The udev rules select the most reliable available identifier from the above list to set the ID_SERIAL udev property, which is used e.g. by dm-multipath to identify SCSI devices which represent different paths to the same physical volume. Furthermore, the udev rules create /dev/disk/by-id/scsi-$ID symlinks for all identifiers from the above list that are defined for a given device. This makes sure that whatever identifier a user has chosen for referring to her disks will be available as symlink under /dev/disk/by-id. However, this has also severe disadvantages. The identifiers f)-i) are not reliable; IOW there can be multiple devices in the same system that use the same identifier, although they don't represent the same physical disk. This applies to i) in particular: Some large storage arrays use the same serial number for all LUNs they expose. Using such identifiers for multipath can cause fatal data corruption. Moreover, the creation of these symlinks during boot can slow down booting a lot, because thousands of devices may be contending for the same symlink. Lastly, not creating useless symlinks will tidy up /dev/disk/by-id and make it easier to read. Therefore sg3_utils 1.48 changes the policy for SCSI device identification. The policy can be customized in the udev rule "00-scsi- sg3_config.rules" (to change the policy, copy this file from /usr/lib/udev/rules.d to /etc/udev/rules.d first). For determining ID_SERIAL, only a)-e) above are tried. If users need to use additional identifiers from the list above, they can set the udev property .SCSI_ID_SERIAL_SRC (leading "." is intentional) to any combination of the capital letters in quotes in the list above. E.g. "ST" would mean to take g) and i) into account. To restore the previous behavior, set ENV{.SCSI_ID_SERIAL_SRC}="LTVS". The current upstream default is "T", so that g) above is still enabled. To disable all "unreliable" IDs, set it to the empty string. If udev encounters a device for which ID_SERIAL can't be assigned, it prints a warning to the journal. Symlink generation is controlled by the variable .SCSI_SYMLINK_SRC. It can also be set to any combination of "LTVS", with the same meaning of the letters as above, and controls which scsi-... symlinks udev will create under /dev/disk/by-id/, *in addition* to the symlink /dev/disk/by-id/scsi-$ID_SERIAL, which will always be created if ID_SERIAL could be determined. Again, to restore the previous behavior of the udev rules, set ENV{.SCSI_SYMLINK_SRC}="LTVS". The default is the empty string. Note 1: The symlink generation applies to both disks and partitions. Partition symlinks have a "-part$P" string appended to the name of the symlink of their parent disk. Note 2: Modern SCSI devices usually support one or more of the "reliable" identifiers a)-e) above. I expect that only very few old devices really need one of f)-i). Inform me if you find counter- examples. Note 3: ATA and USB devices have additional identifiers generated by the transport (/dev/disk/by-id/ata-* and /dev/disk/by-id/usb-*) which are unaffected by this change. These devices often don't expose proper SCSI IDs, but they actually don't need them because the ATA or USB identifiers are unique. Regards, Martin --- Most recent quoted post --- Re: SCSI device identification and SCSI symlink generation in sg3_utils 1.48 Date: 2023-09-29 05:03 From: Martin Wilck via openSUSE Factory <factory@lists.opensuse.org> To: factory@lists.opensuse.org Reply to: Martin Wilck <mwilck@suse.com> On Fri, 2023-09-22 at 00:22 +0200, Martin Wilck via openSUSE Factory wrote:

With the forthcoming update of sg3_utils to v1.48 (currently in Base:System, to be submitted to Factory soon), SCSI device identification and SCSI symlink generation by udev will change.

TL;DR: unreliable device identifiers will not be used by default any more, and /dev/disk/by-id symlinks for such identifiers will not be created by default, either. The policy can be changed by editing the udev rules in 00-scsi-sg3_config.rules.

To make sure this information isn't buried in the mailing list, I've created https://en.opensuse.org/SDB:SCSI_Device_Identification I've added kernel boot parameters as a means for rescue, in case this should cause regeression (I don't expect it will, but well...). The sg3_utils 1.48 update for factory is planned for week 41. Regards Martin --- End of quoted posts ---