![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
muwlgrIn my previous article at muwlgr.dreamwidth.org/54748.html I moved most my in-line scripts to GitHub
to save your efforts on properly copying and pasting them into your terminal window.
Now probably it is worth to briefly explan what is happening inside them.
The script at github.com/muwlgr/scripts/blob/main/debootstrap/populate.sh which you dot-include into your current session
creates initial folder structure, removes leftover Linux kernel files from previous installs,
and fetches a copy of github.com/muwlgr/scripts/blob/main/debootstrap/mount-linux.sh
which could be used for mounting the debootstrapped system and accessing it from the host.
Then it allocates loop image files of given size and creates ext4 fs and swap space within them.
Then it mounts the root fs image and runs debootstrap on it to populate the initial system.
Before running debootstrap it copies eatmydata bins and libs if they are present on the host,
to speed up file operations which is especially useful on slow USB flash drives.
After running debootstrap the user is asked to change the host name of the bootstrapped system,
to be different from the one of the creating host.
Then some more folders are mounted into the target fs (boot , boot/efi if needed, and host),
apt proxy configuration is copied from host into target if present,
and scripts github.com/muwlgr/scripts/blob/main/debootstrap/runme.sh
and github.com/muwlgr/scripts/blob/main/debootstrap/complete-stable.sh
are copied into the root folder of the target.
runme.sh script is used to bind-mount system folder such as /dev , /proc , /sys and others
from the host into the target and run root session in the target using chroot
Then the user is asked to continue system setup by dot-including complete-stable.sh into this root session.
complete-stable.sh is doing the bulk of setup work which requires root permissions and is more convenient to be done from within the debootstrapped target, than from the non-root session on the host.
First, it converts apt sources.list into stable.sources corresponding to Debian Stable instance freshly installed in standard Debian way,
and runs apt update using network interface provided by the host.
Then it installs some essential packages like locales , tzdata and console-setup and asks the user to configure them.
Then it prepares the environment and configuration for grub installation
and adds needed entries to fstab.
And then it installs grub :
first, grub-pc is installed to get bootability on BIOS/CSM systems,
then, if needed, it is replaced replaced with grub-efi-amd64 to get bootability on UEFI/SecureBoot systems
(without losing BIOS/CSM bootability left over after grub-pc installation).
Then comes the turn of initramfs-tools config fixes:
do_symlinks in kernel-img.conf is disabled, vfat modules added to the explicit modules list,
and two drop-in scripts are copied from github.com/muwlgr/scripts/blob/main/initramfs/hostloop-premount
and github.com/muwlgr/scripts/blob/main/initramfs/hostloop-bottom into local-premount/ and local-bottom/ folders
to implement loop= option handling in the cmdline of the booted kernel
in the same way as it is done in Ubuntu fork of initramfs-tools.
Then finally it becomes possible to install linux-image-amd64
so that it gets configured perfectly with the above fixes for grub and initramfs-tools.
Then complete-stable is doing some package cleanup,
and creating the simplest initial configuration for systemd-networkd.
Then, within the same chroot root session, the user is asked to create the first non-root user and add it to the sudo group.
Typical Debian installation asks the user to set root password, then create a non-root user, and does not install sudo at all.
The approach with sudo package and sudo group I borrowed from Ubuntu as I liked it more : root password is locked, root operations are done only by a non-root user with sudo.
You may look into Ubuntu's initramfs handling of loop= option
at git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/initramfs-tools/tree/init?h=ubuntu/noble
and git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/initramfs-tools/tree/scripts/local?h=ubuntu/noble
Compare it to Debian's original version
at salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.148.3/init
and salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.148.3/scripts/local
to understand what functionality I have added by hostloop-premount and hostloop-bottom scripts .
You may also look into salsa.debian.org/grub-team/grub/-/blob/master/util/grub-mkconfig.in
and salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/default-grub-d.patch
(or may be just look into your local copy of /usr/sbin/grub-mkconfig)
to understand the meaning of grub fixes in complete-stable.
Start with the line GRUB_DEVICE= and go up to the end of loop including files from ${sysconfdir}/default/grub.d/
to understand why /etc/default/grub.d/hostloop.cfg should be created with its content.
And also you may want to see my comment to bugs.debian.org/700633 to understand eatmydata performance optimization for debootstrap.
to save your efforts on properly copying and pasting them into your terminal window.
Now probably it is worth to briefly explan what is happening inside them.
The script at github.com/muwlgr/scripts/blob/main/debootstrap/populate.sh which you dot-include into your current session
creates initial folder structure, removes leftover Linux kernel files from previous installs,
and fetches a copy of github.com/muwlgr/scripts/blob/main/debootstrap/mount-linux.sh
which could be used for mounting the debootstrapped system and accessing it from the host.
Then it allocates loop image files of given size and creates ext4 fs and swap space within them.
Then it mounts the root fs image and runs debootstrap on it to populate the initial system.
Before running debootstrap it copies eatmydata bins and libs if they are present on the host,
to speed up file operations which is especially useful on slow USB flash drives.
After running debootstrap the user is asked to change the host name of the bootstrapped system,
to be different from the one of the creating host.
Then some more folders are mounted into the target fs (boot , boot/efi if needed, and host),
apt proxy configuration is copied from host into target if present,
and scripts github.com/muwlgr/scripts/blob/main/debootstrap/runme.sh
and github.com/muwlgr/scripts/blob/main/debootstrap/complete-stable.sh
are copied into the root folder of the target.
runme.sh script is used to bind-mount system folder such as /dev , /proc , /sys and others
from the host into the target and run root session in the target using chroot
Then the user is asked to continue system setup by dot-including complete-stable.sh into this root session.
complete-stable.sh is doing the bulk of setup work which requires root permissions and is more convenient to be done from within the debootstrapped target, than from the non-root session on the host.
First, it converts apt sources.list into stable.sources corresponding to Debian Stable instance freshly installed in standard Debian way,
and runs apt update using network interface provided by the host.
Then it installs some essential packages like locales , tzdata and console-setup and asks the user to configure them.
Then it prepares the environment and configuration for grub installation
and adds needed entries to fstab.
And then it installs grub :
first, grub-pc is installed to get bootability on BIOS/CSM systems,
then, if needed, it is replaced replaced with grub-efi-amd64 to get bootability on UEFI/SecureBoot systems
(without losing BIOS/CSM bootability left over after grub-pc installation).
Then comes the turn of initramfs-tools config fixes:
do_symlinks in kernel-img.conf is disabled, vfat modules added to the explicit modules list,
and two drop-in scripts are copied from github.com/muwlgr/scripts/blob/main/initramfs/hostloop-premount
and github.com/muwlgr/scripts/blob/main/initramfs/hostloop-bottom into local-premount/ and local-bottom/ folders
to implement loop= option handling in the cmdline of the booted kernel
in the same way as it is done in Ubuntu fork of initramfs-tools.
Then finally it becomes possible to install linux-image-amd64
so that it gets configured perfectly with the above fixes for grub and initramfs-tools.
Then complete-stable is doing some package cleanup,
and creating the simplest initial configuration for systemd-networkd.
Then, within the same chroot root session, the user is asked to create the first non-root user and add it to the sudo group.
Typical Debian installation asks the user to set root password, then create a non-root user, and does not install sudo at all.
The approach with sudo package and sudo group I borrowed from Ubuntu as I liked it more : root password is locked, root operations are done only by a non-root user with sudo.
You may look into Ubuntu's initramfs handling of loop= option
at git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/initramfs-tools/tree/init?h=ubuntu/noble
and git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/initramfs-tools/tree/scripts/local?h=ubuntu/noble
Compare it to Debian's original version
at salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.148.3/init
and salsa.debian.org/kernel-team/initramfs-tools/-/blob/v0.148.3/scripts/local
to understand what functionality I have added by hostloop-premount and hostloop-bottom scripts .
You may also look into salsa.debian.org/grub-team/grub/-/blob/master/util/grub-mkconfig.in
and salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/default-grub-d.patch
(or may be just look into your local copy of /usr/sbin/grub-mkconfig)
to understand the meaning of grub fixes in complete-stable.
Start with the line GRUB_DEVICE= and go up to the end of loop including files from ${sysconfdir}/default/grub.d/
to understand why /etc/default/grub.d/hostloop.cfg should be created with its content.
And also you may want to see my comment to bugs.debian.org/700633 to understand eatmydata performance optimization for debootstrap.
