2000, this guide is exactly the setup I want to install, albeit on a different distro.
Could you please tell me, or consider posting a version of this guide somewhere else, with whatever changes would be necessary for it to work with Ubuntu 20.04.1?
Welcome Aboard!
1 Like
Sorry, haven’t seen Ubuntu from the inside for at least 5 years. 
But if you really don’t want to give Arch a try this guide by @wmutschl should be exactly what you’re looking for.
1 Like
Thanks, sorry to gatecrash with Ubuntu questions! 
I am definitely going to try Arch at some point but I am just getting prepared for a new university term and a brand new distro would be a lot to take on.
Willi’s guide is actually what has brought me here. It is perfect for what I want, the only issue is that it does not configure hibernation. I emailed Willi and he mentioned I might find useful information here. I have just completed Step 6 of his guide and I am now trying to setup hibernation with the swapfile - if possible.
I am using this for reference: Hibernating into swap file.
As far as I understand you’ve set up a working swapfile. All you need now is the hibernation part.
I don’t see this being any different in Arch than from Ubuntu. You’ll probably just need to …
- Calculate the physical offset of the swap file. The tool described in the Archwiki/my guide should also work in Ubuntu.
- Add this offset and the resume device to
/etc/default/grub
e. g.GRUB_CMDLINE_LINUX_DEFAULT="[...] resume=UUID=xxxx resume_offset=xxxxx" - Regenerate grub.cfg by running
sudo update-grub
Try hibernating. If hibernation doesn’t work at this point, you may need to
- Rebuild the initramfs
sudo update-initramfs -u -k all
Try again. If it still doesn’t work …
- Edit the file
/etc/initramfs-tools/conf.d/resumeusing the information from step 2 (RESUME=UUID=xxxx resume_offset=xxxxx), and regenerate the initramfs
sudo nano /etc/initramfs-tools/conf.d/resume
sudo update-initramfs -u -k all
Try again. If it still doesn’t work, well you’re on your own again 
1 Like
@ 2000
What I am liking about the Btrfs setup is that my multiboot doesn’t have entries in grub for each install using your setup and rEFInd. I boot from rEFind using grubx64.efi instead of the vmlinuz image. I just create a folder and copy the grubx64.efi into it. On the install that has rEFInd I add the folder name to the image in the rEFInd icons folder. If you install a normal install then it gets added to the grub in each. Your setup it doesn’t so they are all separate so you have to boot to rEFInd to go to another installed desktop. This is all EndeavourOS. Like I said before I am triple boot with one encrypted and two are not.
1 Like
2000, many thanks for putting that together for me. I actually resolved this with the help of a reddit user completing the same steps and it worked after I rebooted after updating grub. It is great to know the options for initramfs in case I need them in future.
Your setup should be a standard option across all distros. Great work.
3 Likes
Everything is working great on my laptop, I have since configured deja-dup for extra redundancy, and right now I am also complementing it by syncing my personal files, which are contained in a Cryptomator vault on Google Drive, with Insync, but if I may trouble you some more…
I prefer being prompted for my passphrase before the GRUB menu appears, it feels cleaner and more efficient, and I am guessing it is even more secure. The issue I have is that although this works perfectly on my laptop where I have given the whole disk to the setup, on my desktop I would like to account for the possibility of chain-loading VeraCrypt Windows in the future, most likely on a different drive unless I clone to a larger one.
If I setup my desktop exactly like the laptop, and later change GRUB so that it chain loads to VeraCrypt Windows, it will mean entering a passphrase once to see the GRUB menu, and again at the VeraCrypt prompt before Windows loads.
My current setup on my desktop, which I FUBAR yesterday and I am trying to recover some files from with chroot before reconfiguring (no timeshift!), is set up in this way, but it uses (or used!) the older crypt setup without the benefits your install offers. For it I used ManualFullSystemEncryption and Using VeraCrypt with a UEFI dual boot.
With what I have mentioned in mind, could you please tell me how I can change the commands and method I used for my laptop so that the passphrase prompt appears after selecting the OS, rather than before the GRUB menu appears? And do so in such a way it is still secure?
Perhaps it is enough just to use the normal Ubiquity installer with /nvme0n1 selected as the device to load the boot loader instead of ubiquity --no-bootloader, and change these commands:
parted /dev/nvme0n1
mklabel gpt
mkpart primary 1MiB 513MiB
mkpart primary 513MiB 100%
to these commands:
parted /dev/nvme0n1
mklabel gpt
mkpart primary 1MiB 513MiB
mkpart primary 513MiB 2013MiB
mkpart primary 2013MiB 100%
?
I’d advise you try booting with rEFInd. There’s a guide in the EOS-Wiki on how to install and configure.
On boot you would be greeted by rEFInd and choose either Windows, EOS or whatever you also have installed and then chainload Grub or the VeraCrypt prompt. So you wouldn’t have to enter two passwords.
Don’t be put off by the websites look. rEFInd can be themed to look pretty slick. The site has some custom themes, but there ar tons of others if you search for them (mostly on Github). Here’s an example …
2 Likes
I setup my laptop using this excellent guide to use BTRFS without encryption and it has been great, except that when I shut down the laptop it takes a long time. On the same laptop EndeavourOS installed using ext4 shuts down very quickly. Perhaps some process(es) takes a long time to quit or to be killed.
Anyone else notice this, and how can we find out why shutdown takes a long time? Any pointer will be appreciated.
I don’t find this and i have it set up on KDE, Xfce and Cinnamon. Cinnamon is encrypted install and the others are not. All are Btrfs set up via the wiki guide.
@ricklinux, thanks for your quick response!
Yes, I did use the quick cut-n-paste version of the wiki, just changed the partition information and skipped swap setting.
When you did the unecrypted install did you change the install from the quick copy & paste as shown here?
Yes, I neglected to mention that I also applied the changes suggested by 2000 in that thread when I installed EndeavourOS.
What I did was 1) copy the command in the cut-n-paste version to a text file, 2) apply the changes per 2000’s post in that thread and remove swap related commands , 3) run the commands in the text file to setup the system.
Just checking. So there must be some other process going on that is hanging up the shutdown process. You’ll have to start looking at some logs and things to try and figure it out. Mine shuts down instantaneously pretty much.
Did you by chance run the commands listed under #07 (#07 – OPTIONAL – Limit the amount of maximum snapshots)?
In this case
- all excess snapshots over your specified amount are removed (deleted), and
- one
grub-mkconfig, which usually only takes a couple of seconds, is
run on shutdown.
.
Now, the above setup could stall your shutdown if
- you have a lot of snapshots that need to be deleted on shutdown, and/or
- something like
os-proberprolongs thegrub-mkconfig, e. g. in case of a multiboot situation.
Both cases should be fairly unusual but of course could occur … 
.
Do you have a multiboot situation?
.
If you didn’t install with option #07, then the problem probably doesn’t have anything to do with this specific setup. 
You could check the logs and maybe report back?
To check the logs you could run a shutdown and then limit the output to the time you initiated it up to the next reboot:
journalctl --since "2020-10-28 18:02:00 --until "2020-10-28 18:05:30"
-or-
journalctl --since "15 min ago"
[Edit] If you set up with #07, there’s a quick way to test if this causes your slow shutdown.
Disable the service that runs on shutdown:
sudo systemctl stop limit-timeshift-snapshots-update-grub.service
sudo systemctl disable limit-timeshift-snapshots-update-grub.service
If this helps I’d advise to leave the service disabled .
2 Likes
@2000
You are the wizard!
I use ReFind and setup multiboot. I did setup with #07 to limit the number of snapshots, so I try the last suggestion in your post and disable the service to update grub, and bingo! my system shuts down quickly. I will keep that service disabled.
Thanks so much for your help.
2 Likes
You may now have the problem that due to the lack of running grub-mkconfig your grub menu doesn’t show all of your snapshots in the boot menu.
If you don’t need to boot into snapshots anyway, this shouldn’t be a problem and you could just leave the system as it is now.
But if you want to have the ability to boot into snapshots there may be a different solution to your shutdown problem …
Because you choose the boot partition with rEFInd anyway, you don’t need to probe for other systems and have these added to the grub menu. You could simply
-
try to stop os-prober from probing other drives when running grub-mkconfig by adding
GRUB_DISABLE_OS_PROBER=true
to/etc/default/grub -
update grub
sudo grub-mkconfig -o /boot/grub/grub.cfg -
and then re-enable the service that removes snapshots and updates grub on shutdown
sudo systemctl enable --now limit-timeshift-snapshots-update-grub.service
[Edit] If you want to check how much a grub-mkconfig would slow down your shutdown just run the following and check the “real …” output:
sudo sh -c 'time grub-mkconfig -o /boot/grub/grub.cfg'
For me this adds about 10 seconds to the shutdown process; I can live with that .
1 Like
That sounds to me like the best bet - after all, rEFInd can boot the grub too, when appropriate (like needing into a snapshot).
1 Like