Been running Lu 20.10 for a few months, overall pretty clean system, but I have posted previously about “slow boot times,” I think that problem remains. Over in U-MATE 20.10 there were enough problems with the install, crashes on booting that made for slow booting, that I wiped that install and went to Debian. I think some of those problems have filtered over from main channels??? Once logged in Lu is able to fend for itself speed-wise, it just is slow getting logged in . . . .
And, I believe the issues with “grub” are still unsolved, so, I’ve had to use Synaptic to run upgrades in Debian and LM . . . so that I can uncheck the various “grub” packages . . . . However, in Lubuntu, launching Synaptic and clicking “mark all changes” . . . marks the grub packages, but then won’t “unmark” them . . . . Compared to Debian, where, when it offered me the grub packages a few upgrades back, I unchecked them, and now Debian isn’t asking again . . . but Lu keeps showing them to me, and then won’t let me un-select them??? in the gui . . . ??? I guess next step will be to “block them”??? I would prefer that ubuntu would get it’s grub issues solved and then be able to upgrade grub without having ubuntu wipe all the other distro connections, etc. Not holding y breath on that one.
Lastly, some problems with “suspend” have cropped up . . . today when I clicked suspend there was an error “lxqt-leave” that opened, and the machine didn’t suspend. Tried three times, then I logged out, and from there “suspended.” But, when trying to revive from suspend, now, keystroke or mouse click will not revive the session . . . have to hit the power button to “be woke.”
It might help for you to actually reference your specific problem with grub… there could be many.
I’m not exactly sure what your specific issue is… it sounds like you have more than one? or is it the one specific one you think is causing all your other problems?
Have you mentioned this in any other forum (since it sounds like you’ve tried other Ubuntu flavors)?
Thanks for the reply, I think I was pretty clear, the issues for Lubuntu 20.10 mentioned are now “slow boot times,” and “problems with suspend and revival from suspend.”
I just mention the grub issues, because a number of bug reports have been filed over many months, but the devs choose to see the problems as a “good thing”??? Had a little flurry of activity on one of the bug reports, but it seems like it too has gone the way of the dodo . . . .
Yes, I have posted on the main ubuntu forum as well as on other distros when the problem first showed up, big mess at the time, all grub links to all the other options were wiped and nobody knew why, etc. I have used a few versions of ubuntu over the last 12 to 13+ years, as well as branching off into other distros altogether, so I can do back to back comparos . . . like everything in life, each option has its strengths and weaknesses . . . right now grub is one area that ubuntu doesn’t seem to be focusing on . . . as far as being able to use grub to “multi-boot.” It only boots to ubuntu when updated in ubuntu, which is fine if all you want to run is ubuntu . . . not so fine if you want options . . . .
Thanks kindly for the interest in the problem, I consider it still to be there, but I’ve simply stopped updating grub on my 3 Debian/ubuntu based systems, or locked it, so I can’t say for sure . . . on my OpenSUSE & Manjaro installs I’ve continued to update without any problems to the multiboot listing or grub’s “visibility.”
Just a few days back somebody posted on Launchpad bug report on this topic that they still had the problem, and a couple of them found “solutions” by editing . . . ?? /etc/apt/grub ??? I checked mine and the solutions that were suggested didn’t seem to apply. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1863434
So, I have been hoping that the issue will be “fixed” upstream in the ubuntu world, it’s not impossible to repair the damages that were done by the apparent ubuntu’s handling of grub, but it consumed a lot of time previously and the devs didn’t seem to understand the problem on this bug report . . . so I haven’t checked it recently.
I have been having “slow boot” issues in Lubuntu groovy lately, I am considering adjusting the sources.list to change it to “hirsute” and see if that changes anything. That may or may not bring in the latest grub . . . with subsequent results to be determined.
The do-release-upgrade command is the recommended way to upgrade to a new version. It does more than just switch sources.
There are many possible reasons why the kernel is not updating but one that came to me is any dkms modules you have installed could also be blocking that. For example, if you have an Nvidia video card and you are using the Nvidia drivers then you have a dkms module loaded for that.
@wxl : OK, theories are good, not sure if grub would relate to the “focal” kernel in Lu . . . was thinking that LM & Debian are upgrading kernels, but those are both fresher installs.
@kc2bez : Alrighty, thanks for that suggestion on “do-release-upgrade” rather than just editing sources.list . . . . I’ve done a lot of installations over the years and the time consuming aspect is setting up the user stuff . . . somebody on a forum must have recommended editing sources.list and I did that a couple of rounds with Lubuntu, maybe going back to 18.04 on my desktop . . . . Didn’t have any problems previously but it did seem to run into issues in U-MATE 20.10 & Lu 20.10 . . . Lu dragging along on the focal kernel, etc.
I’d like to at some point try to get the ubuntu flavors to play nicely with the other OSs grub menu so that I could just run apt to keep it up to date. Was a hassle with the three ubuntu packages updating grub every couple of weeks and having the other distros wiped out with each update . . . very irritating. : - )
Posted a thread on Debian User forum yesterday asking about how to keep “grub” out of apt and got some interesting replies, the usual “gruff” stuff about the poster, but then some suggestions, including from one guy pointing out that in multiboot, “one system runs the grub show, so the rest could be uninstalled,” and then:
The grub-mkconfig script creates a menuentry that points to a specific kernel version so any new kernel versions will not be given a menuentry and the OP would be stuck with an outdated kernel.
If there is a problem with grub-mkconfig then we need to pin it down and report it as a bug so that it can be fixed, anything else is a counter-productive workaround.
Which may or may not be correct as I only started blocking grub updates a few months back, in the time after the time of focal . . . but, always interesting and always something to do . . . .
FYI: 21.04 hasn’t been released yet and is currently known by it’s codename hirsute. That doesn’t matter, but the key bit though is until release, it’s only available with the “-d” option of do-release-upgrade
From man do-release-upgrade
-d, --devel-release
If using the latest supported release, upgrade to the development release
Ah, right . . . I think I have that written down in my linux logbook . . . but just was checking out the command provided . . . . I’m OK with “early adapter” . . . I downloaded the 21.04 live iso and it ran fine . . . . I’m just trying to avoid having to mess with grub menu until after the holiday . . . .