I think @dalto one day told how to do but I forgot because it was so unintuitive form me.
Let’s say I have a Linux installed with systemd-boot and btfs subvolumes.
Now I want to additionally install EndeavourOS on this disc. What I can do is change btrfs subvolume names in /etc/calamares/modules/mount.conf
.
However, when installing and choosing Manual partioning
I have no chance to add the btrfs subvolumes with their designated mount points.
Any help appreciated.
dalto
February 26, 2025, 7:16pm
2
Those subvolumes are applied to whatever btrfs partition you mount at /
.
I know that isn’t particularly intuitive but that is how it works.
dalto
February 26, 2025, 7:17pm
3
As a side note, I have never tried installing into an existing btrfs volume. I would try that in a VM first to make sure it doesn’t do anything unexpected.
This I tried but got a error. I will try again and carefully check. Probably I made a stupid mistake.
Yes, I am currently trying this in a VM because I am a cautious person.
1 Like
To make sure I understand correctly.
Before running the installer
I create the subvols
I specify those subvols in /etc/calamares/modules/mount.conf
Do I also have to mount things before running the installer??? (This is what I hadn’t done)
dalto
February 26, 2025, 7:37pm
7
manfredlotz:
I create the subvols
This will cause it to fail. The installer creates the subvols.
It creates the subvols specified in mount.conf
Ok, without creating the subvols it doesn’t work either. No matter if I previously run cryptsetup open /dev/vda eos
or not.
dalto
February 26, 2025, 8:19pm
9
I am not sure if it is possible to install into an existing encrypted volume.
Hm, that would be a pity. Perhaps I should ask the calamares people at https://github.com/calamares/calamares/issues
In general, shouldn’t it be possible to have more than one system which
resides in the same btrfs fs (having different subvolumes)
and sharing the /efi partition
?
dalto
February 26, 2025, 8:34pm
12
It is possible. I made a post about how I did this a few years ago.
However, that doesn’t mean the installer itself supports it. There was a very recent change to Calamares to allow it to not unmount/close devices before starting the installer. However, that isn’t in EOS yet.
How could one find this post here?
dalto:
However, that doesn’t mean the installer itself supports it. There was a very recent change to Calamares to allow it to not unmount/close devices before starting the installer. However, that isn’t in EOS yet.
So, this means it will be possible when the Calamares changes are in EOS?
dalto
February 26, 2025, 8:43pm
14
I linked it. Just click on the word “post” above.
Perhaps, it would need testing.
Thanks, I hadn’t seen that post
was a bit bluish
1 Like
dalto
February 26, 2025, 8:48pm
16
I don’t know if I actually mentioned how I did it but essentially I installed each distro after the first into a VM and then used btrfs send/receive to send the subvols to real install. Then I chrooted in and rebuilt the initrams.
Thanks for this.
This is the information I was searching for in the post you linked…
There is a hack you can do to get around Calamares closing the LUKS device.
opened 05:35PM - 02 Nov 20 UTC
closed 02:42PM - 02 Nov 21 UTC
Distribution lubuntu 20.04, but, as far as I can tell, this is a Calamares issue… .
Calamares 3.2.20.
Before running Calamares, I have a luks-encrypted lvm partition opened
```
lsblk
...
└─sda5 8:5 0 186G 0 part
└─cryptvol 253:0 0 186G 0 crypt
├─cryptvg-swap 253:1 0 16G 0 lvm
└─cryptvg-linux 253:2 0 160G 0 lvm
```
I start Calamares, select manual partitioning, tell it that the root partition is to go /dev/cryptvg/linux (btrfs), get to the end of the procedure, it asks for confirmation to "Install Lubuntu on btrfs system partition /dev/cryptvg/linux", I say, Yes, please.
It crashes, complaining as follows:
```
Command '['btrfs', 'subvolume', 'create', '/tmp/calamares-root-2_q1ieog/@']' returned non-zero exit status 1.
None
Traceback:
File "/usr/lib/x86_64-linux-gnu/calamares/modules/mount/main.py", line 166, in run
mount_partition(root_mount_point, partition, partitions)
File "/usr/lib/x86_64-linux-gnu/calamares/modules/mount/main.py", line 94, in mount_partition
subprocess.check_call(['btrfs', 'subvolume', 'create',
File "/usr/lib/python3.8/subprocess.py", line 364, in check_call
raise CalledProcessError(retcode, cmd)
```
From the log, it is "successfully" sabotaging itself by closing the device before it tries to write to it:
```
ClearTempMountsJob finished. Here's what was done:
""
08:50:48 [8]: [JOBQUEUE]: Progress for Job[ 1 ]: 0 % completed
08:50:48 [8]: [JOBQUEUE]: Progress Overall: 2.32558 % (accumulated) + 0 % (this job) = 2.32558 % (total)
08:50:48 [6]: virtual void Calamares::JobThread::run()
Starting job "Clear mounts for partitioning operations on /dev/sda" (there are 32 left)
08:50:48 [6]: QStringList getPartitionsForDevice(const QString&)
Reading from "/proc/partitions"
08:50:49 [6]: virtual Calamares::JobResult ClearMountsJob::exec()
ClearMountsJob finished. Here's what was done:
"Successfully closed mapper device /dev/mapper/cryptvg-linux.\nSuccessfully closed mapper device /dev/mapper/cryptvg-swap.\nSuccessfully closed mapper device /dev/mapper/cryptvol."
```
For me, this installer is broken. Is there any workaround, or must I get another distribution which does not use the Calamares installer?
Essentially, just use “live-
” in front of the mapping name when you open the device. For example:
sudo cryptsetup open /dev/[btrfs_partition] live-root
Then proceed with the Calamares installation.
1 Like
Thanks a lot @BluishHumility . Just tested. This workaround works great.
2 Likes