Atlantis Installation Failure

Hi, Atlantis Installation failed on new install. Installation logs are available at:

https://termbin.com/vfqh

This was installation to 3 partitions (existing Pop OS partition on first nvme drive using first 4 primary partitions)

2 gpt formated nvme drives. Endeavor setup as follows:

nvme0n1p1 /boot/efi FAT32 (shared with Pop OS)
nvme0n1p5 / encrypted btrfs
nvme1n1p1 /home encrypted btrfs

Install seems to choke at creating an @swap subvolume? There is another swap partition that could be used at nvme0n1p3 and messages in log about ignoring foreign swap partition. Interestingly enough, same exact setup works fine in previous Garuda Linux install to same partition locations and same encrypted filesystem setup also with Calamares installer. (It does not setup an @swap and uses existing swap partition) I hope this can be fixed because I wanted to replace Garuda with Endeavor

Followup to last message, FYI. Pop OS was installed to laptop for support reasons as this is a System76 Gazelle. Also, August ISO of EndeavorOS was tried previously to same laptop with no errors. Only differences were version and not splitting out home partition. There it seemed to use existing swap partition already carved out during Pop OS install.

is pop_os using luks standard?

The root Pop OS was encrypted btrfs and luks and installed per the following instructions: https://mutschler.eu/linux/install-guides/pop-os-btrfs-21-04/

I believe it also chooses to encrypt swap with random key. The root partition shows as luks2 in gparted. I have plenty of space to carve out another 4G partition for EndeavorOS swap if necessary, but that still doesn’t answer why other Calamares installs have no issue with existing Pop OS encrypted install and swap, including earlier EndeavorOS. I tried August EndeavorOS for test, switched to Garuda, and based on bleeding eyes and bloat decided to try to go back to current EndeavorOS Atlantis, and here we are.

I’m sure I can get this working via any number of methods, like install EndeavorOS first and then PopOS. I intend to install REFInd since Pop uses systemd-boot and Atlantis uses grub even on gpt/EFI. Too bad no boot loader option, would be nice to have both under systemd-boot.

Whole reason for topic/thread is to report Calamares installer failure. No reason it should be trying to setup @swap and swap file. If there is a problem with existing swap partition, I would hope it would be caught in manual partitioning steps. Another possibility is that it doesn’t like btrfs and luks for /home on another drive and partition. I noticed when Garuda was faced with similar setup, it worked fine but did not create an @home subvolume, just mounted /home on second partition btrfs root.

ok … i am no hero on btrfs/ luks :slight_smile:

using systemd-boot myself… i dont know if two systems can make use of systemd-boot the same sysd-boot or one has to manage for that have to experiment in vm :lol

Oh they can, its just a matter of having different loader entries. The issue is when grubx64.efi or systemd-bootx64.efi try to overwrite each other as default boot loader/manager. EFI was really designed to make multiboot easy. REFInd and grub do have advantage though of allowing for more nuanced boots like listing snapshots to boot from with right configuration.

I just did another test install with the new ISO and Luks

[ricklinux@eos-kde ~]$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=C772-7B0C                            /boot/efi      vfat    umask=0077 0 2
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /              btrfs   subvol=/@,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /.snapshots    btrfs   subvol=/@snapshots,defaults,noatime,autodefrag,compress=zstd 0 0
UUID=314dd67c-2060-4f55-8afe-edeacc8d15d6 /swap          btrfs   subvol=/@swap,defaults,noatime,autodefrag,compress=zstd 0 0
/swap/swapfile                            swap           swap    defaults,noatime 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
[ricklinux@eos-kde ~]$ 

first installed pop_os! ? then … ?

There’s a known bug if you’re installing the same distro in a dual boot situation if the first was installed as btrfs. It’s a calamares bug. It sounds like that’s what you’re trying to do.

@joekamprad had a work around for it. . . If this is the same thing.

install error
    Job file "/usr/lib/calamares/modules/fstab/main.py" 
2021-12-03 - 13:49:31 [6]: [PYTHON JOB]: Found gettext "en_US" in "/usr/share/locale/en_US" 
2021-12-03 - 13:49:31 [6]:     ..  Job description from pretty_name "fstab" = "Writing fstab." 
2021-12-03 - 13:49:31 [6]: [PYTHON JOB]: "Ignoring foreign swap nvme0n1p 1ab38575-eb10-42a6-88f6-c3abadcf49a5" 
2021-12-03 - 13:49:31 [6]: Python Error:
 <class 'KeyError'> 
 'subvol' 
 File "/usr/lib/calamares/modules/fstab/main.py", line 410, in run
    return generator.run()

  File "/usr/lib/calamares/modules/fstab/main.py", line 125, in run
    self.generate_fstab()

  File "/usr/lib/calamares/modules/fstab/main.py", line 200, in generate_fstab
    dct = self.generate_fstab_line_info(partition)

  File "/usr/lib/calamares/modules/fstab/main.py", line 240, in generate_fstab_line_info
    if filesystem == "btrfs" and partition["subvol"] == "/@swap": 

Ignoring foreign swap nvme0n1p

I see that too… but technically useless to create a /home partition when using BTRFS… a sit will create a subvol for it already in addition you have both BTRFS partitions encrypted separately…what can cause an issue also… a new change on calamares is that if you create a BTRFS partition on manual partition it will also try to create subvols… and the issue could be with that new feature.
I can report this at calamares… looks a bit like it could be an issue with the new code used there.

I would try installing with only one BTRFS partition what will create subvol scheme with home …
And i am not sure if “reuse” swap is possible, could be Garuda patched that option in calamares.

1 Like

No worries, I think this thread was sufficient to report the problem. Looks like best solution for me is to clear partitions, install EndeavorOS first with Calamares, then install Pop OS on manual partitions since it uses non-Calamares installer. Then Refind to chain load respective boot loaders.

Thanks for looking into it.

i can reproduce the error here:
swapvol-btrfs-error

https://termbin.com/4ov9

And also the issue shows this swap error… it is morelikely related to an issue with using subvol scheme, I can proceed install if I do not have a separate /home BTRFS encrypted and use only one encrypted / with BTRFS

Note:
Reported this already and seems almost tracked down what is the cause.

1 Like

True, but having a separate /home on different drive with more space was desirable. Especially if EndeavorOS Atlantis is going to be my main driver. It’s not so clear cut to move encrypted btrfs home to another drive after installation either.

It should be possible to do what you wanted to create, the issue is with the subvol handling in this case, and BTRFS support in calamares is still not completed, subvol creation should be available in manual partition e.t.c.

1 Like

Having the same problem. https://termbin.com/e9zu

I had btrfs partitions for /home /boot created when I installed Ubuntu and a separate swap partition. And one empty btrfs partition for EndeavourOS. Choosed same mount points, no formatting.
All the disks, if I understand right, were not encrypted. I can read them from livecd.
And I have MBR partition table.

As I see, this bug in calamares was fixed exactly 15 hours ago with https://github.com/calamares/calamares/commit/ceb9ec4115e9038b1faa0869fe4d1e6c1034f008

So, what is possible solution for now, except using ext4? Or maybe the OS installer will be updated soon (or I can find the file and manually change it)
Upd: Found where you wrote about installing on one partition

Just a side note (feel free to ignore if you wish!) - but why not just have a DATA partition on the other drive, while leaving /home on the main setup. Usually that is the end goal of a separate /home, and it is better met with a data partition, with soft links for the ‘standard’ directories to counterparts in the data partition - ie: Music->/mnt/data/Music and will show /mnt/data/Music contents when referenced as ~/Music.

4 Likes