Closed aravindvnair99 closed 9 months ago
+1 on using sed
. You don't have a CLI for step 2, but I assume by "and upgrade" your mean apt update && apt upgrade -y
, not do-release-upgrade
.
If you did a do-release-upgrade
at step 2, don't. LZ for that much is #994. [Folks are working around by purging snapd
before the upgrade but that is by-fortune not by-design. The problem is more general than just snapd
.]
Under "Actual Behavior" you've got groovy
hits despite the sed
, which means you haven't got them all. That is going to fail in unexpected ways as linux behavior.
The microcode fail is either amd64-microcode or intel-microcode. Those packages are unsupported by-design. They are not installed in the Ubuntu-20.04 from the Store; how they got installed on your system is unknown (and likely unknowable). Purge 'em. Like grub
and a few other packages on the border, those userspace packages could in principle be improved to better accommodate WSL, which would make a good discussion if someone wants to entertain one.
@therealkenc Thank you for your response!
I assume by "and upgrade" your mean
apt update && apt upgrade -y
, notdo-release-upgrade
.
After spending hours and getting frustrated, I ended up typing: apt update && apt upgrade -y && apt full-upgrade -y && apt dist-upgrade -y && apt autoclean -y && apt autoremove -y && apt update && do-release-upgrade
. I did that after I was facing the same issue mentioned at https://github.com/microsoft/WSL/issues/6942#issue-891699634. I had successfully upgraded without any issues a few weeks ago. That's what left me confused as after I reinstalled Windows a week later, I ended up with the same issue as mentioned there and after a lot of hunting on the internet, I decided to do the commands I mentioned.
If you did a
do-release-upgrade
at step 2, don't. LZ for that much is #994. [Folks are working around by purgingsnapd
before the upgrade but that is by-fortune not by-design. The problem is more general than justsnapd
.]
Ahh I see... Would you recommend me clearing the app data for the distribution and setting it up again to start fresh and only do apt update && apt upgrade -y
? Or should I continue using what I currently have? What would your suggestion be?
Under "Actual Behavior" you've got
groovy
hits despite thesed
, which means you haven't got them all. That is going to fail in unexpected ways as linux behavior.
My bad, I only pasted one output. I did get the output for both groovy
and hirsute
as intended. I am currently on hirsute
.
user@host:~$ sudo lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 21.04
Release: 21.04
Codename: hirsute
The microcode fail is either amd64-microcode or intel-microcode. Those packages are unsupported by-design. They are not installed in the Ubuntu-20.04 from the Store; how they got installed on your system is unknown (and likely unknowable). Purge 'em. Like
grub
and a few other packages on the border, those userspace packages could in principle be improved to better accommodate WSL, which would make a good discussion if someone wants to entertain one.
I don't have either packages installed though.
user@host:~$ dpkg -l | grep microcode
user@host:~$
Would you recommend me clearing the app data for the distribution
Doesn't hurt.
and only do apt update && apt upgrade -y?
Yes. There is a rando guide cited in #6942 (message) which sketches the general idea.
Or should I continue using what I currently have?
"Should" is in the eye of the beholder. Me, I would update whatever software (let's say mesa
) that was critically blocking my workflow on 20.04 from continuing that day. Second behind that would be wsl --import
ing a groovy or hirsute tarball. And a very distant third would be doing the sed
on sources.list
approach with apt update
followed by apt upgrade
.
I don't have either [amd64-microcode or intel-microcode] packages installed though.
On a closer look, it appears that "Failed to check for processor microcode upgrades
" comes from the needrestart package (source) which I think (?) goes down the rabbit hole of evoking iucode_tool(8)
. You can try apt purge needrestart
. I don't think it is your fatal.
Would you recommend me clearing the app data for the distribution
Doesn't hurt.
and only do apt update && apt upgrade -y?
Yes. There is a rando guide cited in #6942 (message) which sketches the general idea.
Or should I continue using what I currently have?
"Should" is in the eye of the beholder. Me, I would update whatever software (let's say
mesa
) that was critically blocking my workflow on 20.04 from continuing that day. Second behind that would bewsl --import
ing a groovy or hirsute tarball. And a very distant third would be doing thesed
onsources.list
approach withapt update
followed byapt upgrade
.
@therealkenc Thanks for the link! I decided to wipe clean and start over. I removed the app data for Ubuntu and upgraded it by modifying the sources.list
without do-release-upgrade
one at a time. The situation is still the same though as before although everything seemed fine both then and now as well. Occasionally I get the following when installing stuff:
Scanning processes...
Scanning processor microcode...
Scanning linux images...
Failed to retrieve available kernel versions.
Failed to check for processor microcode upgrades.
No services need to be restarted.
No containers need to be restarted.
No user sessions are running outdated binaries.
I don't have either [amd64-microcode or intel-microcode] packages installed though.
On a closer look, it appears that "
Failed to check for processor microcode upgrades
" comes from the needrestart package (source) which I think (?) goes down the rabbit hole of evokingiucode_tool(8)
. You can tryapt purge needrestart
. I don't think it is your fatal.
I do have that package installed:
user@host:~# apt search needrestart
Sorting... Done
Full Text Search... Done
needrestart/hirsute,now 3.5-2ubuntu2 all [installed,automatic]
check which daemons need to be restarted after library upgrades
needrestart-session/hirsute 0.3-8 all
check for processes need to be restarted in user sessions
@therealkenc
If you did a
do-release-upgrade
at step 2, don't. LZ for that much is #994. [Folks are working around by purgingsnapd
before the upgrade but that is by-fortune not by-design. The problem is more general than justsnapd
.]
Thanks for your explanation.
2 questions:
snapd
, am I good, or do I need to rebuild?LZ
?
- if I got around it (before reading your post) by purging
snapd
, am I good, or do I need to rebuild?
You should be good. No need to rebuild.
- what is
LZ
?
Landing zone. Military jargon in this context used to mean the current cannonical destination.
Here's a comprehensive explanation. Two ways to solve this:
/etc/needrestart/needrestart.conf
:$nrconf{kernelhints} = 0;
$nrconf{ucodehints} = 0;
This will remove the hint Failed to retrieve ...
, but other hints like No containers ...
still exist.
sudo apt purge needrestart
I used method 2 and everything works just fine.
I think the "needrestart" package is a clue. I was getting this error immediately after installation. The error no longer appeared after a restart.
sudo apt install --only-upgrade
This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.
Thank you!
Windows Build Number
Microsoft Windows [Version 10.0.19043.1052]
WSL Version
Kernel Version
Linux version 5.4.72-microsoft-standard-WSL2 (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Wed Oct 28 23:40:43 UTC 2020
Distro Version
Ubuntu 21.04 Hirsute Hippo
Other Software
No response
Repro Steps
focal
gets installed.groovy
bydo-release-upgrade
and it does not install.sed --in-place 's/focal/groovy/g' /etc/apt/sources.list
and upgrade.lsb_release -a
hirsute
bydo-release-upgrade
and it does not install.sed --in-place 's/groovy/hirsute/g' /etc/apt/sources.list
and upgrade.Failed to retrieve available kernel versions.
Failed to check for processor microcode upgrades.
No services need to be restarted.
No containers need to be restarted.
Expected Behavior
Was expecting it to upgrade successfully without errors.
Actual Behavior
Diagnostic Logs
No response