For anybody which might be interested I explain in short (for advanced users and untested) how to start to to manually install a minimal distribution of openmamba:
- boot any Linux OS with networking
- use i.e.
curlorwgetto download the openmamba rootfs-base archive from the download page - initialize the destination storage by creating the partition table (GPT or MSDOS) and a FAT32 EFI boot partition (2-300 MBytes) and an ext4 partition
- format the partitions respectively with the
mkfs.vfatandmkfs.ext4 - mount on some mount point the O.S. partition (ext4) and bind mount the boot partition at
/boot, aso bind mount/dev,/sys,/proc,/runfrom the running O.S. - run
chrootto get an openmamba chroot shell in the O.S. partition - install the kernel (
dnf install kernel-mamba-x86_64) - install grub packages (
dnf install grub grub-efi-x86_64) - set a login password for the root user with
passwdcommand exitfrom chroot, unmount and try rebooting- you expected that probably something might not work, this can be discussed and fixed
I'm testing in a vm with bios (no efi) environment, 4gb ram 20gb storage.
1. booted using the latest openmamba livecd-light rolling mounted on a virtual sata cd device
2. download latest openmamba rootfs using firefox
3. using kde partition manager's New Partition Table I create a MBR (ms-dos) partition table with 1x linuxswap partition and 1x ext4 partition, the partition is formatted automatically but must be flagged as boot.
4. mount the ext4 partition and cd into it
1. sudo tar xpf ~/Downloads/openmamba-rootfs... .
2. sudo mount --bind /boot ./boot && \
sudo mount --bind /dev ./dev && \
sudo mount --bind /sys ./sys && \
sudo mount --bind /proc ./proc && \
sudo mount --bind /run ./run
3. sudo chroot . /bin/bash
4. dnf install kernel -y (grub is installed as a dependency of kernel)
5. passwd
6. exit
5. reboot
This procedure does not work because the bind mounts are ephemeral, I think. An os must first be installed.
At this point I'm thinking if it would make more sense to have an official script to strip down the default install once it is installed. Wouldn't it be faster to dnf remove a bunch of stuff and set the default target instead of creating and maintaining a separate installer?
This procedure does not work because the bind mounts are ephemeral, I think. An os must first be installed.
I'm completely unable to understand the meaning of these statements. I suppose they are meaningless or wrong.
At this point I'm thinking if it would make more sense to have an official script to strip down the default install once it is installed.
Such a procedure of stripping down a rootfs would more likely be a user adaptation starting from official rootfs or rootfs-light archives which you are of course free to do. If an official implementation would exist it would consist into providing something like a rootfs-server archive, which would provide a headless installation with at least ssh installed (which would justify calling it -server instead of -headless).
Wouldn't it be faster to dnf remove a bunch of stuff and set the default target instead of creating and maintaining a separate installer?
I don't know what "set the default target" means but if it means having an installer script, well this is what does not exist, although there are tons of documentation which a system administrator can use to make their own script for their usage scenarios.
I'm completely unable to understand the meaning of these statements.
The detailed procedure failed to create a bootable openmamba partition, and I think it is because the bind mounted directories are ephemeral: they do not persist after reboot. That is because the running os is a livecd environment. This is my suspicion, I am not certain about it.
I don't know what "set the default target" means
I meant setting a default systemd boot target (multi-user.target as opposed to graphical.target, which is the default)
The detailed procedure failed to create a bootable openmamba partition, and I think it is because the bind mounted directories are ephemeral: they do not persist after reboot. That is because the running os is a livecd environment. This is my suspicion, I am not certain about it.
The bind mounted directories are always ephemeral so saying that this is a cause of the problem is like saying the door won't open because you used the handle to open it, it's a non-sense.
In the live OS the system is installed by Calamares by doing the same sort of operations. The chroot environment has to access the bind mounted /dev to write boot things outside the root partition, the rest is written in the root partition you chrooted into.
I meant setting a default systemd boot target (multi-user.target as opposed to graphical.target, which is the default)
Ok, now I understand what you mean, by the way if your target provider allows a graphical installation it means that you may as well be able to install the OS with the graphical environment. My openmamba servers at the data center show a graphical console for login access to LXQt opposite to what you want, a black screen with tty mode login. This is by design. While anyone who makes things in free and open context needs to be motivated, any theoretical motivation for me would go into providing a live medium which boots with a text terminal and has a text inteface to install the OS, something that is familiar for a Debian sysadmin. Instead, booting graphically, install with Calamares, then remove the graphical target would cover a limited number of scenarios where this procedure is possible and would require to modify Calamares, i.e. become part of the upstream development or maintain patches for something which might well break across the time.
The bind mounted directories are always ephemeral so saying that this is a cause of the problem is like saying the door won't open because you used the handle to open it, it's a non-sense.
I see, so I must have done something wrong or missed something, thank you for the information, I'll try again and figure that out.
My openmamba servers at the data center show a graphical console for login access to LXQt opposite to what you want, a black screen with tty mode login. This is by design.
I am thinking of doing that. My main concern is that the openmamba livecd install I am using on my workstation comes with many packages out of the box, many I don't even know what they do or what purpose they serve. I would strip down the install to a bare minimum to reduce any possible attack surface, but I remember that a year ago I caused myself trouble by removing discover, which removed x11 as its dependency. I, as a user, do not know what can safely be removed.
Anyway if you run your servers like that I can do that too, and I will. 👍
any theoretical motivation for me would go into providing a live medium which boots with a text terminal and has a text inteface to install the OS, something that is familiar for a Debian sysadmin.
Instead, booting graphically, install with Calamares, then remove the graphical target would cover a limited number of scenarios where this procedure is possible and would require to modify Calamares, i.e. become part of the upstream development or maintain patches for something which might well break across the time.
I understand your thought process now.
I just want to mention that I believe endeavouros fork of Calamares has a desktop selection that includes *no desktop*, forking theirs would be easier than writing a Calamares solution from scratch.
