[SOLVED] A start job is running for /dev/disk/by-uuid
SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
What does your /boot/grub2/grub.cfg look like? Is that identified as your root partition? Do the same grep that you did against /etc/fstab to ensure that it was correctly identified as your root partition post-upgrade. You might need to edit that file and re-install grub if not.
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
Quote:
Originally Posted by ember1205
What does your /boot/grub2/grub.cfg look like? Is that identified as your root partition? Do the same grep that you did against /etc/fstab to ensure that it was correctly identified as your root partition post-upgrade. You might need to edit that file and re-install grub if not.
As long as during booting "A start job is running for /dev/disk/by-uuid/287a2f71-d2d0-45d8-b300-82a19b18f1aa" occurred one may thinks that UUID is coming from /boot/grub2/grub.cfg and assume that the /boot/grub2/grub.cfg entries (particularly the root partition) are correct. This was the reason I did not posted it here. If otherwise one may be sure I would have corrected it.
Code:
grep -r 287 /boot/grub2/grub.cfg
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
menuentry 'openSUSE Tumbleweed' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
linux /boot/vmlinuz-6.6.3-1-default root=UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa security=apparmor
submenu 'Advanced options for openSUSE Tumbleweed' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
menuentry 'openSUSE Tumbleweed, with Linux 6.6.3-1-default' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.6.3-1-default-advanced-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
linux /boot/vmlinuz-6.6.3-1-default root=UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa security=apparmor
menuentry 'openSUSE Tumbleweed, with Linux 6.6.3-1-default (recovery mode)' --hotkey=3 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.6.3-1-default-recovery-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
linux /boot/vmlinuz-6.6.3-1-default root=UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa single
menuentry 'openSUSE Tumbleweed, with Linux 6.5.9-1-default' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.9-1-default-advanced-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
linux /boot/vmlinuz-6.5.9-1-default root=UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa security=apparmor
menuentry 'openSUSE Tumbleweed, with Linux 6.5.9-1-default (recovery mode)' --hotkey=1 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.5.9-1-default-recovery-287a2f71-d2d0-45d8-b300-82a19b18f1aa' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt4 --hint-efi=hd2,gpt4 --hint-baremetal=ahci2,gpt4 287a2f71-d2d0-45d8-b300-82a19b18f1aa
search --no-floppy --fs-uuid --set=root 287a2f71-d2d0-45d8-b300-82a19b18f1aa
linux /boot/vmlinuz-6.5.9-1-default root=UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa single
As long as during booting "A start job is running for /dev/disk/by-uuid/287a2f71-d2d0-45d8-b300-82a19b18f1aa" occurred one may thinks that UUID is coming from /boot/grub2/grub.cfg and assume that the /boot/grub2/grub.cfg entries (particularly the root partition) are correct. This was the reason I did not posted it here. If otherwise one may be sure I would have corrected it.
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
Quote:
Originally Posted by ember1205
Huh. Seems like you know it all, then.
not really ... as long have been posted here. At first it looks like UUID is correct but who knows why is complaining. I did what I have done many times before and TW did not complain.
Unfortunatelly the OpenSUSE forums was hacked most likely and redirects the new users to 'univention' portal
all of /etc/fstab (from installed system) and input/output from lsblk -f and efibootmgr
Input/output means one whole transaction, within one pair of code tags: 1: the prompt with command; 2: the command's output; and 3: the following prompt, exactly as it appeared on your screen. This allows to understand that what was asked for matches what was provided. Blkid doesn't provide all that I asked for, and neither does lsblk without -f. Example (with bulk of UUIDs redacted):
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
Quote:
Originally Posted by mrmazda
I asked for Input/output means one whole transaction, within one pair of code tags: 1: the prompt with command; 2: the command's output; and 3: the following prompt, exactly as it appeared on your screen. This allows to understand that what was asked for matches what was provided. Blkid doesn't provide all that I asked for, and neither does lsblk without -f. Example (with bulk of UUIDs redacted):
I did not posted efibootmgr because this TW is MBR.
I do not know if you realized that unlike you, I cannot boot my TW. My outputs are just chroot environment. Thanks for your inputs.
I will re-posting the output directly from ubuntu (not from chroot):
root@zika:/# more /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=287a2f71-d2d0-45d8-b300-82a19b18f1aa / ext4 defaults,noatime 0 1
UUID=6698c5bc-845b-4917-a290-bbf867e4410a /home ext4 defaults,noatime 0 2
UUID=52A8-414E /boot/efi vfat defaults 0 1
/dev/disk/by-uuid/044e6eb7-82ef-4199-9cb9-dab0a84ec932 none swap sw 0 0
root@zika:/#
Unfortunatelly the openSUSE forums was hacked most likely and redirects the new users to 'univention' portal
It wasn't hacked. It did have sporadic downtime recently due to migration of servers to a different city. It has been steadily working OK for me since sometime last week.
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
Quote:
Originally Posted by mrmazda
It wasn't hacked. It did have sporadic downtime recently due to migration of servers to a different city. It has been steadily working OK for me since sometime last week.
Your sda appears to be MBR partitioned, but your TW fstab says you are UEFI configured. Also you have two ESP partitions, one on sda, the other on sdc. Absent efibootmgr -v output, I don't expect to be of any more help.
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
Quote:
Originally Posted by mrmazda
Your sda appears to be MBR partitioned, but your TW fstab says you are UEFI configured. Also you have two ESP partitions, one on sda, the other on sdc. Absent efibootmgr -v output, I don't expect to be of any more help.
you are correct, it is bit of predicament due to my machine BIOS. I have this configuration since 2014-2015 maybe and worked OK. As far as I remember TW was UEFI but right now because I can't boot TW, when I chroot from ubuntu (which is MBR/GPT!) the output is not relevant. I do not know if this make sense for you? Thanks!
Code:
root@zika:/home/brad# efibootmgr -v
EFI variables are not supported on this system.
the next output is from ubuntu (booted from /dev/sdc3):
root@zika:/home/brad# update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Sourcing file `/etc/default/grub.d/oem-flavour.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.2.0-37-generic
Found initrd image: /boot/initrd.img-6.2.0-37-generic
Found linux image: /boot/vmlinuz-6.2.0-36-generic
Found initrd image: /boot/initrd.img-6.2.0-36-generic
Memtest86+ needs a 16-bit boot, that is not available on EFI, exiting
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Manjaro Linux (23.1.0) on /dev/sda10
Found Windows Boot Manager on /dev/sda3@/EFI/Microsoft/Boot/bootmgfw.efi
Found openSUSE Tumbleweed on /dev/sdc4
Adding boot menu entry for UEFI Firmware Settings ...
done
root@zika:/home/brad#
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.
Distribution: SOLARIS/BSD-like, some Debian-like, some Arch-like, some GENTO-like, some RH-like, some slacky-like
Posts: 386
Original Poster
Rep:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
