apt -y update →
N: Skipping acquire of configured file ‘main/binary-i386/Packages’ as repository ‘https://repo.saltproject.io/py3/ubuntu/20.04/amd64/latest focal InRelease’ doesn’t support architecture ‘i386’
Is this known/expected/innocuous?
cheers - ray
Yes, all of the above.
If you’ve already applied this formula and your WiFi suddenly stopped working around mid-January 2022, without explanation, chances that your system got upgraded to Linux 5.13. The AX210 workaround used for Linux 5.11 breaks WiFi on 5.13. In order to get your WiFi working, execute the following:
sudo systemctl disable intel-ax210-workaround.service
sudo mv /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm.renamed-by-salt /lib/firmware/iwlwifi-ty-a0-gf-a0.pnvm
sudo rmmod iwlmvm
sudo rmmod iwlwifi
sudo modprobe iwlwifi
Following that, pull the latest formula and execute it again in order to remove the workaround completely. Executing the command from the TL;DR in a clean location should also do the trick.
Hm. Now I wonder if I should upgrade to that version of the kernel. I deleted the file manually, following notes I found before I found salt. Anything to worry about?
If you’ve deleted it, your WiFi will die with 5.13. You can restore it by reinstalling the linux-firmware package:
sudo apt --reinstall install linux-firmware
Confirmed that fingerprint reader now works with the latest fprintd from focal-updates, namely 1.90.9-1~ubuntu20.04.1. Updated formula to use the built-in packages. If you’ve already ran the formula, pulling the latest and running it again will purge the prebuilt packages and install the Ubuntu-supplied ones.
Thank you for the update! I ran the commands, got my wifi reconnected, pulled the update for the formula, and reran it and everything is working as it did before. You’re a life saver!
Updated with support for Ubuntu 22.04, including post-upgrade cleanups of things that are no longer needed. Just grab the latest source and re-run the formula after upgrading.
This doesn’t seem to be configuring hibernation for 22.04. I have 2Gb swapfile already from the fresh install and its not being replaced. Also, my framework does not hibernate when the lid is closed and triggering hibernation from the terminal just causes it to hibernate then immediately wake back up.
Very interesting. I believe I tested hibernate on fresh install but it’s not impossible that I didn’t or that there’s an interesting bug. Can you post a log (all the output from running the command)?
EDIT: Also did you specifically run the hibernate state, and did you run it twice? The formula does not apply hibernate by default and the state has to be run twice. Posting a log will reveal exactly what was run and what the results were.
Hey guys!
I was hoping somebody else had my experience and could help out. I am on Ubunutu 22.04 and the salt script listed above is not playing nice. I try to see if tlp is installed after I run the script but it is not. Grub timeout is also not changed. I am concerned the script is failing as it is giving me a weird error code too.
[ERROR ] Failed to import module pip, this is due most likely to a syntax error:
Traceback (most recent call last):
File “/usr/lib/python3/dist-packages/salt/loader/lazy.py”, line 766, in _load_module
mod = self.run(spec.loader.load_module)
File “/usr/lib/python3/dist-packages/salt/loader/lazy.py”, line 1201, in run
return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs)
File “/usr/lib/python3/dist-packages/salt/loader/lazy.py”, line 1216, in _run_as
return _func_or_method(*args, **kwargs)
File “”, line 548, in _check_name_wrapper
File “”, line 1063, in load_module
File “”, line 888, in load_module
File “”, line 290, in _load_module_shim
File “”, line 719, in _load
File “”, line 688, in _load_unlocked
File “”, line 883, in exec_module
File “”, line 241, in _call_with_frames_removed
File “/usr/lib/python3/dist-packages/salt/modules/pip.py”, line 87, in
import pkg_resources # pylint: disable=3rd-party-module-not-gated
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 3267, in
def _initialize_master_working_set():
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 3241, in _call_aside
f(*args, **kwargs)
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 3279, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 573, in _build_master
ws.require(requires)
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 891, in require
needed = self.resolve(parse_requirements(requirements))
File “/usr/lib/python3/dist-packages/pkg_resources/init.py”, line 777, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The ‘contextvars’ distribution was not found and is required by salt
The error you see is benign. It’s caused by a bug in Salt, I think because 22.04 isn’t officially released yet and as such not officially supported distribution yet. It doesn’t affect the functionality of the salt formula.
The framework-laptop-formula doesn’t install TLP on 22.04 because it might conflict with the built-in power-profiles-daemon and also because the latter does a pretty good job at limiting power consumption when you activate “Power Saver” from the top-right menu in GNOME. I did a few measurements and both yielded the same ballpark power consumption so I decided to leave the default solution as-is. If you prefer TLP, you’d have to install it manually as well as manually disable power-profiles-daemon. There are guides about it out there. For most people the default solution is probably going to be good enough.
As for the GRUB timeout, are you using /boot on LVM? That’s the only case when its timeout is reduced.
Hi, @lightrush you just commented on my post about wifi not working after a 22.04 update. As I said in that post, I resolved that issue by updating the BIOS, but I’m now running into an issue that I saw after I initially setup Ubuntu when I received my batch 4 Framework. After I suspend, when I wake, my OS will lock up. I solved this (I think) initially by removing the mem_sleep_default=deep option from my grub config after following this guide. If I’m remembering correctly, it turned out that deep sleep was already enabled and that seemed to be causing the issues. My system ran stably since then. After updating to 22.04 yesterday, my OS would again would lock up after resuming from suspend. If I dropped into tty, I’d get an endless stream of EXT4-fs errors seemingly when trying to read from the disk. I tried running your script (which I did not do when I setup my laptop), and it didn’t resolve it. I also added the mem_sleep_default=deep to grub again, but this did not resolve it. I’ve since installed 22.04 from scratch (and am using Gnome instead of i3-gaps as I was previously), and I’m now having similar–but different–issues. Now, after resuming from sleep, the OS will drop into tty, and print an endless stream of messages saying the file system is read only. From some Googling, I’m seeing very few other people running into the same issue, and most of them either magically start working after some time or suggestions that the disk is failing. This is a brand new Saberent disk, so I’d be surprised if that was the case. I’m still not sure if the cause of this is the 22.04 update or the BIOS update.
EDIT: Forgot to mention that I’m now reinstalling 21.10 from scratch and running your post install script once it’s done. The /etc/default/grub.h/hibernate.cfg that the script sets up puts my grub config in the same place that it was before upgrading to 22.04.
Just verified that downgrading to 21.10 solves the issue. I’m wondering if this is some kind of hardware/kernel issue with my disk maybe??? The disk is a Sabrent 512GB Rocket NVMe PCIe M.2 2280. I’m thinking about reinstalling 22.04 and mailing my /var/log directory to Framework. I can’t parse anything useful from the logs myself. This is a batch 4 DIY and I supplied my own disk and RAM. It’s incredibly odd that I seem to be an outlier here. Trying to think of things that may set my laptop apart from others.
Certainly sounds like one or the other. Try a different SSD. Something from WD or Samsung.
Unfortunately, I’ve only got one other NVME disk, and it’s being used on my gaming rig.
Added installation of HiRes codecs for PulseAudio to use with Bluetooth receivers and headsets. Both versions of gstreamer and PulseAudio in Ubuntu 22.04 now support this but the gstreamer plugins aren’t installed by default due to licensing issues. Tested with my FiiO BTR3K - it uses aptX automatically.
Just wanted to provide an update on my issue. I bought a Samsung 980 Pro, and the system is no longer locking up after suspend. So it looks like the disk is the problem, though I still don’t know what the actual problem is. Wish me luck trying to get an RMA with Sabrent support.