| View previous topic :: View next topic |
| Author |
Message |
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
 Posted: Tue Jun 09, 2020 7:47 pm Post subject: |
 |
|
Zu der Frage aus dem Edit. Genkernel baut statische Versionen von cryptsetup, lvm, btrfs, usw. (wenn ich das richtig verstehe) mit jeder neuen Version. Solange die Version sich nicht anhebt bleiben die. Weiss grade nicht wo, aber das wird irgendwo angelegt einmal.
Man bemerkt es, weil das Versionsupdate von genkernel dazu führt, das der darauf folgende Bau der Initramfs dann deutlich mehr Zeit in Anspruch nimmt. Danach geht es sehr schnell bei mir, bis zum nächsten Versionsupdate.
Wenn du willst das es immer gemacht wird musst du schauen wo die statischen Versionen quasi gecached werden und das weg löschen. Das sollte reichen vermutlich.
Zur Frage ob das gepackt vorliegen muss. Gegenfrage - wie sagst du grub das? Das Wurzelverzeichnis da anzugeben würde reichen. Kannste ja mal testen was dann passiert. Soll heissen - ich hab keine Ahnung ob das geht ... *grins*
Und ja ext2 sollte der Kernel können. |
|
| Back to top |
|
 |
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Tue Jun 09, 2020 8:00 pm Post subject: |
|
|
Ach grub macht das. Ich hatte irgendwo gelesen oder so verstanden das der Kernel das liest entpackt und dann das init Script startet. Ich guck mal was die über den grub sagen vielleicht finde ich was.
Was mir aber mehr sorgen macht wenn ich ein fertiges initramfs von genkernel auspacke und ohne Änderung wieder einpacke kann ich nicht mehr booten.
So habe ich das gemacht (im Verzeichniss wo ich das ausgepackt habe):
| Code: |
find . | cpio --verbose --create --format=newc > ../initramfs-5.4.28-gentoo-x86_64.img
|
Dann mit xz wieder komprimierte.
Fehlermeldung: unable to mount root fs on unknown-block (0,0)
Weisst Du vielleicht was ich da beim einpacken falsch mache?
<Edit>
Grub habe ich mit grub-mkconfig aktuallisiert.
</Edit> |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Wed Jun 10, 2020 12:27 am Post subject: |
|
|
Also kann sein das ich da irgendwo was verschlampt habe. Ist schon spät. Bei mir macht das genkernel wie folgt. Also habe da in das Skript geschaut.
Damit legste das das img an:
| Code: |
find . -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-5.6.17-gentoo-luthien.img
|
Jetzt noch mit xz packen:
| Code: |
xz -e --check=none -z -f -9 initramfs-5.6.17-gentoo-luthien.img
|
Dann Umbennen um das .xz loszuwerden
| Code: |
mv initramfs-5.6.17-gentoo-luthien.img.xz initramfs-5.6.17-gentoo-luthien.img
|
|
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Wed Jun 10, 2020 8:35 am Post subject: |
|
|
Ich hatte das von der Kernel Doku und mich schon gewundert das die Kernel Doku falsch ist. Das kommt eher nicht vor.
https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
Ist sie auch dieses mal nicht den Unterschied macht die Komprimierung und nicht das einpacken in das cpio Archiv. In der Kernel Doku verwenden die eine andere Komprimierung.
Das cpio Archiv im gleichen Verzeichnis anzulegen wie die Daten sind ergibt bei mir eine Fehlermeldung. Das kann man aber leicht vermeiden wenn man bei der -F Option eine Verzeichnis mit angibt.
Vermutlich ist das so weil er dann versucht das cpio Archiv mit einzupacken das sich aber laufend verändert.
Danke für die Info das hat sehr geholfen. Irgendwie bin ich nicht auf die Idee gekommen bei der Komprimierung zu suchen.
Jetzt kann ich wieder weiter machen und die Änderungen testen ...
<Edit>
Falls es jemanden interessiert: bei der Komprimierung ist die entscheidende Option --check=none die schaltet die Integritätsprüfung bei der Komprimierung aus.
Ich dachte immer Integritätsprüfungen sind eine gute Sache. Die man Page sieht es ähnlich.
</Edit> |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Sat Jun 13, 2020 8:40 am Post subject: |
|
|
Irgendwie geht das nicht wie es soll. Aber die Shell-Magie ist mir auch nicht so richtig bekannt. Sobald man den LUKS_NAME ändert erhält man die Fehlermeldung:
| Code: |
Faild to open Luks device /dev/sda4
could not find the in /devsda4
|
Eingebaut habe ich das in openLUKS so:
| Code: |
fi
# At this point, keyfile or not, we're ready!
#####
# Ändere den Mapping Namen auf das PartLabel
Trennzeichen= expr index "$CRYPT_ROOT" '='`
ErsterTeil=${CRYPT_ROOT:$Trennzeichen}
Trennzeichen= expr index "$ErsterTeil" '='`
ZweiterTeil=${ErsterTeil:$Trennzeichen}
LUKS_NAME=$ZweiterTeil
good_msg "$LUKS_NAME"
#
#####
crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"
crypt_filter_ret=$?
|
Nach dem Passwort für die Verschlüsselung wird nicht mehr gefragt. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sat Jun 13, 2020 9:55 am Post subject: |
|
|
Also rein aus der Ausgabe schaut es so aus als ob LUKS_NAME nichts enthält.
Aus dem was ich grade an den Kommandos testen wollte ist da auch ein Fehler drin.
Du musst
| Code: |
Trennzeichen=`expr index "$CRYPT_ROOT" '='`
|
setzen.
Das erste ` Zeichen ist bei dir stattdessen ein Blank.
Dito bei der zweiten Zuweisung an Trennzeichen. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Sat Jun 13, 2020 1:50 pm Post subject: |
|
|
Ah ja, da fehlt was ... habe ich doch gut gemacht beim Beispiel Script richtig und dann falsch ... 
Das ist auf meinem Bildschirm weniger als ein Staubkorn kaum zu sehen. Sorry habe ich übersehen.
Ich konnte das nicht kopieren weil ich aus irgendeinem Grund kopieren und einfügen in das Qemu Fenster niccht funktioniert. Ich habe was gelesen das man auf dem Gast Betriebssystem irgendwas installieren muss damit das geht.
Nach einfügen des fehlenden Zeichens bootet es wie es sein soll.
<Edit>
Sehe ich das richtig das man ein Verschlüsseltest SWAP nicht automatisch einfach mit dem gleichen Passwort entschlüsseln kann. Ich weiß jetzt nicht warum man verschiedene benutzen sollte. Ein Angreifer wird versuchen das RootFs Passwort zu raten. Ich würde das zumindest so machen. Wenn man dann Zugriff auch das RootFs hat macht es da noch einen Unterschied ob man das SWAP Passwort hat oder nicht. Klar könnten Temporäre Daten nur im SWAP zu finden sein aber bei den meisten Modernen Rechnern ist so viel Hauptspeicher vorhanden das der Kernel SWAP so kaum benutzt.
Man kann das gleiche Keyfile für root und swap benutzen habe ich gefunden aber ist das wirklich besser. Wie werden denn dann die Keyfiles gesichert. Ohne Passwort könnte dann doch jeder der die Platte in die Finger bekommt die Daten entschlüsseln. Gut Keyfile auf dem USB-Stick geht auch aber wo nimmt man den mit der darf niemals mit dem Notebook in einer Tasche landen. Wenn mit der Kette um den Hals aber macht das wer so und wie verteidigt man den im Zweifelsfall.
Ein Passwort ist finde ich leichter zu verteidigen. Man sagt es einfach nicht wenn man es nicht auf Zetteln lagert kann es nicht geklaut werden bin mir nicht sicher.
</Edit> |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sat Jun 13, 2020 6:43 pm Post subject: |
|
|
Zur Frage zum Swap:
Mein Swap liegt zusammen mit Root-Filesystem in der gleichen verschlüsselten Partition. Die hat aber erst LVM zum Inhalt und das erzeugt Logical Volumes. Insofern hab ich genau ein Keyfile. Ich habe auch als 2. Sicherheit Passwörter. Sehr lange wilde Passwörter. Und die sind nicht elektronisch irgendwo abgelegt. Die gibt es tatsächlich auf Papier. Jenachdem wie paranoid du sein willst (*hust*) versteckste diese Zettel entsprechend. Das muss nicht im selben Gebäude sein wo du lebst. Wobei so wichtig sind die Platten nun auch nicht bei mir. Aber gut "weggelegt" hab ich die Passwörter wohl ... 
Und wer das Keyfile replizieren kann, der ist doch eh im System. Nen zweites für Swap halte ich auch für unnötig.
Wenn du mehr Sicherheit willst dann lagerst du die Headers zu den gecrypteten Partitionen ebenfalls extern. Das macht das ganze nochmal erheblich sicherer. cryptsetup hat da auch Kommandos für. Hab das aber noch nicht gemacht.
Was den Stick angeht - theoretisch kann der kaputt gehen. Da ich davon keine Sicherheitskopie habe - aber eben das Passwort - kann ich zur Not ein neues Keyfile einstellen.
Wenn jemand mit Gewalt an dein System will musst du im Prinzip den Stick zerstören. Du kannst ja ne Kneifzange in der Nähe haben ... je nach dem wie paranoid es sein soll ... *lol* |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Sat Jun 13, 2020 7:44 pm Post subject: |
|
|
So Paranoid ist das gar nicht ... Hausdurchsuchungen werden in Deutschland heute recht Inflationär durchgeführt. Die Details lasse ich jetzt mal weg. Wer einen nicht Optimal gewarteten Internetzugang Betreibt ist von unerwünschtem Staatsbesuch nicht weit entfernt. Werden dann Kundendaten beschlagnahmt und absichtlich oder versehentlich öffentlich hat der Kunde Schadenersatzanspruch. Das kann teuer werden. Bei einer Hausdurchsuchung wenn die den Keyfile USB finden sind die Kundendaten auch weg.
Darum geht es mir aber gar nicht mal so. Was viel Wahrscheinlicher ist das mir der Rechner auf Reisen geklaut wird. Oder die Lufthansa wieder mein Gepäck nach Israel fliegt obwohl sie mich nach Berlin fliegen. Es kann Wochen dauern das Stück zurück zu bekommen und wer derweilen daran rumspielt kann ich nicht feststellen. Der Tägliche Wahnsinn halt. Ist dann ein Keyfile auf dem USB-Stick und das in der gleichen Tasche kann man sich das verschlüsseln sparen. Mir wäre die Passwort Methode wie jetzt für das Rootfs gemacht lieber. Aber halt das man RootFs und SWAP mit dem einmal eingegeben Passwort entsperrt. Ich will kein LVM weil ich es schlicht nicht brauche und es die Sache nur komplizierter macht.
Ich weiß nicht ob Du das Benutzt aber so ähnlich wie beim Thunderbird. Man kann da einstellen ob der Server zum Empfangen und Senden von Mails das gleiche Paswort benutzt dann muss man es nur einmal eingeben und der Benutzt das dann automatisch für beides. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sat Jun 13, 2020 11:36 pm Post subject: |
|
|
Naja auf Reisen kann man den Stick gut am Körper tragen. Wenn es um Diebstahl geht oder das dir dein Gepäck abhanden kommt haste immer den Stick. Natürlich musste den dann schon bei dir führen. Schlüsselbund?
Und sicher liegt es an der Wichtigkeit der Daten was sinnvoll erscheint. Bei nem Passwort ist es etwas das du dir merken kannst. Ein Zettel zum nachsehen mitzuschleppen dauernd weil man eine extrem wilde lange Passwortkombination hat macht für mich keinen Sinn. Wenn du aber ein Passwort hast das du dir merken kannst ist es auch irgendwo leichter es zu erraten.
Lies mal hier: https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption - da unter "On passphrases, detached LUKS headers, and (encrypted) keyfiles"
Leider wird das Auslagern der LUKS-Header nicht von genkernel unterstützt laut der Wiki.
Ansich kannst du wenn der swap dir weniger wichtig erscheint aber du ihn verschlüsseln willst das automatisieren.
Dazu hat openRC den service dmcrypt. Der wird bei mir im Boot-Runlevel gestartet.
Wegen Konfiguration schau dann in /etc/conf.d/dmcrypt.
Da findest du auch einen Eintrag für Swap. Da kannste auch ein Keyfile haben. Leg dazu an einem sinnvollen Ort deiner Wahl im root-Filesystem ein Keyfile an das nur dafür da ist den Swap zu entschlüsseln. Dann brauchste auch nur noch das eine Passwort um das root-Filesystem zu entsperren.
Ich habe einige externe Festplatten die alle verschlüsselt sind und von dem Dienst entschlüsselt werden. Jede hat ihr eigenes Keyfile. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Mon Jun 22, 2020 9:11 am Post subject: |
|
|
Man kann Passwörter schon so machen das man sich die Merken kann und die trotzdem sicher sind. Das was die Presse allen voran die c't immer behaupten das von Menschen erdachte Passwörter generell unsicher sind ist schlicht nicht wahr. Man muss aber schon auf einige Sachen aufpassen was scheinbar gerade Fachredakteuren schwer zu fallen scheint.
Ich habe jetzt mal mit den Methoden für die SWAP Verschlüsselung experimentiert. Das mit den Keyfiles ist halt schon sehr umständlich. Wegen dem shutdown to disk kann man die auch schlecht speichern. Weil beim booten eines früheren Zustandes aus der SWAP-Partition das mounten des rootfs um an die Keys zu kommen vermutlich keine gute Idee ist.
Ich habe jetzt die Änderung an dem Init-Script /etc/initrd.scripts so angepasst:
| Code: |
# At this point, keyfile or not, we're ready!
#####
# Ändere den Mapping Namen auf das PartLabel
if [ "$1" = "root" ]; then
Laufwerk=$CRYPT_ROOT
else
Laufwerk=$CRYPT_SWAP
fi
good_msg "Laufwerk: $Laufwerk"
Trennzeichen=`expr index "$Laufwerk" '='`
ErsterTeil=${Laufwerk:$Trennzeichen}
Trennzeichen=`expr index "$ErsterTeil" '='`
ZweiterTeil=${ErsterTeil:$Trennzeichen}
LUKS_NAME=$ZweiterTeil
good_msg "LUKS_NAME: $LUKS_NAME"
#
#####
crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"
|
So muss ich zwar momentan das Passwort zweimal eingeben aber es geht zumindest schon mal.
Bei der ganzen Sucherei bin ich zufällig darüber gestolpert das man die Filesysteme auch irgendwie remote entsperren kann. Das wäre sehr hilfreich wenn man mal einen Server aus der Ferne Neustarten muss. |
|
| Back to top |
|
|
forrestfunk81
Guru
Joined: 07 Feb 2006
Posts: 567
Location: münchen.de
|
| Posted: Mon Jun 22, 2020 1:40 pm Post subject: |
|
|
| alexander_ro wrote: |
So muss ich zwar momentan das Passwort zweimal eingeben aber es geht zumindest schon mal. |
Du kannst auch ein mit LUKS verschlüsseltes loop Device erstellen, in welchem die Schlüssel für die beiden Partitionen abgelegt werden. Dann brauchst du beim Booten nur einmal das Passwort für das loop Device eingeben und hast damit beide Schlüssel zur Verfügung.
| Code: |
# create an image file (here 10MB)
dd if=/dev/urandom of=file.img bs=1M count=10
# bind it to a loopback device
losetup /dev/loop0 file.img
# initialize it with luks
cryptsetup [your cipher, key and hash options here] luksFormat /dev/loop0
# open the image file
cryptsetup luksOpen /dev/loop0 keys
# format the image file
mkfs.ext4 /dev/mapper/keys
# mount the image file
mount /dev/mapper/keys /mnt/keys
# copy key files to image
cp /path/to/key1 /mnt/keys/
cp /path/to/key2 /mnt/keys/
# cleanup
umount /mnt/keys
cryptsetup luksClose keys
losetup -d /dev/loop0
|
Das File kann einfach ins Initramfs kopiert werden, dort als loop Device verwendet und mit cryptsetup entschlüsselt werden.
Zum Thema Initramfs packen möchte ich noch die Kernel Konfiguration CONFIG_INITRAMFS_SOURCE in den Raum werfen. Wenn man dort das Source Verzeichnis des entpackten Initramfs angibt (z.B. /usr/src/initramfs), wird der Kernel Build das Initramfs automatisch mit in das Kernel Binary aufnehmen. Dabei am besten gleich einen geeigneten "Built-in initramfs compression mode" auswählen. Das Kernel Binary ist dann zwar um einiges größer und dauert etwas länger zu laden, aber dafür geht das Initramfs nicht mehr verloren. Vorallem aber ist das Erstellen des Initramfs damit ein Kinderspiel, kein 'find .. | cpio .. | xz ' mehr.
Bleibt noch die Frage zum aktuell-Halten des Initramfs. Ich baue meine initramfs meist selbst (Custom Initramfs) und ich habe mir schon mal überlegt, die Binaries im Initramfs Source Verzeichnis auf die im System installierten "System Binaries" zu linken (eventuell per Hardlink). Das habe ich allerdings noch nicht ausprobiert.
_________________
# cd /pub/
# more beer |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Tue Jun 23, 2020 8:47 am Post subject: |
|
|
Das direkt in den Kernel zu integrieren ist sicher auch keine schlechte Idee. Vom laden wird das nicht viel unterschied machen. Ob man zwei kleiner Dateien oder eine große lädt.
Ich benutze genkernel um Kernel und InitRamFs zu erstellen. Das macht mir alles fertig. Ich finde das mit den Labeln besser weil ich es lesen kann im Gegensatz zur UUID und das durchgängig bis zum Mapping Namen für cryptsetup sorgt meiner Meinung für Übersichtlichkeit. Deswegen muss ich einen Patch in das genkernel Initscript einbauen. Das patchen könnte man aber leicht automatisieren. Wenn ich da so schon einen Patch brauche wäre mir die Lösung es so umzubauen das man dem Initscript sagen kann es soll ein Passwort für beides benutzen. Ich muss das aber erst noch finden wie die bei dem genkernel Initscript das ändern kann.
Falsch war der Code oben nicht weil er tut was er sollte ... wirklich richtig aber auch nicht ... 
Hier die Verbesserung:
| Code: |
# At this point, keyfile or not, we're ready!
#####
# Ändere den Mapping Namen auf das PartLabel
if [ "$1" = "root" ]; then
Laufwerk=$CRYPT_ROOT
else
Laufwerk=$CRYPT_SWAP
fi
good_msg "Laufwerk: $Laufwerk"
Trennzeichen=`expr index "$Laufwerk" '='`
LUKS_NAME=${Laufwerk:$Trennzeichen}
good_msg "LUKS_NAME: $LUKS_NAME"
#
#####
crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"
|
<Edit>
Irgendwie geht das immer nicht so wie ich es gerne hätte ...
Das Passwort ein zweites mal zu benutzen geht nicht weil man ein Passwort an cryptsetup nicht übergeben kann.
Geht doch ist mir nur nicht gleich eingefallen es zu versuchen: echo '<Passwd>' | cryptsetup open /dev/sdb4 GentooRoot
(Den Rest habe ich wieder gelöscht ist ja dann nicht nötig.)
</Edit> |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Thu Jul 02, 2020 2:02 pm Post subject: |
|
|
| Weiß jemand warum man bei genkernel für das InitRamFs keine andere als die Englische Tastatur einstellen kann. Man soll da Passwörter mit Sonderzeichen eingeben aber mit falschen Tastaturlayout. Oder man muss jedesmal die Tastatur extra wieder auswählen. Das macht nur Sinn bei einer Life-CD aber nicht bei einer Installation die an einen Rechner gebunden ist. Ich vermute jetzt mal das wenn man die Laufwerke per SSH Entsperren will geht diese Art der Tastaturauswahl aber nicht mehr. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Thu Jul 02, 2020 9:05 pm Post subject: |
|
|
Du kannst genkernel sagen das es die Keymap als Bootparameter beachtet.
Also in der manpage steht:
| Code: |
--[no-]keymap
Enables or disables keymap selection at boot.
|
Das bedeutet du musst wohl beim Aufruf
| Code: |
genkernel --keymap ...
|
benutzen.
Wegen des Kernelparamters steht dann in der manpage zu genkernel:
| Code: |
[...]
RAMDISK/INITRAMFS OPTIONS
The following options are some of those available to be passed as kernel parameters from the bootloader. Genkernel will not handle this
operation, please refer to your bootloader documentation for a more complete description of each.
[...]
keymap=MAP
Set keymap to MAP, e.g. keymap=de. For valid values of MAP please see /usr/share/genkernel/defaults/keymaps/.
dokeymap
Use keymap. Usage of keymap= implies this option, already.
[...]
|
Also musst du dann auch /etc/default/grub anpassen. Da kommen die Bootparameter ja rein.
Da drin:
| Code: |
[...]
GRUB_CMDLINE_LINUX='crypt_root=UUID=d5a3428b-b21c-42b4-a4ce-0818c92bca9c real_root=/dev/mapper/GENTOO-ROOT root_keydev=UUID=E716-DA12 root_key=dmcrypt-2.key dobtrfs dolvm' keymap=de dokeymap
[...]
|
Das ist nur ein Beispiel. Aber denke da kommt das hin. Wobei wahrscheinlich 'dokeymap' weggelassen werden kann.
Also genkernel baut dann zusätzlich die benötigten Binaries um die Keymap einzustellen. Welche Keymap genommen wird, kommt dann von Grub als Bootparamter später.
Und nicht vergessen
| Code: |
grub-mkconfig -o /boot/grub/grub.cfg
|
|
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Fri Jul 03, 2020 8:24 am Post subject: |
|
|
Bin etwas verwirrt ... hat der Kernel überhaupt was mit der Keymap zu tun?
Warum konfiguriert den genkernel nicht gleich das InitRamFs (das es ja so selbst baut) so das es die gewünschte Keymap benutzt. Hat das irgendeinen Nutzen wenn man es erst noch durch den Kernel schleust? |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Mon Jul 20, 2020 11:20 am Post subject: |
|
|
Ich habe jetzt mal versucht zum Testen ein initramfs selber zu bauen. Ich kopiere einfach die nötigen Dateien aus meinem rootfs zusammen. Das macht folgendes Script.
| Code: |
#!/bin/bash
#####
# Hinweise:
# Das Script muss man als User root ausführen.
# Parameter:
# $1 Pfand in dem das InitRamFs erstellt werden soll.
# Wird nichts angegeben wird es im aktuellen Verzeichnis erstellt.
#
#####
Pfad=$1
#####
# Verzeichnise im Root-Verzeichnis anlegen.
mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}bin
mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}dev
mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}etc
mkdir --parents --mode=u=+rx-w,g=+rx-w,o=+rx-w ${Pfad}proc
#
#####
#####
# Busybox kopieren und konfigurieren.
#
cp --archive /bin/busybox ${Pfad}bin
# Symbolisch Verlinkungen anlegen.
aktuellerPfad="`pwd`"
cd ${Pfad}bin
ln --force --symbolic busybox sh
ln --force --symbolic busybox ash
cd ${aktuellerPfad}
#
#####
#####
# Boot Script erzeugen.
aktuellerPfad="`pwd`"
cd ${Pfad}
cat > "init" << INIT
#!/bin/sh
echo "Geht das jetzt?"
[ ! -e /dev/console ] && mknod /dev/console c 5 1
[ ! -e /dev/null ] && mknod /dev/null c 1 3
[ ! -e /dev/tty ] && mknod /dev/tty c 5 0
[ ! -e /dev/tty0 ] && mknod /dev/tty0 c 4 0
[ ! -e /dev/tty1 ] && mknod /dev/tty1 c 4 1
[ ! -e /dev/ttyS0 ] && mknod /dev/ttyS0 c 4 64
[ ! -e /dev/ttyS1 ] && mknod /dev/ttyS1 c 4 65
[ ! -e /dev/urandom ] && mknod /dev/urandom c 1 9
[ ! -e /dev/random ] && mknod /dev/random c 1 8
[ ! -e /dev/zero ] && mknod /dev/zero c 1 5
exec /bin/sh
INIT
chmod u=+rwx,g=-rwx,o=-rwx init
ln --force --symbolic init linuxrc
cd ${aktuellerPfad}
#
#####
|
Bekommt man mit "chroot MeinInitRamFs/ /init" einen Shell-Prompt innerhalb des gebauten initramfs.
Wenn man das so in ein initramfs verpackt;
| Code: |
#!/bin/bash
Version=5.4.48
Pfad=$1
echo "Erstelle cpio Archiv"
find ./$Pfad -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-$Version-gentoo-x86_64.img
echo "InitRamFs mit xz komprimieren"
#xz --compress --extreme -9 --check=none --force initramfs-$Version-gentoo-x86_64.img
gzip -9 initramfs-$Version-gentoo-x86_64.img
echo "xz vom Dateinamen entfernen"
#mv initramfs-$Version-gentoo-x86_64.img.xz initramfs-$Version-gentoo-x86_64.img
mv initramfs-$Version-gentoo-x86_64.img.gz initramfs-$Version-gentoo-x86_64.img
echo "Installiere InitRamFs"
cp -a initramfs-$Version-gentoo-x86_64.img /mnt/boot
|
und mit Qemu versucht zu booten geht es nicht.
| Code: |
qemu-system-x86_64 -kernel /boot/vmlinuz-5.4.48-gentoo-x86_64 -initrd initramfs-5.4.48-gentoo-x86_64.img -nographic -append "console=ttyS0"
|
Mekert der Kernel
| Code: |
...
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
PCI: CLS 0 bytes, default 64
Trying to unpack rootfs image as initramfs...
Freeing initrd memory: 1124K
Initialise system trusted keyrings
workingset: timestamp_bits=62 max_order=15 bucket_order=0
...
--[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---
...
|
Finden und entpacken tut er es nur nicht ausführen.
Hier liest sich das so (wenn richtig Übersetzt) als würde der Kernel das initramfs als erstes rootfs benutzen.
https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
Hab wohl irgendwas übersehen ... |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Thu Aug 13, 2020 5:21 pm Post subject: |
|
|
Jetzt habe ich gefunden was ich da falsch gemacht habe. Das hier war etwas ungeschickt ...
| Code: |
find ./$Pfad -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-$Version-gentoo-x86_64.img
|
Mit dem "./$Pfad" bekommt man ein Archiv das alles in einem Unterverzeichnis hat was der Kernel nicht versteht weil halt die ganzen Pfad angaben dann falsch sind. Logisch ...
Hab es so geändert:
| Code: |
cd ./$Pfad
find . -print0 | sort -z | cpio --verbose --null -o -H newc --owner root:root --force-local --reproducible -F ../initramfs-$Version-gentoo-x86_64.img
cd ..
|
Das --verbose gibt dann Pfad und Dateinamen jeder Datei aus die ins Archiv kommt dann sieht man das auch wenn etwas falsch ist.
Das kann man jetzt mit Qemu wie oben angegeben booten. Gibt aber noch Fehlermeldung:
| Code: |
Geht das jetzt?[ 4.575384] random: fast init done
/bin/sh: can't access tty; job control turned off
|
man bekommt aber schon eine Shell mit der man dann experimentieren kann ... |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Thu Sep 17, 2020 3:21 pm Post subject: |
|
|
Och nee ... jetzt haben die die Option --disklabel ausgebaut.
| Code: |
genkernel --no-clean --luks --disklabel --microcode --menuconfig all
|
Den Mist mit der UUID gibts noch war ja klar warum Übersichtlich wenn man die Verwirrung Maximieren kann. Jetzt hatte ich mich gefreut weil nach Wochenlanger Arbeite mal was ging und auch auf den ersten Blick zu erkennen war was wie zusammengehört dann wird es einem wieder ohne Vorwarnung kaputt gemacht ... herzlichen Dank auch ... |
|
| Back to top |
|
|
|
Deutsches Forum (German)
