When booting from fresh DVD 20.04 LTS, 21.04 and 22.04 nightly build all stall at failures to start Modem mgr, Disk mgr and SNAP daemon on 20.04 LTS, 21.04 LTS and 22.04 nightly aa0b4d/Linux 5.1`5.0 dr. This is consistent behavior on various desktop systems ranging from i7 8 core 16GB ram to dual core intel and amd mobos with 2-4GB ram. The install eventually completes and while waiting boot DVD is active. Depending on system power the completed boot may hang per above from a few to several minutes. Installations to HDD go normally and systems perform without any obvious issues. Is this old news?
Please be specific with details; Ubuntu 21.04 is not an LTS release which is why it’s EOL having exceeded it’s nine months of life, so why try something that isn’t supported?
I don’t know what you mean by “aa0b4d/Linux 5.1`5.0 dr.” as if you grab the current dailies; I see
http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/244544/testcases
with the jammy daily 20220221 (yyyymmdd format)
You look in download info & see the date; though on installs & install media I generally look for it /etc/apt/sources.list as the date is in the first line comment
For the focal daily I see 20220217 (again yyyymmdd format)
Thus its common for multiple dailies to have the identical date so the daily date is usually used with the codename (jammy for what will be 22.04, focal for what will be 20.04.4 which is the next release).
You’ll note the focal hasn’t changed in a few days, as it’s likely reached RC state and re-spins are now only if mandated (daily should be understood as interval really; it’s weekly often early in the cycle; but shifts to daily most of the cycle; then as required late in the cycle as it is with focal).
For us to clearly understand your issue, providing pastes of the commands & output you get showing why you believe show the issue will help us to understand, and then provide meaningful & helpful replies.
If you’re watching boot messages during boot; the actual issues for stalls are not usually visible on screen, ie. the last message is something that has already completed & was ok/failed & thus was reported as such… ie. are you referring to what’s on screen during boot (ie. events in the past) or via logs reading the lines subsequent to what you saw on screen during the boot process during ‘pauses’ (ie. the slow processes that didn’t appear quickly)?.
Boot logs are where I’d look, and providing portions (or the whole via pastebin) may help others to look for you, and with luck provide some clues on finding your issues.
Do NOTE however, live systems boot speed isn’t a major concern (I’ve a box which takes ~10 minutes to boot recent live release due to issues in the boxes firmware) as once installed the system is as quick as any; but trying to have the ISO/installation-media deal with every boxes somewhat-unique firmware just makes the ISO for everyone larger, but impacts 0.05% boxes in actual use.
2 Likes
Ubuntu 21.04 is not an LTS release
yes I realize that. I’m a 70 yo man and like most oldies my short term memory is deteriorating. you’ve seen that in a previous post from me
so why try something that isn’t supported?
**Because I’m shopping for an upgrade candidate from 18.04, not bug testing. I’m forced to abandon 18.04 because latest builds of specialty SDR software I use require a later Linux version. I stumbled onto this delay behavior while auditioning a lot of Lubuntu distros but did not see it on Xubuntu 20.04.3 or Ubuntu 20.04.3. I’m simply a long time Lubuntu end user (since 14.04) and want to add to my practical knowledge of Linux as well as gaining more information about what makes the watch tick. **
I don’t know what you mean by “aa0b4d/Linux 5.1`5.0 dr.” as if you grab the current dailies;
This message appeared on screen with the FAILED to load messages and appeared to be indicating a kernel version so I thought it might be relevant. Why would I think otherwise?
Lubuntu 24.04 (Noble Numbat) Daily Build is where I got my 22.04 download so I presumed it refereed to daily builds. I called it nightly because other sites often use that term.
http://iso.qa.ubuntu.com/qatracker/milestones/429/builds/244544/testcases
You look in download info & see the date; though on installs & install media I generally look for it /etc/apt/sources.list as the date is in the first line comment
For the focal daily I see 20220217 (again yyyymmdd format)
Thus its common for multiple dailies to have the identical date so the daily date is usually used with the codename (jammy for what will be 22.04, focal for what will be 20.04.4 which is the next release).
You’ll note the focal hasn’t changed in a few days, as it’s likely reached RC state and re-spins are now only if mandated (daily should be understood as interval really; it’s weekly often early in the cycle; but shifts to daily most of the cycle; then as required late in the cycle as it is with focal).
Good tutorial
For us to clearly understand your issue, providing pastes of the commands & output you get showing why you believe show the issue will help us to understand, and then provide meaningful & helpful replies.
I agree but how does one cut and paste screen messages while the script is running? I suppose piping could be used but why go to that effort if asking a quick question will suffice?
If you’re watching boot messages during boot; the actual issues for stalls are not usually visible on screen, ie. the last message is something that has already completed & was ok/failed & thus was reported as such… ie. are you referring to what’s on screen during boot (ie. events in the past) or via logs reading the lines subsequent to what you saw on screen during the boot process during ‘pauses’ (ie. the slow processes that didn’t appear quickly)?.
**Nothing new to me there, and not necessary to elicit a simple yes or no reply to an Anybody seen this before? type question **
Boot logs are where I’d look, and providing portions (or the whole via pastebin) may help others to look for you, and with luck provide some clues on finding your issues.
Do NOTE however, live systems boot speed isn’t a major concern (I’ve a box which takes ~10 minutes to boot recent live release due to issues in the boxes firmware) as once installed the system is as quick as any; but trying to have the ISO/installation-media deal with every boxes somewhat-unique firmware just makes the ISO for everyone larger, but impacts 0.05% boxes in actual use.
**You make sense here if I were part of the dev team, but as an end user I dispute the opinion. I waited much longer than 10 minutes using 21.10 on my 8 core i7, watching FAILED to start SNAP Daemon messages accumulate before I finally gave up. Seems to me that is unacceptable feature from an end user’s point of view. I will further opine that although (probably) an unrelated behavior, many posts on the net complain of unacceptably long boot times due to SNAP daemon loading during installed system boot. I verified this using systemd-analyze blame command on my 20.04.3 Xubuntu that developed much longer boot times after doing a regular system update **
I posted in dev hoping to get KC2BEZ’s attention. Next time I’ll skip this board.
You will receive notifications because you created this topic.
1 Like
Personally I think all of Ubuntu & flavors are equal for a given release; as it’s rare that a problem that impacts one doesn’t impact others, eg. the bug I mentioned that causes Lubuntu groovy → impish to take ~10 minutes to boot, impacts main Ubuntu & all other flavors too equally (Lubuntu boots the fastest as we’re just under 10 minutes; where some are ~11 mins)
Lubuntu uses LXQt now, ie. Qt5; so I’d pick the flavor or desktop more on what libraries/toolkits the application you need to run, particularly if your box is resource limited. Are you aware that changes were made to ISOs for 20.04 & up that can mean Ubuntu 20.04 LTS will differ to flavors of 20.04 using the same ISO with regards kernel stack. Lubuntu is a flavor thus 20.04 & 20.04.1 media use the GA kernel stack by default just as with 18.04 & before; however Ubuntu 20.04 LTS Desktop now defaults to HWE stack for all installs of 20.04 (regardless of media/patch-level used).
In this regards Xubuntu & Lubuntu 20.04 are identical, however Xubuntu ISOs used the ubiquity installer which can cause the install to detect hardware that will benefit from an OEM kernel stack & use that instead. Lubuntu media uses calamares and does not provide OEM support (that is done post-install).
Thus differences can occur between Xubuntu, Ubuntu & Lubuntu as I’ve attempted to outline here.
Thanks
You’re getting it from the correct site which is what matters. Yeah some do call it nightly.
I’d use dmesg to view the boot messages; yes you may find additional details using other commands too (eg. journalctl) but dmesg is where I’d look to copy/paste or remind myself of boot messages
I hadn’t noticed it was posted in development; so thanks for alerting me (it’s now moved to support). You should tag Dan if you want him to see it, as anything posted on this site generally gets my attention (one of my Lubuntu responsibilities), and I’ll tag [or inform others] others when I deem necessary. I don’t see anything as related to Ubuntu jammy worthy of notice given it’s very late in the cycle and the booting of the media is mostly upstream Ubuntu product anyway.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.