Linux OS - info, how-to, pitanja, novosti, savjeti, problemi...

[radi.neradi]

ima jos jedan post prije.

mozes pokusat i slozit svoj initramfs/ramdisk kako bi dosao do samog izvora problema proceduralno. tekst sam pisao za vrijeme boravka na crux distri jer sam htio nauciti vise o boot procesu i bootloaderu. na engleskom je kako bi ga ceo sve razumeo. ima par malih greskica tako da copy/paste bez razumjevanja nece radit. :-)

to learn more about linux booting process, ive inspected lilo bootloader and built a small initramfs. essentially initramfs is a minimal system that includes required dependencies for reading, mounting, decrypting, assembling software raid, assembling lvm and other actions needed to continue booting to real rootfs. we will now write a working initramfs for crux linux that will decrypt luks partition on HP DL380p Gen8 server using P420i hardware RAID-1. software raid will also be explained. kernel modules for hardware raid, software raid and other actions done on disks before mounting should be built as kernel modules which will be included in initramfs.

# partition layout
/dev/sda disk 10G
/dev/sda1 /boot
/dev/sda2 crypt_LUKS
/dev/mapper/crypt
/dev/mapper/crypt-root /
/dev/mapper/crypt-home /home
/dev/mapper/crypt-swap [swap]

start by creating required directory tree for initramfs.

# this is the main tree
$ DIR=initramfs/tree
$ VER=5.4.141
$ mkdir -p $DIR/{bin,chroot,dev,etc,lib,proc,run,sbin,sys}
$ mkdir $DIR/{dev/mapper,dev/vc}
$ mkdir $DIR/proc/mounts
$ mkdir $DIR/run/cryptsetup

# for software RAID (if used)
$ mkdir -p $DIR/dev/md

# kernel modules dir
# DAX - direct access for block devices - dependency for dm-mod
# dm-mod - device mapper driver
# dm-crypt - device mapper for encryption/decryption
# hpsa - HP smart array driver - or CCISS on older kernels
# hid-generic - to have a working keyboard on HP HTML5/JAVA remote console

$ mkdir -p $DIR/lib/modules/$VER/kernel/drivers/{dax,hid,md,scsi}

# software raid users
$ mkdir -p $DIR/lib/modules/$VER/kernel/drivers/dm

bin dir should include busybox, cryptsetup and lvm binaries. additionally mdadm if using software raid. either statically build these binaries or include required libraries for them, required libs can be checked with ldd. since building static binaries can take time, i have provided them for download - here.

$ cp /tmp/{busybox,cryptsetup,lvm} $DIR/bin/

chroot dir is where the main rootfs will be mounted.

dev dir will include block devices we need for successfull operation. if making initramfs on same system that will use the initramfs, you may use 'cp -a' method to preserve device major and minor ids, otherwise it is safer to use 'mknod' and change with appropriate. major number identifies driver user, minor identifies a device identification under that driver.

# using 'cp -a', for software RAID include device md0 or whichever is used
$ cp -a /dev/{console,null,random,urandom,sda2} $DIR/dev/


# or using 'mknod', 'c' stands for character device, 'b' for block device
$ mknod -m 666 $DIR/dev/null c 1 3
$ mknod -m 666 $DIR/dev/random c 1 8
$ mknod -m 666 $DIR/dev/urandom c 1 9
$ mknod -m 666 $DIR/dev/sda2 b 8 2
$ mknod -m 666 $DIR/dev/console c 5,1

# make mapper and vc dir, otherwise we will get warnings or errors
$ mkdir $DIR/{mapper,vc}
# and a symbolic link for console 0
$ ln -s ../console $DIR/dev/vc/0

etc contains configuration for software RAID (if used), it is easier to supply RAID array information in mdadm.conf than from the command line

$ cat $DIR/etc/mdadm.conf
ARRAY /dev/md/1 metadata=1.2 UUID=38e6c197:7f64ca70:13bd1d75:44e70864 name=crux:1
ARRAY /dev/md/0 metadata=1.2 UUID=f8aec6e3:fc7cf21c:e12283b5:b50b91ef name=crux:0

lib will include kernel modules mentioned earlier

$ cp /lib/modules/5.4.141/kernel/drivers/dax/dax.ko $DIR/lib/modules/5.4.141/kernel/drivers/dax/
$ cp /lib/modules/5.4.141/kernel/drivers/hid/hid-generic.ko $DIR/lib/modules/5.4.141/kernel/drivers/hid/
$ cp /lib/modules/5.4.141/kernel/drivers/md/{dm-crypt.ko,dm-mod.ko} $DIR/lib/modules/5.4.141/kernel/drivers/md/
$ cp /lib/modules/5.4.141/kernel/drivers/scsi/hpsa.ko $DIR/lib/modules/5.4.141/kernel/drivers/scsi/
# software raid users, note there are raid1.ko, raid0.ko, raid10.ko ..
$ cp /lib/modules/5.4.141/kernel/drivers/dm/{md-mod.ko,dm-crypt.ko} $DIR/lib/modules/5.4.141/kernel/drivers/dm/

proc will contain 'mounts' dir to prevent potential issues with mounting

$ mkdir $DIR/proc/mounts

run will contain 'cryptsetup' dir to avoid warnings with cryptsetup process locking

$ mkdir $DIR/run/cryptsetup

sbin will contain a symlink back to '../init'

$ ln -s ../init $DIR/sbin/init

sys an empty 'sys' directory

$ mkdir $DIR/sys

now the more interesting part, we will be creating an init file that will run required commands to setup everything for rootfs mounting and switching boot process to it

$ cat $DIR/init
--------------
#!/bin/sh
/bin/busybox echo "# mount proc"
/bin/busybox mount -t proc none /proc
/bin/busybox mount -t sysfs none /sys

echo "# load kernel modules"
/bin/busybox modprobe dax
/bin/busybox modprobe dm-mod
/bin/busybox modprobe dm-crypt
/bin/busybox modprobe hid-generic
/bin/busybox modprobe hpsa

# software RAID
#/bin/busybox modprobe md-mod
#/bin/busybox modprobe raid1

/bin/busybox echo "# waiting for devices to settle"
/bin/busybox sleep 10

# software RAID
#/bin/mdadm --assemble --scan || exec /bin/sh

/bin/busybox echo "# open luks partition"
/bin/cryptsetup luksOpen /dev/sda2 crypt || exec /bin/sh

/bin/busybox echo "# assemble logical volumes"
/bin/lvm vgchange -ay || exec /bin/sh
/bin/lvm vgscan --mknodes || exec /bin/sh

# make sure to triple check device or logical volume for mounting, vda, md0 or other
/bin/busybox echo "# mount root volume"
/bin/busybox mount -r /dev/crypt/root /chroot || exec /bin/sh

/bin/busybox echo "# umount proc"
/bin/busybox umount /sys
/bin/busybox umount /proc

/bin/busybox echo "# chroot "
exec /bin/busybox switch_root /chroot /sbin/init $(cat /proc/cmdline)
---------------

symlinks to commands can be made
$ ln -s busybox $DIR/bin/{echo,umount,switch_root,modprobe,mount,sleep}

'|| exec /bin/sh' is used to drop to shell in case something fails to manually inspect, that is why we load hid-generic to support keyboard input

if there is no hpsa.ko, initramfs will not see your disks

$ chmod +x $DIR/init

# and to generate an initramfs
$ echo "find . | cpio -H newc -o > ../initramfs.cpio" >../generate.sh
$ sh ../generate.sh

finally, writing lilo configuration

$ cat /etc/lilo.conf
-------------
lba32
install=text
boot=/dev/sda
# to prompt
#prompt
#timeout=100
# try using if software RAID doesn't boot
#raid-extra-boot=auto
# when using vda or disks using virtio driver
#disk=/dev/vda bios=0x80 max-partitions=7`
image=/boot/vmlinuz
initrd="/boot/initramfs"
label="linux"
read-only
append="quiet lvm luks enc_root=/dev/sda2 root=/dev/crypt/root"
------------

and of course write the bootloader with 'lilo'

[tomek@vz]

Autor radi.neradi

imam jedno pitanje, kakva je razlika kad imam nouveau u kernelu i kakva je poveznica imao ili nemao nouveau firmware u ramdisku?

Ovo me pitanje od tebe iskreno malo iznenadilo s obzirom na to kakve experimente radis. Jednostavan odgovor: nikakve. Ne zamaraj se time jer nemas od toga nikakvog benefita.

Objasnjenje:

Drivere kod kompajliranja Linux kernela mozes dodat kao modul ili integrirat u sam kernel. Cim vise stvari dodas u kernel rezultira vecim kernelom i vecim memory-footprintom kernela sto iskreno u 2024 nije neki zesci problem osim ak vrtis neku specijalnu masinu sa < 1GB RAM. Dok sam vrtio Slackware na Coppermine-u sa 128GB meme pokusao sam kreirat naravno sto manji kernel i sto vise toga implementirat kao modul jer se osjetilo na performansama sustava. Tad je to imalo smisla. E sad - u slucaju da si kreirao minimalisticki kernel mozda ti na novoj masini (ili istoj) treba neki od tih drivera kod boota - inace sustav ne boota. Primjerice: ako si konfigurirao EXT4 driver ako modul moras nekako reci sustavu da taj modul uvijek loada kod boota (u ovom slucaju pre-boot stage). Tu u igru dolazi initrd (sto nije isto kao i klasican ramdisk...bar ne direktno). No u konacnici - dali implementirao driver u sam kernel , ili kao modul - na kraju imas isti memory footprint na tom kernelu na tom stroju ako moras koristiti taj driver. Problemi bi nastali kad bi to htio migrirat na drugu masinu ali necemo na tako siroko.


P.S.- za ekipu - za Boga dragoga i sve kaj je sveto nemojte koristiti Lilo u 2024. Grub2 ga je s razlogom nadomjestio , Lilo je bio OK pred 20 godina kad nije bilo alternative ali tu motiku treba zakopat.

https://www.cainfortexas.com/grub-and-lilo/

[Dule]

Autor tomek@vz

P.S.- za ekipu - za Boga dragoga i sve kaj je sveto nemojte koristiti Lilo u 2024. Grub2 ga je s razlogom nadomjestio , Lilo je bio OK pred 20 godina kad nije bilo alternative ali tu motiku treba zakopat. /

*sweats in syslinux*

[tomek@vz]

Autor Dule

*sweats in syslinux*