| View previous topic :: View next topic |
| Author |
Message |
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
 Posted: Thu Jun 04, 2020 8:22 am Post subject: Verschlüsseltes Rootfilesystem: Passwd eingabe beim booten |
 |
|
Hallo ... 
Ich habe gerade versucht eine Gentoo Installation zu bauen bei der das Rootfilesystem und SWAP verschlüsselt sind. Das habe ich auch soweit zum laufen bekommen. Nur leider kann der das Rootfilesystem nicht finden. Startet man dann eine Shell und da den cryptsetup Befehl und exit bootet das System.
Initrdfs und Kernel habe ich so mit genkernel gebaut:
| Code: |
genkernel --no-clean --luks --disklabel --microcode --menuconfig all
|
Weiß jemand zufällig wie man das so macht das der cryptsetup Befehl automatisch ausgeführt wird und ich nur noch das Passwort eingeben muss?
Grüße
Alexander |
|
| Back to top |
|
 |
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Thu Jun 04, 2020 9:30 am Post subject: |
|
|
Dazu musst du Bootparameter setzen.
Also wenn grub dein Bootmanager ist musste das in /etc/default/grub eintragen.
Da kann man über GRUB_CMDLINE_LINUX die Paramter einstellen
Bei mir sieht das z.B. so aus:
| 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
|
Allerdings nutze ich auch lvm. Das kannste weglassen. Und das ist nicht mit Passworteingabe sondern mit einem Keyfile. Das File liegt bei mir auf einem USB-Stick. Bedeutet ohne den Stick kann der Bootvorgang nicht stattfinden.
Weiterhin würde ich immer UUIDs nutzen weil der USB-Stick zum Beipsiel wechselnde Benennungen hat wenn der gemountet wird (/dev/sdX - das X ist wechselnd). crypt_root ist die UUID der verschlüsselten Partition. real_root ist das device das cryptsetup erzeugt wenn es die verschlüsselte Partition öffnet.
Wenn du Passworteingabe willst reicht vermutlich root_keydev und root_key wegzulassen. Ich hab das aber noch nicht ausprobiert.
Edit:
Ich hab eventuell vergessen zu erwähnen, das du natürlich das /boot/grub/grub.cfg neu erzeugen musst.
Ich mach das mit grub-mkconfig dann so:
| Code: |
grub-mkconfig -o /boot/grub/grub.cfg
|
Das Kommando beachtet dann /etc/default/grub für die Parameter. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Thu Jun 04, 2020 12:09 pm Post subject: |
|
|
Ich habe das jetzt mal so versucht was leider nicht funktioniert hat.
| Code: |
GRUB_CMDLINE_LINUX="crypt_root=/dev/sda4 real_root=/dev/mapper/GentooRoot root_keydev=/dev/sda"
|
Wer verarbeitet diese Parameter denn?
Der Kernel selber ist es eher nicht ... bin mir nicht sicher. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Thu Jun 04, 2020 12:26 pm Post subject: |
|
|
Hallo Alexander.
Hast du mein Edit gesehen? Sorry hab ich nicht gleich dazu geschrieben.
Du musst die Parameter natürlich übernehmen mit grub-mkconfig in das grub.cfg
Wegen "/dev/sda4" - nimm besser die UUID.
Kannste nachsehen wie die lautet mit 'blkid'.
root_keydev brauchst du nur, wenn du ein Keyfile zum entsperren nutzt. Bei der Passwortlösung macht das keinen Sinn.
Damit sagste dann auf welchem Device das Keyfile liegt.
Das Device für real_root kannst du nachsehen in der Benennung. Das ist etwas unglücklich als Beispiel oben, weil das ist ein Mappereintrag, der aber von LVM kommt. Das ist ein Logical Volume bei mir.
Du hast für root ein Filesystem ja angelegt. Den Eintrag findest du am besten indem du erst manuell mit cryptsetup entsperrst und dann blkid nutzt um die UUID von dem Filesystem zu holen.
Edit:
| Quote: |
Wer verarbeitet diese Parameter denn?
|
Das passiert über die initramfs - weil da wird ja zuerst mal entsperrt - vorher kann der Kernel nicht an die Root-Partition ran. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Thu Jun 04, 2020 6:19 pm Post subject: |
|
|
Da ich grade den neuen Kernel 5.6.16 gebaut habe musste ich auch die initramfs dazu erneuern. Die Ausgabe sieht so aus:
| Code: |
luthien /usr/src/linux # genkernel --luks --lvm initramfs
* Gentoo Linux Genkernel; Version 4.0.7
* Using genkernel configuration from '/etc/genkernel.conf' ...
* Running with options: --luks --lvm initramfs
* Working with Linux kernel 5.6.16-gentoo-luthien for x86_64
* Using kernel config file '/usr/share/genkernel/arch/x86_64/generated-config' ...
* Current kernel's LOCALVERSION is set to '-luthien'; Will ignore set --kernel-localversion value '-x86_64' because kernel was not build ...
* initramfs: >> Initializing ...
* >> Appending devices cpio data ...
* >> Appending base_layout cpio data ...
* >> Appending auxilary cpio data ...
* >> Appending busybox cpio data ...
* >> Appending blkid cpio data ...
* >> Appending btrfs cpio data ...
* >> Appending luks cpio data ...
* >> Appending lvm cpio data ...
* >> Appending modprobed cpio data ...
* >> Appending modules cpio data ...
* >> Appending linker cpio data ...
* >> Deduping cpio ...
* >> Pre-generating initramfs' /etc/ld.so.cache ...
* >> Compressing cpio data (.xz) ...
*
* You will find the initramfs in '/boot/initramfs-5.6.16-gentoo-luthien.img'.
* WARNING... WARNING... WARNING...
* Additional kernel parameters that *may* be required to boot properly:
* - Add "dobtrfs" for Btrfs device scanning support
* - Add "dolvm" for LVM support
* - Add "crypt_root=<device>" for LUKS-encrypted root
* - Add "crypt_swap=<device>" for LUKS-encrypted swap
* Do NOT report kernel bugs as genkernel bugs unless your bug
* is about the default genkernel configuration...
*
* Make sure you have the latest ~arch genkernel before reporting bugs.
|
Da du kein lvm nutzt geh ich davon aus das du das root aber auch swap seperat verschlüsselt hast.
Deswegen solltest du auch wie vorgeschlagen von genkernel auch crypt_swap einstellen weil das muss ja auch entsperrt werden.
Ob es auch real_swap gibt weiss ich grade nicht. Ich verwende auch einen Swap. Aber der liegt auf dem gleichen verschlüsselten Bereich wie root. Bei mir ist das so aufgebaut, das ich erst eine verschlüsselte Partition habe und da drin liegen dann logische Volumes für root aber eben auch für swap (also mit lvm). Deswegen brauch ich das nicht. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Thu Jun 04, 2020 7:27 pm Post subject: |
|
|
Gut zu wissen das es im initrd verarbeitet wird dann weiß ich wo man nach Infos suchen kann. Ich habe zwar einige Sachen gefunden aber nie hat einer geschrieben wo es her kommt. Leider ist das oft wie eine Todo Liste aufgebaut. Keiner Erklärt die Hintergründe warum man tun soll was beschrieben ist. Schon mal danke das Du das immer mit erklärt hast.
Ich habe es so hin bekommen das der nach dem Passwort fragt. Ich habe das in meiner fstab so angegeben das /dev/mapper/GentooRoot das Rootfilesystem ist. Das ist es auch nach dem er sucht. Soweit würde das gehen. Nur das der bei der automatischen Passwort abfrage dann das Entschlüsselte Laufwerk unter /dev/mapper/root mappen tut. Klar ich könnte das jetzt in der fstab ändern dann geht es vermutlich. Nur hätte ich das gerne als GentooRoot so lautet auch das Label der Partition. Ich würde auch gerne statt der UUID das LABEL verwenden. Die UUID ist halt überhaupt nicht selbst Erklärend.
Das mit crypt_root=LABEL=GentooRoot habe ich aber noch nicht zum funktionieren bekommen.
Ich habe jetzt zwar eine eigene SWAP Partition gemacht mit eigenem Passwort aber man könnte ja auch eine SWAP-Datei auf das Rootfilesystem legen. Damit geht aber dann glaube ich kein Shutdown to Disk ob der mit Verschlüsselung überhaupt geht weiß ich nicht. Da es aber nicht funktionierte wie gewünscht habe ich erst mal das mit der SWAP weg gelassen. Der Rechner hat 8GB-RAM wird also normal außer für Shutdown to Disk keine SWAP benötigen. Ich probiere halt gerade mal herum was geht und was nicht. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Thu Jun 04, 2020 10:17 pm Post subject: |
|
|
/dev/mapper/root gitbs bei mir auch. Das scheint einfach der Name zu sein den cryptsetup für die "entschlüsselte" Partition vergibt.
| (Auszug von blkid): |
/dev/mapper/root: UUID="WeNcwR-5pL7-QCAF-AgGA-GExf-bSxM-WIkdha" TYPE="LVM2_member"
|
Wie man sieht ist das hier die Partition die dann von LVM verwaltet wird. Deswegen liegt da auch nicht schon das root-Device bei mir.
In deinem Fall passt es natürlich und root ist das korrekte Element. Es könnte sogar sein, das du das "real_root" weglassen kannst. Weil es für die initramfs klar sein sollte wie das Device heisst.
In meinem Fall muss ich aber eben dann ein anderes Device angeben das nach Start von lvm verfügbar wird.
Wenn du "root" (den Namen) ändern willst, dann müssest du in die initramfs schauen und den Aufruf von cryptsetup verändern. Also da würde ich zumindest schauen.
Wegen der UUIDs - du kannst ja in fstab auch Kommentare dazu schreiben. Also LABEL hab ich noch nicht versucht. Ich sehe am mountpoint eigentlich welches Device vorne gemeint ist. Deswegen hatte mich das nie gestört.
Dazu findest du in der manpage zu cryptsetup:
| Code: |
[...]
LUKS EXTENSION
[...]
The <device> parameter can also be specified by a LUKS UUID in the format UUID=<uuid>. Translation to real device name uses symlinks in
/dev/disk/by-uuid directory.
[...]
|
Interessant ist das es auch /dev/disk/by-label gibt. Aber scheinbar scheint cryptsetup das nicht implementiert zu haben. Also so interpretiere ich die manpage dazu jetzt. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Fri Jun 05, 2020 7:56 am Post subject: |
|
|
Das Label wird mit verschlüsselt. Wenn man es lesen will mit e2label /dev/sdb4 wird man darauf hingewiesen das es einen Luks Header gibt.
(Ich boote das mit Qemu von USB deshalb hat das Laufwerk mal sda oder sdb je nach Zugriff Host oder Gast.)
| Code: |
e2label /dev/sdb4
e2label: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb4 zu öffnen
/dev/sdb4 hat ein crypto_LUKS-Dateisystem
|
|
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Fri Jun 05, 2020 10:52 am Post subject: |
|
|
Das verschlüsselte Device - bei dir jetzt im Beispiel /dev/sdb4 hat kein LABEL aber es gibt ein PARTLABEL.
Bei mir sieht das so aus:
| Auzug aus blkid: |
/dev/sda3: UUID="d5a3428b-b21c-42b4-a4ce-0818c92bca9c" TYPE="crypto_LUKS" PARTLABEL="Crypted Gentoo /" PARTUUID="cd1e1d55-027e-47be-b0f7-d139d615615a"
|
Keine Ahnung ob man das PARTLABEL irgendwo nutzen kann. Ich hab es "beschreibend" eingesetzt. Es wird angezeigt zum Beispiel wenn man die Partitionstabelle mit parted ausgibt:
| Code: |
luthien ~ # parted -a optimal /dev/sda print
Modell: ATA Crucial_CT275MX3 (scsi)
Festplatte /dev/sda: 275GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 3146kB 2097kB grub bios_grub
2 3146kB 2003MB 2000MB fat32 efi-boot boot, esp
3 2003MB 275GB 273GB Crypted Gentoo / msftdata
|
(Das Flag msftdata wurde von Windows 7 (das liegt bei mir auf /dev/sdb) damals bei der Installation da gesetzt. Windows trägt sich in die Efi-Partition ein ... warum das Flag da gesetzt wurde weiss ich nicht.) |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Fri Jun 05, 2020 12:10 pm Post subject: |
|
|
Das ist bei mir einfach leer:
| Code: |
parted -a optimal /dev/sdb print
Modell: Hitachi HTS542516K9SA00 (scsi)
Festplatte /dev/sdb: 160GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags:
Nummer Anfang Ende Größe Dateisystem Name Flags
1 1049kB 6291kB 5243kB bios_grub
2 6291kB 111MB 105MB ext2
3 111MB 21,6GB 21,5GB
4 21,6GB 160GB 138GB
|
Ich hatte das mit fdisk gemacht der glaube ich kann das nicht setzen. Muss ich mal suchen und probieren ob das dann geht.
<Edit>
Das finde ich interessant eine schöne Sammlung. Danach kann man bei LUKS2 auch eine Label setzen.
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-label
</Edit> |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Fri Jun 05, 2020 12:35 pm Post subject: |
|
|
Das kannste im Gentoo-Handbuch zur Installation nachlesen: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/de#Standard:_Partitionieren_mit_parted
Also so sollte es gehen:
| Code: |
parted -a optimal /dev/sdb
name 4 <Dein Name>
print
quit
|
Edit:
Ah das ist für das neue Format LUKS2. Aber Achtung - wenn man umstellt - die sind nicht kompatibel. Dafür hat emerge für das Paket cryptsetup ein Useflag und hatte mir ne fette Warnung rausgehauen sodas ich das erstmal nicht gemacht hab. Lies mal hier:
https://forums.gentoo.org/viewtopic-t-1108052.html
Getestet hab ichs noch nicht auf dem alten Laptop - werd ich aber noch machen.
Edit-2:
Die Sammlung ist wirklich top. Danke - da hab ich mir mal ein Lesezeichen drauf gesetzt. *grins* |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Fri Jun 05, 2020 2:47 pm Post subject: |
|
|
Ist mir nicht gleich wieder eingefallen aber fdisk hat ja mit x den Experten Modus da kann man dann auch das Label setzen. Ich weiß nicht genau was daran so expertig ist aber gut es geht. Das Beispiel von Dir geht auch. Ob sich das so jetzt mit Label booten lässt muss ich erst noch ausprobieren ...
Das mit LUKS1 oder LUKS2 ist seltsam. Ich habe das erst erstellt mit cryptsetup es wurde aber immer noch LUKS1 automatisch erstellt. Trotz der neuen Version von cryptsetup
| Code: |
qlist -Iv | grep cryptsetup
sys-fs/cryptsetup-2.3.2
|
<Edit>
Das lässt sich leider nicht booten. Es gibt bei mir in der Shell innerhalb der initrd aber auch nur das Verzeichnis /dev/disk/by-id die anderen für UUID oder LABEL sind gar nicht vorhanden.
</Edit> |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Fri Jun 05, 2020 5:58 pm Post subject: |
|
|
Wegen der PARTLABEL.
Lies mal hier: https://wiki.gentoo.org/wiki/Custom_Initramfs#Mount_by_UUID_or_label
Wenn ich das richtig verstehe kann das in der initramfs zuerst mit findfs aufgelöst werden, sodas cryptsetup die Auflösung nicht selber machen muss.
Also bei mir zeigt:
| Code: |
luthien /etc/portage/package.use # findfs PARTLABEL='Crypted Gentoo /'
/dev/sda3
|
Versuch mal in der initramfs das Kommando:
| Code: |
cryptsetup luksOpen $(findfs PARTLABEL=<Dein Partlabel>) <dein Name für das entsperrte Device>
|
Zumindest sieht das den Versuch wert aus. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Fri Jun 05, 2020 9:04 pm Post subject: |
|
|
Den Wiki Artikel kenne ich schon hatte den aber schon wieder vergessen. Den findfs gibt es in der initrd von genkernel nicht.
Ich habe jetzt mal gesucht wie man das wieder in einzelne Dateien zerlegt.
Ist ja ganz einfach ein cpio Archiv ja echt ... geht nur nicht so wie die meisten es beschreiben.
| Code: |
file initramfs-4.19.97-gentoo-x86_64.img
initramfs-4.19.97-gentoo-x86_64.img: XZ compressed data
|
Ah ein xz ist das ... dem muss man aber das xz anhängen sonst verweigert unxz die Arbeit.
| Code: |
mv initramfs-4.19.97-gentoo-x86_64.img initramfs-4.19.97-gentoo-x86_64.img.xz
unxz initramfs-4.19.97-gentoo-x86_64.img.xz
|
Nun noch das cpio auspacken
| Code: |
cpio --extract --make-directories --format=newc --no-absolute-filenames < initramfs-4.19.97-gentoo-x86_64.img
45558 Blöcke
|
Ein Kinderspiel wenn man weiß wie es geht ...
Man findet da drinnen lauter Hübsche Sachen ... Diamanten, Ölquellen und natürlich das init Script das genkernel verwendet und da drinnen (im init) alte bekannte wie root_real usw.. Das werde ich mir Morgen mal näher anschauen. Dann sieht man besser was geht und was nicht. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Fri Jun 05, 2020 9:56 pm Post subject: |
|
|
Danke jetzt hast du mich neugierig gemacht selber reinzuschaun. *schmunzelgrins*
So geht es aber:
| Code: |
blkid -o device -l -t PARTLABEL="Crypted Gentoo /"
|
Das ergibt bei mir auch:
Und:
| Code: |
mithrandir@luthien ~/test $ ls -l sbin
insgesamt 5716
-rwxr-xr-x 1 mithrandir users 1085240 5. Jun 23:39 blkid
-rwxr-xr-x 1 mithrandir users 1942880 5. Jun 23:39 btrfs
lrwxrwxrwx 1 mithrandir users 5 5. Jun 23:39 btrfsck -> btrfs
-rwxr-xr-x 1 mithrandir users 2801192 5. Jun 23:39 cryptsetup
lrwxrwxrwx 1 mithrandir users 19 5. Jun 23:39 dmsetup -> ../usr/sbin/dmsetup
lrwxrwxrwx 1 mithrandir users 19 5. Jun 23:39 dmstats -> ../usr/sbin/dmstats
lrwxrwxrwx 1 mithrandir users 7 5. Jun 23:39 init -> ../init
lrwxrwxrwx 1 mithrandir users 15 5. Jun 23:39 lvm -> ../usr/sbin/lvm
|
Also das gibt es in meiner initramfs. Im init-Script ist auch findfs erwähnt. Also wahrscheinlich kann man das mit irgendeiner Option dem Genkernel sagen - dann hat er das auch. Aber reicht ja mit blkid.
Edit:
Der Aufruf von cryptsetup steht in initrd.scripts im Verzeichnis etc. Da findest ab Zeile 1745 die Funktion "openLUKS" und in Zeile 1900 den eigentlichen Aufruf von cryptsetup mit luksOpen:
| Code: |
crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"
|
Ab Zeile 2256 findest du dann die Funktion "start_LUKS". Die benutzt das openLUKS:
| Code: |
start_LUKS() {
# if key is set but neither ssh enabled or key device is given, find
# the key device
[ -n "${CRYPT_ROOT_KEY}" ] && [ -z "${CRYPT_ROOT_KEYDEV}" ] \
&& sleep 6 && bootstrapKey "ROOT"
if [ -n "${CRYPT_ROOT}" ]
then
openLUKS "root"
if [ -n "${REAL_ROOT}" ]
then
# Rescan volumes
start_volumes
else
REAL_ROOT="/dev/mapper/root"
fi
fi
# same for swap, but no need to sleep if root was unencrypted
[ -n "${CRYPT_SWAP_KEY}" ] && [ -z "${CRYPT_SWAP_KEYDEV}" ] \
&& { [ -z "${CRYPT_ROOT}" ] && sleep 6; bootstrapKey "SWAP"; }
if [ -n "${CRYPT_SWAP}" ]
then
openLUKS "swap"
if [ -z "${REAL_RESUME}" ]
then
# Resume from swap as default
REAL_RESUME="/dev/mapper/swap"
fi
fi
}
|
Im init-Skript ab Zeile 608 findest du dann den Aufruf von start_LUKS:
| Code: |
# Initialize LUKS root device except for livecd's
if [ "${CDROOT}" != '1' ]
then
start_LUKS
if [ "${NORESUME}" != '1' ] && [ -n "${REAL_RESUME}" ]
then
case "${REAL_RESUME}" in
LABEL=*|UUID=*|PARTLABEL=*|PARTUUID=*)
RESUME_DEV=""
retval=1
if [ ${retval} -ne 0 ]
then
RESUME_DEV=$(findfs "${REAL_RESUME}" 2>/dev/null)
retval=$?
fi
if [ ${retval} -ne 0 ]
then
RESUME_DEV=$(blkid -o device -l -t "${REAL_RESUME}" 2>/dev/null)
retval=$?
fi
if [ ${retval} -eq 0 ] && [ -n "${RESUME_DEV}" ]
then
good_msg "Detected real_resume=${RESUME_DEV}"
REAL_RESUME="${RESUME_DEV}"
fi
;;
esac
do_resume
fi
fi
|
Jetzt musste nur noch (*hust*) rausfinden wie du da am am leichtesten eingreifen kann. Mir ist das jetzt auch zu spät - aber ich schau mir das morgen auch noch mal tiefer an ...
Aber dann haste schon mal nen paar Hinweise wo du weiterschauen kannst.
*müde sein jetzt* *grins*
Tyrus |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Sat Jun 06, 2020 9:20 am Post subject: |
|
|
Wo ich geschrieben habe das es findfs nicht gibt wusste ich noch nicht wie man das initramfs auspackt. Ich hatte es einfach in der initramfs Shell ausprobiert. Stimmt blkid gibt es da.
Danke für Deine Vorsuche das start_LUKS hatte ich zwar auch schon entdeckt aber den Rest nicht. Das hat schon mal geholfen. Da kam mir dann die Idee mal zu schauen was die mit dem crypt_root so machen. Ich hatte da einfach LABEL angegeben also so: crypt_root=LABEL=GentooRoot was aber halt für das Label in der GPT falsch ist da muss man PARTLABEL statt LABEL angeben. Sieht dann so aus: crypt_root=PARTLABEL=GentooRoot.
So findet er dann das Laufwerk und frägt automatisch nach dem Passwort zum entsperren. Der mappt das entsperrte Laufwerk aber immer noch auf /dev/mapper/root. Das wollte ich eigentlich auf /dev/mapper/GentooRoot haben. Also das er es mappt auf den PARTLABEL Namen. Da muss ich jetzt mal suchen. Vielleicht gibt es ja da auch wieder eine Option die ich nicht kenne ... 
<Edit>
So wie es aussieht ist das leider fest vorgegeben.
Die rufen die Funktion: openLuks "root" auf.
</Edit> |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Sat Jun 06, 2020 10:55 am Post subject: |
|
|
Zur Namensvergabe des entsperrten Device:
Den Verdacht das das hart verdrahtet ist hatte ich ja von Anfang an. Weil bei mir ist das Device ja auch unter dem Namen vorhanden.
Was man machen könnte ist ein kleines Script schreiben. Zwei Funktionen reinstecken. Eine entpackt die initramfs, die andere setzt alles wieder zusammen. Und dann kannste das patchen. Also nach >> openLUKS "root" << suchen und root ersetzen.
Also einfach mal so als Idee.
Edit:
Als Erweiterung - welcher Name soll ersetzt werden - das kannste auch noch etwas optimieren. Dazu kannste noch ne Funktion machen die aus der /etc/fstab das rausholt. Also Zeile suchen die als Mountpoint nur "/" enthält. Dann den Device-Eintrag da rausfiltern. Zur Sicherheit kannste das Ergebnis nochmal mit blkid Aufruf von oben gegenchecken ob dann ein auch wirklich das aufgelöst wird in etwas der Art "/dev/sdX". Damit haste dann auch verifiziert das das PARTLABEL noch zur /etc/fstab passt. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Sat Jun 06, 2020 8:10 pm Post subject: |
|
|
Ich musste da jetzt erst mal Überlegen wie ich da weiter mache ...
Ja das wäre eine Möglichkeit.
Aber die fstab benutzt der glaube ich gar nicht. Weil er ja alle Parameter vom Kernel geliefert bekommt. Weil gerade Kernel ... warum man die Parameter durch den Kernel schleust ist mir ein echtes Rätsel der macht damit ja nichts das ist nur Mega verwirrend. Und ob man nun einen Grub oder ein InitRamFs neu installiert ist Jacke wie Hose. Wenn das ja eh alles von genkernel zusammen generiert wird könnte man das ja in einer Konfigurationsdatei im initramfs unterbringen. Die Kernel Macher sollten mal einen präfix einführen mit dem Markiet wird wo die Optionen verarbeitet werden damit könnte man vermutlich für etwas Klarheit sorgen. Klare Schnittstellen ohne überflüssige Datenübergabe wäre aber besser ... aber gut nur weil ich der Meinung bin wird das keiner Ändern also gehen wir mal davon aus die wissen was sie tun.
Mit crypt_root bekommt der das Physikalische Gerät mitgeteilt auf dem die Verschlüsselten Daten sind.
Wenn der dann einen fixen Namen "/dev/mapper/root" vergibt wozu braucht der dann real_root?
Das entsperrte Laufwerk kommt doch so immer in /dev/mapper also könnte man in real_root den Namen übergeben auf den das Laufwerk gemappt werden soll. In meinem Fall also real_root=GentooRoot. Im init Script baut man das dann zu /dev/mapper/GentooRoot zusammen.
<Edit>
Habe ich gerade noch entdeckt:
| Code: |
real_root=<...>
Legacy kernel parameter from kernel-2.4 initrd. Does the same as root=, which should be used in its place.
|
wohl nicht mehr so aktuell der Parameter.
</Edit> |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Mon Jun 08, 2020 8:38 am Post subject: |
|
|
Ich werd das so mal versuchen. Ich weiss nicht so genau wie man Strings in einem Shell-Script zerlegt aber es scheint in dem Beispiel so zu gehen. Den Teil zwischen den fünf Kommentarzeichen oben und unten muss man in das init etc/init.scripts ins der Funktion openLUKS einbauen. Den $1 darf man aber nicht verändern das ist der erste Funktionsparameter. Ist in meinem Beispiel anders weil es keine Funktion ist. Für Swap müsste man das ein zweites mal einfügen. Wenn man aber weder UUID noch LABEL oder PARTLABEL angibt funktioniert das so nicht mehr.
| Code: |
#!/bin/sh
Parameter1='root'
CRYPT_ROOT='crypt_root=PARTLABEL=GentooRoot'
#####
# Diesen Teil in die Funktion openLUKS beim case $1 einfügen.
# case $1 darf nicht verändert werden ist hier nur zum Testen umbenannt.
Trennzeichen=`expr index "$CRYPT_ROOT" '='`
ErsterTeil=${CRYPT_ROOT:$Trennzeichen}
Trennzeichen=`expr index "$ErsterTeil" '='`
ZweiterTeil=${ErsterTeil:$Trennzeichen}
case $Parameter1 in
root)
TYPE=ROOT
LUKS_NAME='/dev/mapper/'$ZweiterTeil
;;
swap)
TYPE=SWAP
;;
esac
#
#####
echo $Trennzeichen
echo $CRYPT_ROOT
echo $ErsterTeil
echo $ZweiterTeil
echo $LUKS_NAME
|
|
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Mon Jun 08, 2020 11:43 pm Post subject: |
|
|
Also es geht doch darum 'LUKS_NAME' auf 'GentooRoot' zu setzen.
Zumindest sagt mir das der Aufruf von cryptsetup in Zeile 1900.
| Code: |
crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"
|
Die Zuweisung für LUKS_NAME ist in Zeile 1764:
| Code: |
eval local LUKS_DEVICE='"${CRYPT_'${TYPE}'}"' LUKS_NAME="$1" LUKS_KEY='"${CRYPT_'${TYPE}'_KEY}"'
|
Also muss nur $1 mit GentooRoot an der Stelle ankommen.
/dev/mapper muss sich nicht davor stehen. Das wird von cryptsetup selber gemacht.
Die von dir gezeigte case-Unterscheidung würde ich einfach so ändern auf 'GentooRoot' (also erster Versuch):
| Code: |
case $1 in
root) <-- hier dann GentooRoot)
local TYPE=ROOT
;;
swap)
local TYPE=SWAP
;;
esac
|
OpenLUKS bekommt das $1 von dem Aufruf aus der Funktion start_LUKS ab Zeile 2265.
Da muss der Aufruf angepasst werden. Weil da wird hart verdrahtet "root" reingeschickt. Der Einfachheit halber das dann auf "GentooRoot" ändern für den ersten Versuch.
Weiterhin gibt es dann die harte Verdrahtung da drunter noch:
| Code: |
if [ -n "${CRYPT_ROOT}" ]
then
openLUKS "root" <-- hier
if [ -n "${REAL_ROOT}" ]
then
# Rescan volumes
start_volumes
else
REAL_ROOT="/dev/mapper/root" <-- hier
fi
fi
|
Da sollte das "root" hinten ebenfalls gepatched werden auf deinen Wert. Also für den ersten Versuch "GentooRoot"
Für Swap da drunter ähnlich.
Das kann man wenn der Versuch klappt verbessern indem dem Patchscript den zu verdrahtenden Wert variabel ermitteln lässt. Also ich würde das Patchscript dann erst /etc/fstab auslesen lassen und die Zeile mit dem Mountpoint "/" enthält das PATRTLABEL. Das kann man dann vorher noch gegenchecken - also ob die Auflösung des PARTLABEL nach Devicename der Art /dev/sdX klappt. Das geht ja einfach mit blkid. Und wenn der Check erfolgreich ist kann das Patchscript dann die oben erwähnten Stellen patchen.
Edit:
Das Patchscript zu erzeugen da würde ich keine Stringuntersuchung machen. Erster Versuch nehmen. Dann mit Diff einen Patch erzeugen der die Änderungen hat. Den kannste jetzt verändern wenn das variabel werden soll über das Script. Eine Zeile rauswerfen und ne neue rein. Also du nimmst die ersten x Zeilen, hauste ne eigene Zeile rein die variablel angepasst wird und dann wieder den Rest anfügen (head, tail, echo und cat sollten da helfen). Zum Schluss rufste dann das patch-Kommando auf. So in der Art würde ich das versuchen. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Tue Jun 09, 2020 5:56 am Post subject: |
|
|
Bei mir gibt es zwar eine fstab die enthält aber nicht das GentooRoot.
Sieht so aus:
| Code: |
/dev/ram0 / ext2 defaults 0 0
proc /proc proc defaults 0 0
|
Nachdem was ich gefunden habe kann blkid das PARTLABEL nicht alleine ausgeben. Deshalb habe ich es aus dem CRYPT_ROOT genommen. Aber das setzen des LUKS_NAMEN ist natürlich falsch.
Müsste so aussehen:
| Code: |
LUKS_NAME='$ZweiterTeil
|
Wie ich ohne String Operationen an den Namen kommen soll weiß ich jetzt nicht.
Ich hätte das Script einfach manuell geändert und dann das ganze wieder in das initramfs verpackt. Man muss bei einem Update ja dann so immer darauf achten das einem die Änderung nicht verloren geht. Meine Idee war das ich an so wenig stellen wie möglich Änderungen mache. Deshalb habe ich den Aufruf des Scripts unverändert gelassen. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Tue Jun 09, 2020 7:27 am Post subject: |
|
|
Schnelle Frage - was zeigt denn bei dir:
Ich bekomme als Ausgabe:
| Code: |
/ /dev/mapper/GENTOO-ROOT btrfs rw,relatime,ssd,space_cache,subvolid=5,subvol=/
|
|
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Tue Jun 09, 2020 7:46 am Post subject: |
|
|
Ja das gibt der bei mir auch in dem Format aus nur halt ext4 und mit GentooRoot weil ich das anders geschrieben habe. Macht er aber nur wenn ich es manuell zusammen baue. Wenn ich es so konfiguriere das er nach dem Passwort eingeben automatisch bootet gibt er /dev/mapper/root aus.
Den Befehl gibt es aber in meinem initramfs nicht ob man den da rein bekommt weiß ich nicht. |
|
| Back to top |
|
|
Tyrus
Guru
Joined: 03 Feb 2018
Posts: 300
|
| Posted: Tue Jun 09, 2020 11:23 am Post subject: |
|
|
Naja ich würde es ja nach wie vor von aussen patchen.
Also erst genkernel aufrufen das die initramfs baut. Dann ein Script haben, das Auspacken und Einpacken kann und dazwischen einfach die eine Datei patcht. Also dann brauchst auch das 'findmnt' nicht in der Initramfs. Du musst doch nach dem Bau der Initramfs nur sicherstellen das sich die Verhältnisse nicht geändert haben. Mit dem 'findmnt' kannste das Partlabel extraieren (also aus der aktuellen Situation) und das Ergebnis kannst dann mit dem blkid gegenchecken bei der Partition. Wenn du dann als Ergebnis einen Devicenamen wie /dev/sdX bekommst stimmt alles. Dann kannste das Partlabel in das Script in der initramfs reinpatchen.
Innerhalb der initramfs das Script ummodeln bedeutet ja auch das du das immer erneuern musst. Du musst das jedes mal wenn du genkernel aufgerufen hast wieder machen. Also klar kannste das machen, aber ausserhalb hast du einfach viel mehr Kommandos zur Verfügung um da was zu ändern.
Nur ein paar Gedanken. Ich will dir da nicht reinreden. Ist eine lokale Lösung und eigentlich egal - wichtig ist es funktioniert für dich. |
|
| Back to top |
|
|
alexander_ro
Guru
Joined: 22 Nov 2014
Posts: 427
|
| Posted: Tue Jun 09, 2020 11:50 am Post subject: |
|
|
Ich sehe da nun nicht wirklich einen großen Unterschied. Ein/Aus-Packen muss ich es in beiden Fällen. Einen Patch machen und mit dem gleichnamigen Kommando einbauen oder was ähnliches muss ich auch in beiden Fällen. Vergessen darf ich das auch in beiden Fällen nicht und wenn man es mit genkernel neu macht muss ich das wieder korrigieren auch in beiden Fällen.
Nur das es sich nicht mehr booten lässt wenn man das initramfs aus und wieder einpackt. Warum weiß ich nicht. Muss mal suchen was da falsch ist.
Muss man das eigentlich unbedingt einpacken?
Die wichtigen Filesystem habe ich so nicht als Kernel-Module also müsste der Kernel doch ein ext2 Filesystem auch direkt lesen könne. Also den Inhalt des initramfs cpio auch ohne cpio Weg booten können.
<Edit>
Man hat doch dann einige der Programme aus dem root Filesystem in dem initramfs. Wenn es für die Updates gibt müsste man doch eigentlich das initramfs neu bauen. Zumindest wenn es irgendwelche Sicherheitsrelevanten Udates sind. Ob das jemals einer gemacht hat? Also ich nicht weil ich bisher gar nicht wusste was alles in dem initramfs eingepackt ist. Ich hatte angenommen das wurde geschaffen damit der Kernel Zugang zu den Kernel-Modulen hat die er braucht um ein Rootfs einzubinden. Ist aber ja schon fast ein eigenes Rootfs das da eingepackt wird. Sogar Tastatur Maps sind da nur kann man die auch nicht vorgeben. Der Parameter --keymap de wählt leider nicht das Deutsche Layout aus.
</Edit> |
|
| Back to top |
|
|
|
Deutsches Forum (German)
