vanilla-os / albius Goto Github PK

View Code? Open in Web Editor NEW

18.0 18.0 8.0 18.62 MB

A Linux installer backend with support for SquashFS and OCI installations

License: GNU General Public License v3.0

Go 97.91% Python 0.84% Shell 1.10% Makefile 0.15%

installer linux oci squashfs

albius's People

Contributors

Stargazers

Watchers

Forkers

rudraswat kbdharun gabsedits msgpo taukakao lingmoos jardon muhdsalm

albius's Issues

[Bug] interface conversion: interface {} is nil, not string

Version 80 Not bootable after install

Version

Orchid alpha 80, does not happen in 79

Bug

After using the installer, booting into Vanilla only drops you in a grub shell.

This happens on some real hardware as well as in a Boxes VM.

(After installing there are no boot devices apart from one called "grub", which boots into the screen shown above)

Replicate

Open Boxes
Use latest iso
Set OS to Debian or Fedora Silverblue (though I don't think it really makes a difference)
Set Firmware to UEFI
Ram 10G, Storage 60G
Create
Select en_us as language, us keyboard layout (or de), Timezone Berlin
No full disk encryption
Install (No errors in install log except a locale warning from perl)
Reboot

[feat] Allow passing extra flags to `grub-install`

Albius should be able to parse extra key-value pairs to be used as arguments when invoking grub-install (and perhaps also grub-mkconfig). This will allow us, for example, to set the bootloader id from the installer frontend.

Related issue: Vanilla-OS/vanilla-installer#217

Panic: Timed out waiting for partition

Setup [1/20]: label
Setup [2/20]: mkpart
Discarding device blocks: done                            
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: bbeacfd4-ce77-46e1-842d-b65dcc32a605
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Setup [3/20]: mkpart
mkfs.fat 4.2 (2021-01-31)
Setup [4/20]: mkpart
Setup [5/20]: mkpart
Setup [6/20]: pvcreate
Setup [7/20]: pvcreate
Setup [8/20]: vgcreate
Setup [9/20]: vgcreate
Setup [10/20]: lvcreate
Setup [11/20]: lvm-format
Discarding device blocks: done                            
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: 5e1574f5-a718-422a-ad97-b0726e8d60c7
Superblock backups stored on blocks: 
	32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Setup [12/20]: lvcreate
Setup [13/20]: lvcreate
Setup [14/20]: make-thin-pool
Setup [15/20]: lvcreate-thin
Setup [16/20]: lvcreate-thin
Setup [17/20]: lvm-format
btrfs-progs v6.6.3
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/vos-root/root-a (19.00GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               e01b4387-8aca-49c8-ac09-914bfeae0b87
Node size:          16384
Sector size:        4096
Filesystem size:    19.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes, free-space-tree
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH                
    1    19.00GiB  /dev/vos-root/root-a

Setup [18/20]: lvm-format
btrfs-progs v6.6.3
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/vos-root/root-b (19.00GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               0e5787c9-7a2e-4bdc-8146-3170d98d541c
Node size:          16384
Sector size:        4096
Filesystem size:    19.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes, free-space-tree
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH                
    1    19.00GiB  /dev/vos-root/root-b

Setup [19/20]: lvcreate
Setup [20/20]: lvm-luks-format
panic: Timed out waiting for partition /dev/vos-var/var

goroutine 1 [running]:
github.com/vanilla-os/albius/core/disk.(*Partition).WaitUntilAvailable(0xc0002200e0)
	github.com/vanilla-os/albius/core/disk/partition.go:343 +0xfc
github.com/vanilla-os/albius/core.runSetupOperation({0xc00041ac28?, 0xc000058038?}, {0xc00041ac40, 0xf}, {0xc00042d180, 0x4, 0x3?})
	github.com/vanilla-os/albius/core/recipe.go:598 +0x1b48
github.com/vanilla-os/albius/core.(*Recipe).RunSetup(0xc0000ab5e0)
	github.com/vanilla-os/albius/core/recipe.go:629 +0x195
main.main()
	github.com/vanilla-os/albius/albius.go:20 +0x96

Trying to install in a 30GB VM with encryption enabled and automatic partitions.

VanillaOS-2-testing.20240208

The vanilla os installer can't use system proxy

The download speed is slow and the installer can't use the system proxy to speed up.

[feat] Create/manage zram

We need to create a recipe command to set up zram on the system.

sh: 1: mkfs.: not found when installing over a previously encrypted partition

I was installing VanillaOS with an encrypted home partition and all was well until I ran into the issue described in #77. I rebooted to try again, this time without swap. I remembered that I have a SED, so I don't need an encrypted home partition, and I continued the installation without choosing encryption. I was using manual disk setup to install alongside Windows, too, but I'm not sure it matters.

I used all the same partitions that were setup previously. I got an error very shortly into installation during the setup stage that went something like sh: 1: mkfs.: not found. I was tearing my hair out for a while until I figured to just create the ext4 filesystem myself in the terminal. It turns out that the crypt format was still there and mkfs.ext4 asked for confirmation to replace the crypt format with ext4. I obliged and restarted the installation, and the setup proceeded normally. I suppose you might want to investigate /core/recipe.go line 270.

Anyway, this seems like it's certainly a bug. The error message is very strange and is consistent with what you would see if you just run mkfs. in bourne shell... I'm not really sure what's up with that. This also seems both relatively low priority (I can't imagine a lot of people are going to be in this situation) and relatively easy to patch.

partitioning errors inside VMs

Latest Installer as of July 5th 2024 results in frequent install failures. I have now verified this across multiple hypervisor platforms on multiple hosts including multiple host OSes.

these failures seem to run down to two errors with what is likely a shared cause.

Install on a blank disk starts as such

but quickly devolves to one of the following errors depending how the machine is feeling (or other times works completely fine with seemingly no difference.)

While I wanted to create an issue for this, I cannot give much more detail as the logs are rather unhelpful and I know very little of what the script is doing. If there are any further debugging steps I can take, I am glad to help.

mkpart issue

Trying to Install Vanilla OS (Orchid #117) on a fresh new VM (VirtualBox) after deleting previous VM because of previous failure I get this error :

mkpart
panic: failed to make ext4 filesystem for /dev/sda1: mkefs 1.47.0
The file /dev/sda1 doesn not exist and no size was specified.

Albius can't delete LVM partitions, me either

When i was testing vanilla in vm, albius made 2 lvm partitions, but after the installation failed(the bootloader didn't install properly) albius couldn't delete the partitions after selecting the previously used virtual disk, so the installer failed, i tried to delete the lvm partitions in gparted and i needed to use a nixos disk to delete them because the volumes were active.

too short timeout

Often when trying to install Vanilla OS when connected to a slow internet bandwith (not everybody is yet connected at finer speed), installation fails because of connection timed out.
So not only installation is slow because of slow internet connection but we have start over and over again and again hoping we get more lucky with bandwidth the next time...

Could you increase the timeout please?

Stuck on lvm-luks-format when installing with encryption

Setup [1/20]: label
Setup [2/20]: mkpart
Discarding device blocks: done                            
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 133ef921-83bf-4d79-9d08-ecba6148016e
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Setup [3/20]: mkpart
mkfs.fat 4.2 (2021-01-31)
Setup [4/20]: mkpart
Setup [5/20]: mkpart
Setup [6/20]: pvcreate
Setup [7/20]: pvcreate
Setup [8/20]: vgcreate
Setup [9/20]: vgcreate
Setup [10/20]: lvcreate
Setup [11/20]: lvm-format
Discarding device blocks: done                            
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: cf1c86d6-6178-4bb4-a03c-edb9b613a100
Superblock backups stored on blocks: 
	32768, 98304

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Setup [12/20]: lvcreate
Setup [13/20]: lvcreate
Setup [14/20]: make-thin-pool
Setup [15/20]: lvcreate-thin
Setup [16/20]: lvcreate-thin
Setup [17/20]: lvm-format
btrfs-progs v6.6.3
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/vos-root/root-a (19.00GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               093bf450-c884-4cca-8d1a-30ec9ad5d078
Node size:          16384
Sector size:        4096
Filesystem size:    19.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes, free-space-tree
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH                
    1    19.00GiB  /dev/vos-root/root-a

Setup [18/20]: lvm-format
btrfs-progs v6.6.3
See https://btrfs.readthedocs.io for more information.

Performing full device TRIM /dev/vos-root/root-b (19.00GiB) ...
NOTE: several default settings have changed in version 5.15, please make sure
      this does not affect your deployments:
      - DUP for metadata (-m dup)
      - enabled no-holes (-O no-holes)
      - enabled free-space-tree (-R free-space-tree)

Label:              (null)
UUID:               d8012d3f-ca00-47a3-9208-1f806c594882
Node size:          16384
Sector size:        4096
Filesystem size:    19.00GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP             256.00MiB
  System:           DUP               8.00MiB
SSD detected:       no
Zoned device:       no
Incompat features:  extref, skinny-metadata, no-holes, free-space-tree
Runtime features:   free-space-tree
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH                
    1    19.00GiB  /dev/vos-root/root-b

Setup [19/20]: lvcreate
Setup [20/20]: lvm-luks-format

Installing VanillaOS-2-testing.20240306 (118) with encryption, VM tools and automatic partitions on a 30GB VM. The installation never finishes. I waited for almost 3 hours.

Installer trying to access an unprovided partition

I asked the installer to install with the partitions 6/7/8/9, yet it's trying to access p5 which was on lvm2 (photo says it's fat32).
I followed this blog post when partitioning the disk.

Check if VG or LV already exists before creating

remove generation of locale

The Vanilla image and most other images have all locales already pre-generated.

[feat] Support systemd-homed for user home directories

Use systemd-homed to create home directories, and encrypt them.

[feat] New recipe commands

Now that the installation process for Vanilla OS is (somewhat) finalized, it's a good idea to create/improve some recipe commands in Albius to replace the more complex shell items from vanilla-installer. Below is a list of some of the commands we should consider working on:

Mount/Unmount commands for post-install (needs to support overlay and bind mounts)
#13
Copy file from host to installed system, with support for printf-like substitution
Make chroot parameter in post-install optional, and default it to true
Basic filesystem operations (mkdir, rm, mv, chmod, ln, etc)
File editing (sed-like)

installing with swap partition failed at swapon

Encryption causes Albius to fail during setup

Title says it all, with Encryption enabled my install would fail, It may have failed at more steps than just step 20 at times, (step 7?) but I was testing multiple different things, Step 20 was the most consistant, & I have a screenshot of it.

System Info

[Orchid] LVM error 'insufficient free space'

I tried to install on an external 1TB SSD, and kept getting a Volume group error when selecting to install on the entire drive:

Volume group "vos-root" has insufficient free space (253 extents): 256 required.

sometimes it says 252 extents instead of 253, but it's always the same result.
When I assign the partitions myself in the installer, I also get the same result.

The drive I'm using is an M.2 NVME SK Hynix 1024.2GB drive in a Sabrent USB-C enclosure.
I tried to install from different hardware (onto the same drive) and also get the same issue. However, a different 240GB drive worked fine.
Testing other distributions worked fine too, so I don't think it's an issue with the drive...

Let me know if I can provide more info!

Improve Support for traditional single root systems and add an option for specifying where the chroot is mounted too

Currently albius seems to have a hard-coded

RootA
RootB

System in the recipes

And they get mount to /mnt/a and /mnt/b

We should be able to change both these things

Can not use special characters in LUKS password

Otherwise, it's impossible to decrypt the drive.