[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.
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 goumba
Fonts have nothing to do with it. You'd just get a warning message and possibly a display that doesn't look great.
I asked that question because I noticed above "UUID blabla no-limit" message the Virtual Console Setup service failed. I masked the service but did not make any difference.
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 colorpurple21859
What about chroot into the system and run dracut for one of the kernel versions to see what happens?
I can do that but you need to tell me the command ... I mean dracut what? and what is the expected outcome? I am not sure if I can regenerate initrd.img from a chroot
To be sure of a reasonable answer (before colorpurple21859's post #55), I booted Slowroll, where the newest installed kernel is 6.5.9, and chrooted into TW 20231121, where the newest installed kernel is also 6.5.9. It had a corresponding 16,704,252 byte initrd with a 22 November timestamp. I issued:
Code:
dracut -f
It resulted in a currently timestamped 16,596,340 byte 6.5.9 initrd. If you're actually running Tumbleweed, and chrooting from a TW rescue media of close enough matching date, I would expect an equivalent result for you.
I dumped output from lsinitrd from each of the two initrds to files. I diff'd the two files and the result was 987 lines.
I then saved the new initrd, restored the original initrd, and booted TW directly to run dracut -f again. This one came out to 16,702,240 bytes. I saved it too. Then I successfully rebooted directly into TW, restored the 1st initrd rebuild, and rebooted successfully again. A diff between the 1st and 3rd initrds was 994. Between 2nd and 3rd was 981.
I suppose it could somehow become necessary to run dracut specifically identifying the version to get the correct kernel rebuilt. So, I booted Ubuntu 22.04 and chrooted into TW. Next I ran dracut -f -k 6.4.12-1-default, which resulted in error messages and no new initrd. So did dracut -f -k /usr/lib/modules/6.4.12-1-default, which also failed. Next I followed one of the error message instructions: export DRACUT_KMODDIR_OVERRIDE=1, but it didn't help. Next try, without thinking to first nullify DRACUT_KMODDIR_OVERRIDE=1, worked, 16,019,264 bytes:
Code:
dracut -f --kver 6.4.12-1-default
Thus I can't say whether DRACUT_KMODDIR_OVERRIDE=1might have been necessary. I suppose not. The 6.4.12 boots with its new initrd too.
If you are in the habit of using zypper up without also using zypper dup, that explains any number of problems. Only dup should be used, or if up is used, it needs to be done with the awareness of the possible consequences. TW is a rolling release. Each edition of TW is an upgrade. Thus, only dup can complete the process, so required package changes can be left undone by doing only up.
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 goumba
Likely a new kernel was installed and therefore your initrds were rebuilt for you.
As mrmazda and pretty much every source of documentation says for TW, use zypper dup with Tumbleweed.
Leave that alone, it's there for a reason.
I just wanted to replicate the initial issue with booting because so far we do not know why the root partition "was not found". I expected you can explain why was able to boot without that line I temporarily removed for testing purpose.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.