[SOLVED] A start job is running for /dev/disk/by-uuid

mrmazda · 12-06-2023, 05:42 PM

Quote:

Originally Posted by lattimro

what is BBS hotkey menu?

Unless your motherboard is configured to hide POST processing behind a splash screen, most BIOS announce their hotkeys every time you cold boot, or reboot from Linux instead of Windows, same as announcing how to enter BIOS setup, but specifying a different key for the unique purpose of selecting what to boot from from its menu.

lattimro · 12-06-2023, 06:48 PM

Quote:

Originally Posted by mrmazda

Any installation media that can be booted in UEFI mode will suffice to collect the UEFI NVRAM state. It might be facilitated by going into BIOS and temporarily disabling CSM so that booting is only possible via UEFI. We need that efibootmgr output!!! Have you tried using the BBS hotkey menu to select TW for booting? How many entries are in it? How many for TW?

When Windows 10/11 is/are present, it's best to only install anything in UEFI mode, especially so if Windows is UEFI installed.

In whatever Linux bootloader you have booting any Linux from sda you should be able to add a boot stanza copied and edited as necessary to try to boot the TW installation. Put the stanza in the same directory as grub.cfg from which you are able to boot any Linux, in a file named custom.cfg. You may need to regenerate its grub.cfg after doing so. All my UEFI booting is configured so that my custom.cfg entries are included at the top of Grub's boot menu. This way I'm normally booting only from stanzas of my own creation. Anyone can do the same by copying /etc/grub.d/41_custom to /etc/grub.d/07_custom.

BBY, what BBS stand for?

Yes, when I boot EFI (W10, TW and Ubuntu (EFI)), I choose what media to boot from by depressing F9, I will post some screenshots tomorrow.

lattimro · 12-07-2023, 11:23 AM

... cont

mrmazda · 12-07-2023, 05:40 PM

The first of the three screenshots in post #18 suggests a possibility that a Gecko boot might be being attempted rather than TW, and that its fstab may include a line for mounting the root partition of the TW installation that can't be found. One reason I say this is that there is an extra column to the right of the time column (e.g. [ T238]) that I don't get from TW either on the boot screen, in the journal, or in dmesg. It's something I can't recall ever encountering before.

An alternative possibility is that booting isn't even attempting to come from TW's sdc4 287a... filesystem, because of all the USB messages. When I boot TW with no USB storage attached, mouse only, 28 USB lines appear in dmesg. With a bootable Knoppix USB stick attached during boot, 51 USB lines appear in dmesg. Without mouse or stick, 25 lines appear. Your image has 36 or so among a single screenful ending with the pending start job line.

Another inconsistency is that you say sdc4 is TW, yet it's volume label is "Gecko". I see no indication in the #5 image in post #17 whether the list came from the geckolinux or the opensuse parent directory (or perhaps something else). Your lsblk output shows only Gecko, no opensuse or tumbleweed. What exactly are you trying to boot? What did you last install?

Your sdc4 filesystem's fstab points to sdc3 as the relevant ESP filesystem, but in lsblk output sda3 is mounted to /boot/EFI/. Where is/was the Ubuntu / filesystem located when you generated lsblk? I don't recognize any likely location in the output. Post #17 image #1 is not what I expect to see from any normal SSD/HDD UEFI boot. There should be at least one line corresponding to whatever lives on sdc4 287a... coming from sdc3 as indicated by fstab on sdc4.

I wonder if there is something going on here related to this TW bug "Assignment of /dev/sd* has altered dramatically" that a fresh TW installation wouldn't fix?

I've only ever had more than one ESP in one PC at the same time once. That was a long time ago as a brief experiment with a since dead motherboard, for booting an NVME in a PCIe slot. IOW, I have no hands-on experience with what to expect when more than one ESP is in a system. My installations are rock solid, in part because there is only ever one installed Linux bootloader, regardless whether I have only 3 Linux installations or 20+. Nothing can get mixed up.

Volume labels on everything could be a big help. When not assigned during format they can be added later, such as with e2label or tune2fs for EXTx. I have another limitation evaluating here in never using encryption and multiboot on the same PC, so no familiarity with how shim or mokmanager might interfere or subsume. Trying to sort through what's going on here is a big challenge so far. I need a mental break for a while....

goumba · 12-07-2023, 06:09 PM

I doubt if that sd* assignment bug would affect lattimro as his fstab relies on UUIDs, and not device names.

That "waiting for..." should time out at some point, and give us a recovery shell.

What is the output of

Code:

journalctl -xe

?

Upon failure it may also give a hint about a specific journal entry that you should check (it's been a while since I've had a root mount fail), check all messages and see if it suggests a specific unit. Look for a line similar to (I can't remember the exact wording):

Code:

systemctl status dev-disk-by-uuid-xxxxxx.service

You can also use same with journalctl for more detailed info:

Code:

journalctl -u dev-disk-by-uuid-xxxxxx.service

mrmazda · 12-07-2023, 06:35 PM

Quote:

Originally Posted by goumba

I doubt if that sd* assignment bug would affect lattimro as his fstab relies on UUIDs, and not device names.

If this stems before fstab plays a role, UUIDs can be no panacea. Did you read that bug? There it's an early appearance device enumeration issue, before kernel loading, a difference between BIOS and Grub, before fstab is read. It doesn't appear to me that fstab is even in a TW initrd:

Code:

# inxi -S
System:
  Host: ab250 Kernel: 6.5.9-1-default arch: x86_64 bits: 64 Console: pty pts/0
    Distro: openSUSE Tumbleweed 20231121
# lsinitrd | grep fstab
-rw-r--r--   1 root     root            0 Nov 22 14:12 etc/fstab.empty
-rwxr-xr-x   1 root     root        51792 Nov  2 15:59 usr/lib/systemd/system-generators/systemd-fstab-generator
lrwxrwxrwx   1 root     root           41 Nov 22 14:12 usr/lib/systemd/systemd-sysroot-fstab-check -> system-generators/systemd-fstab-generator
#

Quote:

That "waiting for..." should time out at some point, and give us a recovery shell.

That particular "waiting for" has "no limit". It can't timeout. Elsewhere example.

colorpurple21859 · 12-07-2023, 08:25 PM

The initrd may need to be regenerated, modules may be missing to access the root drive.

lattimro · 12-07-2023, 10:52 PM

Quote:

Originally Posted by goumba

I doubt if that sd* assignment bug would affect lattimro as his fstab relies on UUIDs, and not device names.

That "waiting for..." should time out at some point, and give us a recovery shell.

it does not time out to a recovery shell. I waited few hours and it was still counting.

[/QUOTE]
What is the output of

Code:

journalctl -xe

?

Upon failure it may also give a hint about a specific journal entry that you should check (it's been a while since I've had a root mount fail), check all messages and see if it suggests a specific unit. Look for a line similar to (I can't remember the exact wording):

Code:

systemctl status dev-disk-by-uuid-xxxxxx.service

You can also use same with journalctl for more detailed info:

Code:

journalctl -u dev-disk-by-uuid-xxxxxx.service

[/QUOTE]

Since does not finalize the booting, I am not able to provide any data. The only outputs are from chroot. Therefore jurnalctl and systemctl are not available.

mrmazda · 12-07-2023, 11:16 PM

Quote:

Originally Posted by lattimro

The only outputs are from chroot. Therefore jurnalctl and systemctl are not available.[/I]

If the installed system's / is accessible, then journalctl can be run using the -D option. From the man page:

Code:

       -D DIR, --directory=DIR
           Takes a directory path as argument. If specified, journalctl will operate on the specified
           journal directory DIR instead of the default runtime and system journal paths.

e.g.:

Code:

journalctl -b -D /mnt/var/log/journal/

Of course, this presumes the journal is persistent (/var/log/journal exists on the target); and, that boot proceeded far enough for mounting /, that it was mounted, and was written to, which I doubt from seeing the first image in post #18.

lattimro · 12-07-2023, 11:31 PM

Quote:

Originally Posted by mrmazda

If the installed system's / is accessible, then journalctl can be run using the -D option. From the man page:

Code:

       -D DIR, --directory=DIR
           Takes a directory path as argument. If specified, journalctl will operate on the specified
           journal directory DIR instead of the default runtime and system journal paths.

e.g.:

Code:

journalctl -b -D /mnt/var/log/journal/

Of course, this presumes the journal is persistent (/var/log/journal exists on the target); and, that boot proceeded far enough for mounting /, that it was mounted, and was written to, which I doubt from seeing the first image in post #18.

I'll try tomorrow afternoon and post it.
BTW, I have one ESP on HDD and one ESP on a portable SSD (Gecko is on /dev/sdc4)

Is there a /var/log/journal in Geckolinux? Not on my system? Is it on yours?
However this is what I have on mine:

Code:

root@rudy:/# ls /var/log/
Calamares.log         boot.log-20231020.xz  hp                    pk_backend_zypp-1                   wpa_supplicant.log
NetworkManager        boot.log-20231021.xz  krb5                  plymouth-debug.log                  wtmp
Xorg.0.log            boot.log-20231023.xz  lightdm               plymouth-shutdown-debug.log         wtmp-20230504.xz
Xorg.0.log.old        boot.log-20231024.xz  mail                  private                             xrdp-sesman.log
Xorg.1.log            boot.log-20231107.xz  mail.err              redis                               xrdp.log
YaST2                 boot.msg              mail.info             sa                                  zypp
acpid                 boot.omsg             mail.warn             samba                               zypper.log
alternatives.log      btmp                  messages              snapper.log                         zypper.log-20230912.xz
apparmor              cepces                messages-20231107.xz  teamviewer15                        zypper.log-20231016.xz
audit                 chrony                ntp                   tuned                               zypper.log-20231017.xz
boot.log              cups                  ntpstats              updateTestcase-2023-12-05-13-58-38  zypper.log-20231024.xz
boot.log-20231018.xz  firewall              pbl.log               updateTestcase-2023-12-05-19-39-06
boot.log-20231019.xz  firewalld             pk_backend_zypp       warn
root@rudy:/#

mrmazda · 12-07-2023, 11:57 PM

TBC, any reference to "Gecko*" in your posts is a reference to an openSUSE Tumbleweed installation, correct? Because, an openSUSE-based distribution named GeckoLinux also exists, so your use of Gecko anywhere here tends to obfuscate in this troubleshooting context.

lattimro · 12-08-2023, 04:53 AM

Quote:

Originally Posted by mrmazda

TBC, any reference to "Gecko*" in your posts is a reference to an openSUSE Tumbleweed installation, correct? Because, an openSUSE-based distribution named GeckoLinux also exists, so your use of Gecko anywhere here tends to obfuscate in this troubleshooting context.

I apologize for confusion, I realized lately myself this particular installation is a Geckolinux (which is still a rolling but separate project from OpenSuse TW). My labels referred to Gecko but Ubuntu (os-prober) see it as TW (see /boot/grub2/grub.cfg).

lattimro · 12-08-2023, 05:15 AM

Quote:

Originally Posted by colorpurple21859

The initrd may need to be regenerated, modules may be missing to access the root drive.

wouldn't enter in a panic state if something will be wrong with initrd? I believe at this point, for some reasons it can't find the root partition UUID=287blabla. Could be a fonts mistmach issue somewhere even when everything seems all right (grub.cfg)? As long as my outputs regarded Geckolinux posted here are from chroot environment how can one be sure what is in the native (Geckolinux) installation?

colorpurple21859 · 12-08-2023, 09:26 AM

Editing the linux line of the the grub menu and change root=UUID=..... to root=/dev/sdc4 should determine if the problem is with the initrd or not.

lattimro · 12-08-2023, 01:48 PM

Quote:

Originally Posted by colorpurple21859

Editing the linux line of the the grub menu and change root=UUID=..... to root=/dev/sdc4 should determine if the problem is with the initrd or not.

I remember I did that and was waiting (no limit). I will try again and post it

... It does the same thing is it now looking for /dev/sdc4