OK, tomorrow I’ll try again. I tried Fedora 35 and while it seemed to work out of the bag, I came to realize once again why I love the LTS releases the most.
Those words have come out of my mouth so many times over the years. 
I think I stopped installing non-LTSes after 12.04 or 14.04.
Ok, so I’ve got Ubuntu 20.04 back on the Framework and it is all setup beside a few SSH connections I still need to add, but this time the salt script seemed to work. Of the 20 actions it was supposed to do it said that 19 were successful. I think the 1 second timeout on the grub menu is what failed. My guess is because this is a dual boot with Ubuntu installed after Windows.
As a side note for anyone trying to get hibernation working in a similar situation as me (Windows and Linux installed), you have to disable secure boot or hibernation will not be available to the kernel. Hopefully they fix that.
Not a big deal as the main reason I installed Linux was so I could have standard suspend to RAM functionality.
Thanks again for your efforts! So nice to have a LTS distro fully set up again.
1 Like
Much better. Thanks for verifying!
Interesting. I disable secure boot habitually in order to not hit any unsolved corner cases. I didn’t know that hibernation is one of those.
I do wonder how things with 20.04 are going to be handled when 22.04 LTS comes out. 22 will include power profiles and already have some battery management stuff included.
Not too worried, I’m quite comfy on 20.04.
Thanks once again for the help. I do wonder why the grub timeout failed though. Do you think it has to do with me installing Windows first on the machine, such that grub is not the only bootloader found?
Hopefully it won’t need any of the workarounds. I’m actually going to put a check to run the states needed for 20.04 only on 20.04.
Maybe. If you re-run it and get the failure again, and paste it here, I’ll probably be able to tell. It won’t break anything it already did.
Here you go:
One other issue I’m having is that even though the fingerprint reader is showing to the kernel, I’m unable to use. Anytime I try to register a finger it has an error. Nothing to do with your script, but just something else I’m noticing.
Damn. No error now. Seems to have reapplied the mem-sleep-default that was commented out.
Did you have fingerprints enrolled in a previous OS install? For me it stopped working on a fresh install after I had fingerprints enrolled in my previous. I had to delete them first. There’s a script someone wrote which I included and is installed by default for this - /usr/local/bin/libfprint_delete_device_prints.py -d. I’m not sure if registering fingerprints in Windows causes the same problem when you boot into Ubuntu as well.
Yeah I think Windows has it locked out due to the security scheme it is using. My guess is that if I deleted all stored prints it would start working but would no longer work with Windows.
I’ll keep this in mind in case I ever get to the point of wiping windows and just using Ubuntu.
Most likely. Which is why I probably shouldn’t be running the fingerprint deletion by default. 
It only runs the first time when fingerprint packages are installed, but if you have already fingerprints setup in Windows at that point, you may get surprised as to why they stopped working.
Hi, I installed 20.04 and ran this and everything went fine, but now I’m noticing the following in my /var/log/syslog:
Oct 24 12:02:18 framework salt-minion[1207]: [ERROR ] Error while bringing up minion for multi-master. Is master at salt responding?
Oct 24 12:03:08 framework salt-minion[1207]: [ERROR ] Error while bringing up minion for multi-master. Is master at salt responding?
Oct 24 12:03:58 framework salt-minion[1207]: [ERROR ] Error while bringing up minion for multi-master. Is master at salt responding?
Any idea on how to get that to stop complaining?
That’s normal. You can likely get rid of it by telling the salt minion that there’s no master to connect to by doing this - Salt Masterless Quickstart. But that’s just config so I should just add another state to the formula to do it automatically. Another option is to uninstall salt from the machine if you don’t need to run the formula again or if you don’t run it often. And finally, you can just ignore it. It’s not causing anything other than wasting your battery. I probably haven’t noticed it because I’m actually using a salt master so it manages to connect.
EDIT: Sadly the suggestion in the docs wasn’t enough. It also requires master_type: disable. I’m putting up a new state that will do this by default as well as disable the service which seems to be a-OK according to salt’s developers.
1 Like
@Dan_Brakeley If you haven’t opted to uninstall salt, pull the latest version of the formula and re-apply. It will re-configure the minion and disable the service for you.
And now onto unscrewing my own minion that has to talk to a master.
Did anyone test this on 21.04?
Hi @lightrush thanks for sharing these scripts. I used this as part of the process to setup the new framework I bought my wife for Christmas. I wanted to make sure she gets an LTS release, since the “official” recommendation of 21.04 will lapse in support before the next 22.04 LTS. Plus, there are lots of reasons to think 20.04 is a great place to park LTS users while some kinks are worked out, e.g. in the transition of certain packages to snaps. I’m confident the user experience will much better soon, but I wouldn’t want her wondering why e.g. launching zoom calls from the Firefox snap isn’t quite reliable. (This is an example I’ve run into, as this is exactly the setup I run on my laptop.)
At any rate, I have a suggestion for the scripts: supporting a swap partition. I put btrfs on the system so that I could use snapper+borg to provide automatic full-system backups. Now there is a well known issue with btrfs, where swapfiles are not supported. There is a similar issue with zfs as well, afaict. So, in order to ensure both of my requirements of fully-system backups along with power-saving hibernation, I created a swap volume in lvm. I was able to use your script as a guide to setup the hibernation hooks for lid closure, but it would be beautiful to just run salt, for when my laptop bites the dust and I buy my own framework! 
As an aside, I also ran into a journal log of “suspend-then-hibernate not supported” when I tried to enable that feature. I don’t really understand why that is the case, unless my upgrade to bios 3.07 was part of that issue. I assume you’ve been using that feature as well.
As a double aside, I’d never heard of saltstack before, but I think this is beautiful! I find it much easier to understand then Ansible, which has a much more “Enterprisey” architecture. I think a long term goal of mine will be to move my setup bash scripts to saltstack!
No kidding. Also screen sharing due to Wayland.
You did the right thing. I’ll open an issue on Github for this and try to get it done when I have time. I can’t promise you an ETA. If you end up implementing it in your own future Salt code, submit a PR.
Secure boot enabled?
Ansible is equivalent in many ways, but any config management tool is generally better than pure bash. I encountered Salt in the enterprise years ago and it dawned on me at that time that I should just write all my machines’ config as code. The initial investment needed to get started is very small.
1 Like
Ah, hadn’t encountered that one, although general Wayland things were another point of pause. I expect zoom stuff to have a great impact to her, so I’ll be hoping that these things get smoothed out over the next 4 months.
Totally understandable, I’m just glad I had a helpful guide! This is really a wishlist item for me, so I’ll see if I can understand the mechanics of salt over the weekends. It may take a while.
Yes, that is what struck me about salt! Ansible seems extremely powerful and has a great community, but it is really tough for me to just get started. I love how your example showed how much salt can scale down to being very easy to quickly glance at and comprehend. I can see myself actually making this plunge.
It isn’t, but I had a previous install set up with secure boot, which I disabled to update to bios 3.07 (shipped with 3.06). I realized later that I installed with secure boot disabled, so maybe that is impacting things somehow? Tpms are new to me. Maybe I’ll start a new thread on this.
Possibly. I instinctively disable secure boot and never installed with it on. I know people reported having it on breaks hibernation but I don’t know the exact details.