vanilla-os / albius Goto Github PK
View Code? Open in Web Editor NEWA Linux installer backend with support for SquashFS and OCI installations
License: GNU General Public License v3.0
A Linux installer backend with support for SquashFS and OCI installations
License: GNU General Public License v3.0
Orchid alpha 80, does not happen in 79
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)
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
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
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 download speed is slow and the installer can't use the system proxy to speed up.
We need to create a recipe command to set up zram on the system.
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.
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.
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.
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.
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?
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.
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.
The Vanilla image and most other images have all locales already pre-generated.
Use systemd-homed to create home directories, and encrypt them.
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:
printf
-like substitutiontrue
mkdir
, rm
, mv
, chmod
, ln
, etc)sed
-like)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!
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
Otherwise, it's impossible to decrypt the drive.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.