Du bist nicht eingeloggt! Möglicherweise kannst du deswegen nicht alles sehen.
  (Noch kein mods.de-Account? / Passwort vergessen?)
Zur Übersichtsseite
Hallo anonymer User.
Bitte logge dich ein
oder registriere dich!
 Moderiert von: mercury, Schalentier


 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 170 171 172 173 [174] 175 176 177 178 ... 215 nächste » letzte »
erste ungelesene Seite | letzter Beitrag 
GarlandGreene

Mod GIGN
in beiden Fällen muss man sich mit dem jeweiligen Bootmanager halt etwas auskennen, um ihn zu reparieren.
28.12.2020 10:52:03  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Farbkuh

farbkuh
 
Zitat von [KdM]MrDeath

hmmm ok, komisch, danke für die ausführung aber WAS da jetzt genau kaputt war kann ich dir leider auch nicht sagen Breites Grinsen

finds nur amüsant dass wir da wohl diametral entgegenegesetze "ängste" haben.
wenn "grub kaputt ist", ist das schlimmste was man so machen müsste vonner live cd booten und das dann von der aus zu reparieren.
wenn der windows boot kaputt ist ja keine ahnung, ich glaub nicht wenige sind da schon mit ner kompletten neuintsallation beglückt worden.



Mein Angst ist eigentlich, dass ich aufgrund meines Unverständnisses es irgendwie schaffe irgendwas derartig falsch zu machen, dass ich quasi gar nicht mehr in eins der OS reinkomme. Is mir schon mal vor vielen Jahren passiert. Deswegen bin ich da wohl so ängstlich.
Der Kommentar von statixx "2 mal ESP klingt jedenfalls schlecht" hat mich dann noch mal nachträglich verunsichert. Grub/Bootloader sind für mich einfach Voodoo den ich noch nicht verstehe. Vielleicht beschäftige ich mich mal eingehend damit. Breites Grinsen
28.12.2020 10:55:04  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
in deinem fall zwei ESP sind unerwartet jo und sollten wohlmöglich nicht da sein.
bei uns in der firma wird so allerdings nen getrennter a/b boot mechanismus realisiert, ein "ist definitiv kaputt und nix geht mehr" heisst das also noch nicht automatisch.
28.12.2020 11:06:56  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
 
Zitat von GarlandGreene

in beiden Fällen muss man sich mit dem jeweiligen Bootmanager halt etwas auskennen, um ihn zu reparieren.


das stimmt allerdings, haste recht.

wobei man halt bei linux seit 20 jahren wenn man sich auskennt die probleme reparieren kann und bei windows erst seit irgendwie vista bzw es irgendwelche bcdrec live tools gibt.
28.12.2020 11:07:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Zitat von [KdM]MrDeath

lass mich raten: im uefi grub als config wieder hinzugefügt?



Richtig. Oder SATA1 auswaehlen, womit das UEFI wohl die ESP meint und letztendlich GRUB laedt. Weil? So halt. Die Anzahl der Layer zwischen Hardware und "Kernel wird geladen" moechte irgendwie immer zunehmen. Kaputter Bootloader kann mit Wissen und dem richtigen Werkzeug gut heilen. Passiert zum Glueck selten und eher durch BIOS-Updates. Auf fremden System oder ohne das noetige Werkzeug ist es uebel.


Third Level Horror
Bei uns hat es mal eine C++ X86_64 Redistributable des MSVC auf einem Windowssystem zerschossen. Konnte man im Depedency Walker nachvollziehen, Bitfehler oder schief gelaufenes Windowsupdate. Jeglicher Versuch es irgendwie zu beheben sind gescheitert. Weil die Microsoft Installer und Reparaturwerkzeuge auch hingefallen sind. Es musste aber auf diesem Windows laufen! Habe dann eine 32 Bit Version kompiliert und herausgegeben.
Vermutlich haetten wir auch die Bibliothek irgendwo her kopieren koennen. Waere sicher zu einfach gewesen verschmitzt lachen


Ach ja. Frohe Weihnachten
[Dieser Beitrag wurde 6 mal editiert; zum letzten Mal von hoschi am 28.12.2020 18:21]
28.12.2020 15:24:41  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
GarlandGreene

Mod GIGN
ich finde da den Raspberry-Bootloader irgendwie erfrischend einfach. Da, auf der Karte is ne Datei. Lad die mal und Bob's your uncle. Beim Pi4 gibts gleich wieder ne Bootpartition. Nur weil man Betriebssysteme nicht auf FAT32 laufen lassen will.
28.12.2020 18:36:58  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Oli

AUP Oli 21.12.2018
Schönes Bild hoschi!

Als Belohnung gönn dir einen Schluck Honig.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Oli am 28.12.2020 19:19]
28.12.2020 19:19:12  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
csde_rats

AUP csde_rats 04.09.2021


Hab den Kram nicht verfolgt und fand das eine gute Zusammenfassung.
28.12.2020 22:31:33  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Rootsquash

Arctic
Ich glaub' das Mainboard in meinem alten Fujitsu-Bürorechner verhält sich bei dem UEFI-Kram auch anders als das ASUS im Heim-Desktop.
Während man es eigentlich gewohnt ist, dass man eine Platte mit bootbarem OS einfach anklemmt und dann bootet, möchte die Fujitsu-Hure erst eine Grub-Installation haben bevor er den Bootmanager sieht, anzeigt und booten kann.

Selbigen Eintrag wird Farbkuh gelöscht haben.
Ich müsste den ganzen Krempel auch nochmal nachlesen, irgendwie ist das alles komplizierter als damals.

:-|

Empfehlung für kompakte Literatur zum Thema?
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Rootsquash am 29.12.2020 11:13]
29.12.2020 11:12:54  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Hier.
Ich verwende GRUB, einfach weil ich es schon kenne und es alles wichtige unterstützt. Bei Laptops bevorzuge ich die Hardwareverschlüsselung der Festplatte, weil Hardwareveschlüsselung transparent für die Betriebssysteme ist. Ich spare mir damit die Konfiguration und vermeide Schwierigkeiten, weil es die Komplexität verringert.




Den Bossgegner herausfordern Secure Boot.

Ich mache Secure Boot immer aus. Beim letzten ThinkPad war das erfreulicher Weise schon der Fall. Stattdessen habe ich zusätzlich ein BIOS Passwort, zusammen mit der Hardwareverschlüsselung sollte es mir ein relativ sicheres Leben ermöglichen ohne übermässig viel Aufwand.

Verwendet ihr Secure Boot?
Ich nehme an, die meisten werden ansonsten LUKS oder Hardwareverschlüsselung verwenden?
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 29.12.2020 12:14]
29.12.2020 11:50:22  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
Ne Empfehlung hab ich nicht, aber den Hinweis dass das aktuelle Humble bundle ein Buch zum Vorgang beinhaltet. Keine Ahnung ob das was taugt oder inwieweit das schon auf uefi eingeht.

https://www.humblebundle.com/books/linux-apress-books?hmb_source=humble_home&hmb_medium=product_tile&hmb_campaign=mosaic_section_1_layout_index_1_layout_type_twos_tile_index_2_c_linuxapress_bookbundle
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 29.12.2020 11:57]
29.12.2020 11:56:18  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
 
Zitat von Oli

Als Belohnung gönn dir einen Schluck Honig.



*schleck*
Ist für meine arme Leute Mahlzeit, Quark.


Habe gestern zum ersten mal mit Signal eine Videokonferenz mit der Familie gemacht (Linux, Windows, iOS, Android). Hat gut funktioniert bis auf die üblichen "Wieso nimmt Windows das eingebaute Mikrofon?". Die App auf den Smartphones dreht das Bild nicht ins Querformat, die Teilnehme bleiben dann vertikal. Das könnte man noch verbessern.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 29.12.2020 12:11]
29.12.2020 12:06:43  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
 
Zitat von hoschi

Verwendet ihr Secure Boot?
Ich nehme an, die meisten werden ansonsten LUKS verwenden?


Da hast das eine mit dem anderen doch gar nix zu tun.
29.12.2020 12:10:01  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
hoschi

hoschi
Ist auch nicht so gemeint.

// edit
Das "ansonsten" ist natürlich doof platziert, bezieht sich auf die Hardwareverschlüsselung der Festplatte.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 29.12.2020 12:12]
29.12.2020 12:11:54  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
kRush*

kRush*
Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)

GRUB brauchte damit irgendwie fast ne Minute, weil es SHA von Hand macht.. oder so.
29.12.2020 14:06:08  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
B0rG*

Gordon
 
Zitat von kRush*

GRUB brauchte damit irgendwie fast ne Minute, weil es SHA von Hand macht.. oder so.



Gibt's dafür eigentlich eine Lösung um es zu beschleunigen?
29.12.2020 14:43:43  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
FuSL

AUP FuSL 22.06.2012
Wenn ich's recht im Kopf habe: Wenn es wirklich grub macht: nicht wirklich (das ist aber nur der Fall, wenn man mit cryptodisk / encrypted /boot arbeitet) – wenn man die Entschlüsselung also erst nach Laden von initramfs/initrd macht, sind da schon die normalen Kernelmodule verfügbar mit den gewohnten Geschwindigkeiten.

Kommt also ein bisschen drauf an, wie man's einrichten / was man haben will.
29.12.2020 14:49:46  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
- weniger rounds -> lol?
- implementierung besser machen -> jo geht
- wozu der fuck überhaupt? xkcd sich im klaren sein was man denn genau erreichen will/was für einen vorteil man dadurch hat.

ich persönlich fahr mit der schiene, ich will das szenario absichern

ich hab zugriff auf die hardware -> jemand anderes hat zugriff auf die hardware -> nix leaked.

was ich nicht absichern will
ich hab zugriff auf die hardware -> jemand anderes hat zugriff auf die hardware -> ich hab wieder zugriff auf die hardware -> nix leaked.


ja, das ist ein bishen luxus weil ich halt kein journalist bin der damit rechnen muss dass an der grenze ein chips ins smartphone gelötet wird, aber reicht einfach auch schon für sehr vieles...
29.12.2020 14:50:03  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
kRush*

kRush*
Iterationen von Hand runterdrehen, bis es erträglich ist (und die NASA deinen Key wohl mit nem Taschenrechner bruteforcen kann) oder systemd-boot wurde afair irgendwo als sha-ni nutzende Alternative genannt, habe ich aber noch nicht ausprobiert und hat andere Einschränkungen.
29.12.2020 14:56:24  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
B0rG*

Gordon
Hmh. Schade. Nicht oder weniger sicher machen ist leider wegen Compliance in meinem Fall nicht möglich. Also muss ich wohl damit leben, dass das Entschlüsseln am Anfang der langsamste Teil des Bootvorgang ist :/. systemd-boot werde ich mir mal anschauen, danke für den Tipp!
29.12.2020 15:22:00  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
Systemd-boot hat den Kernel und initramfs doch direkt in der efipartition liegen, oder nicht? Wenn ich da nicht falsch gewickelt bin, ist das doch wie unverschlüsseltes /boot.
29.12.2020 16:48:35  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
ist halt die frage ob das noch gechecksummed wird.
lesen darf ja gerne jeder den kernel/die initramfs, nur veränderungen sollten auffallen.
29.12.2020 20:16:23  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
statixx

AUP statixx 14.11.2023
Jo. Aber da hilft doch secure boot, nicht luks.
29.12.2020 20:52:58  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Dardrai

AUP Dardrai 03.02.2012
hmmm dafuq
Ich bin an meiner Bachelor Arbeit am arbeiten und muss ein Linux Distribution erstellen (ua) für den Raspberry Pi - also erstelle ich das Filesystem und debootstrap die Raspian version.

Jetzt habe ich aber "manchmal" ein Problem mit dem getty@ttyGS0.service - der sagt das Blockdevice exisitert nicht im /dev/ttyGS0 - also habe ich vor dem Service start noch ein mknod /dev/ttyGS0 c 4 1 hinzugefügt (erstellt das Blockdevice).

Man müsste denken alles gut und so - NOPE

Jetzt läuft das Script manchmal durch und "motzt" /dev/ttyGS0 existiert bereits -> Systemläuft ohne probleme (getty Service startet ohne Probleme etc) - Okay.jpg.

Manchmal sagt das Linux Script aber nichts - kein xxx existiert bereits etc - es sieht so aus, als würde er das device erstellen mit dem mknod. Später dann beim Boot und einer Kontrolle des getty@ttyGS0.service spuckt der Service die Meldung aus /dev/ttyGS0 does not exist -.-
Und natürlich nach einem mknod und restart vom getty Service läuft alles wieder. Aber wieso funktioniert es manchmal und manchmal nicht -.- es macht keinen Sinn traurig

Anyone has a tipp?

Was ich mache:
1. erstelle mit DD ein Image File (2GB)
2. Mounten auf die loop devices
3. Erstelle Boot (Fat) Partition + 2. Partition für das RootFS (läuft mit LVM)
4. Mounte die die Partitions (vom Loop Device) nach /mnt/rootfs und /mnt/rootfs/boot
5. Starte qemu-debootstrap --keyring=/etc/apt/trusted.gpg --arch armhf buster /mnt/rootfs http://archive.raspbian.org/raspbian
6. Mounte proc, sys, dev für chroot Enviroment + zugriff auf CHROOT mit ausführung eines weiteren scripts LC_ALL=C chroot /mnt/rootfs} ./setup.bash

im Setup.bash wird dann ua auch:
mknod /dev/ttyGS0 c 4 1
systemctl enable getty@ttyGS0.service

Ausgeführt
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Dardrai am 31.12.2020 11:48]
31.12.2020 11:36:14  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
KingGinord

kingginord
 
Zitat von hoschi

Hier.
Ich verwende GRUB, einfach weil ich es schon kenne und es alles wichtige unterstützt. Bei Laptops bevorzuge ich die Hardwareverschlüsselung der Festplatte, weil Hardwareveschlüsselung transparent für die Betriebssysteme ist. Ich spare mir damit die Konfiguration und vermeide Schwierigkeiten, weil es die Komplexität verringert.


https://i.imgur.com/sswfqTo.png

Den Bossgegner herausfordern Secure Boot.

Ich mache Secure Boot immer aus. Beim letzten ThinkPad war das erfreulicher Weise schon der Fall. Stattdessen habe ich zusätzlich ein BIOS Passwort, zusammen mit der Hardwareverschlüsselung sollte es mir ein relativ sicheres Leben ermöglichen ohne übermässig viel Aufwand.

Verwendet ihr Secure Boot?
Ich nehme an, die meisten werden ansonsten LUKS oder Hardwareverschlüsselung verwenden?




Als ich auf der Arbeit den Rechner neu bekommen habe, musste ich zum Admin laufen und ihn darum bitten Secure Boot auszumachen, da ich dafür das Admin PW brauchte.
Damit ich nicht bei jeder weiteren Änderung angeschissen kommen musste, hat er mir das zugeschoben (scheinbar sind nicht alle Mitarbeiter standardmäßig Herr ihres Arbeitsrechners).


Und ja ich nutze LUKS (kenn mich mit dem ganzen Kram aber nicht so gut aus), dahinter kommt allerdings, wenn ich dann doch mal Windows booten möchte, BitLocker.


Egal was gebootet wird, es dauert auf jeden Fall alles länger als auf anderen Rechnern, von anmachen bis zum decryt pw, von dort bis zum bootloader und von da bis zum os boot.
Ich installier nie wieder eine neueste (stable) OS version

// letzteres hat damit natürlich nicht viel zu tun, es hat dann aber nur nochmal zu den Problemen hinzugefügt, die man so als nicht ganz planvoller User so hat
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von KingGinord am 31.12.2020 15:40]
31.12.2020 15:39:26  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
 
Zitat von Dardrai

Ich bin an meiner Bachelor Arbeit am arbeiten und muss ein Linux Distribution erstellen (ua) für den Raspberry Pi - also erstelle ich das Filesystem und debootstrap die Raspian version.

Jetzt habe ich aber "manchmal" ein Problem mit dem getty@ttyGS0.service - der sagt das Blockdevice exisitert nicht im /dev/ttyGS0 - also habe ich vor dem Service start noch ein mknod /dev/ttyGS0 c 4 1 hinzugefügt (erstellt das Blockdevice).

Man müsste denken alles gut und so - NOPE

Jetzt läuft das Script manchmal durch und "motzt" /dev/ttyGS0 existiert bereits -> Systemläuft ohne probleme (getty Service startet ohne Probleme etc) - Okay.jpg.

Manchmal sagt das Linux Script aber nichts - kein xxx existiert bereits etc - es sieht so aus, als würde er das device erstellen mit dem mknod. Später dann beim Boot und einer Kontrolle des getty@ttyGS0.service spuckt der Service die Meldung aus /dev/ttyGS0 does not exist -.-
Und natürlich nach einem mknod und restart vom getty Service läuft alles wieder. Aber wieso funktioniert es manchmal und manchmal nicht -.- es macht keinen Sinn traurig

Anyone has a tipp?

Was ich mache:
1. erstelle mit DD ein Image File (2GB)
2. Mounten auf die loop devices
3. Erstelle Boot (Fat) Partition + 2. Partition für das RootFS (läuft mit LVM)
4. Mounte die die Partitions (vom Loop Device) nach /mnt/rootfs und /mnt/rootfs/boot
5. Starte qemu-debootstrap --keyring=/etc/apt/trusted.gpg --arch armhf buster /mnt/rootfs http://archive.raspbian.org/raspbian
6. Mounte proc, sys, dev für chroot Enviroment + zugriff auf CHROOT mit ausführung eines weiteren scripts LC_ALL=C chroot /mnt/rootfs} ./setup.bash

im Setup.bash wird dann ua auch:
mknod /dev/ttyGS0 c 4 1
systemctl enable getty@ttyGS0.service

Ausgeführt



hmmm, so auf die schnelle, ka?
nur um sicherzugehen
setup.bash mit
#!/bin/bash -ex
als shebang um mal zu schauen dass das wirklich sauber durchläuft?

bzw "einfach" mal binary-search mäßig durchhangeln?

d.h. das gleiche image bootet immer gleich (immer kaputt vs geht immer, sprich /dev/... ist _immer_ da oder nicht?)

usw...
31.12.2020 16:05:48  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[CSF]Omega

Arctic
 
Zitat von Dardrai

Ich bin an meiner Bachelor Arbeit am arbeiten und muss ein Linux Distribution erstellen (ua) für den Raspberry Pi - also erstelle ich das Filesystem und debootstrap die Raspian version.

Jetzt habe ich aber "manchmal" ein Problem mit dem getty@ttyGS0.service - der sagt das Blockdevice exisitert nicht im /dev/ttyGS0 - also habe ich vor dem Service start noch ein mknod /dev/ttyGS0 c 4 1 hinzugefügt (erstellt das Blockdevice).

Man müsste denken alles gut und so - NOPE

Jetzt läuft das Script manchmal durch und "motzt" /dev/ttyGS0 existiert bereits -> Systemläuft ohne probleme (getty Service startet ohne Probleme etc) - Okay.jpg.

Manchmal sagt das Linux Script aber nichts - kein xxx existiert bereits etc - es sieht so aus, als würde er das device erstellen mit dem mknod. Später dann beim Boot und einer Kontrolle des getty@ttyGS0.service spuckt der Service die Meldung aus /dev/ttyGS0 does not exist -.-
Und natürlich nach einem mknod und restart vom getty Service läuft alles wieder. Aber wieso funktioniert es manchmal und manchmal nicht -.- es macht keinen Sinn traurig

Anyone has a tipp?

Was ich mache:
1. erstelle mit DD ein Image File (2GB)
2. Mounten auf die loop devices
3. Erstelle Boot (Fat) Partition + 2. Partition für das RootFS (läuft mit LVM)
4. Mounte die die Partitions (vom Loop Device) nach /mnt/rootfs und /mnt/rootfs/boot
5. Starte qemu-debootstrap --keyring=/etc/apt/trusted.gpg --arch armhf buster /mnt/rootfs http://archive.raspbian.org/raspbian
6. Mounte proc, sys, dev für chroot Enviroment + zugriff auf CHROOT mit ausführung eines weiteren scripts LC_ALL=C chroot /mnt/rootfs} ./setup.bash

im Setup.bash wird dann ua auch:
mknod /dev/ttyGS0 c 4 1
systemctl enable getty@ttyGS0.service

Ausgeführt



Ohne jetzt Ahnung von Raspbian oder Raspberry zu haben: Kann es sein, dass /dev/ttyGS0 von irgendwelchen udev-Skripten (oder systemd) gelöscht und erstellt wird, abhängig davon, ob das USB-Kabel, über welches das Terminal übertragen wird, gerade verbunden oder abgesteckt ist?

Falls das der Fall ist, dann müsste man das Starten des getty-Services auch an dieser Stelle aufhängen, und den Service nicht einfach beim Systemstart starten.
31.12.2020 20:32:42  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
stimmt, ganz verdrängt.
/dev wird ja pro boot als devtmpfs gemounted und on the fly erstellt, wir haben ja 2020.
dann kann das gut ne race condition auch sein.
31.12.2020 21:52:19  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
Dardrai

AUP Dardrai 03.02.2012
Vielen Dank für den Input, was mich "verunsichert" ist, dass beim setup.bash script halt manchmal beim mknod die Meldung erscheint already exist und manchmal nicht. Auch komisch, wenn diese Meldung nicht erscheint erhalte ich bei systemctl status getty@ttyGS0.service foglenden Output:

getty@ttyGS0.service - Getty on ttyGS0
Loaded: loaded (/lib/systemd/system/getty@.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-02-14 10:12:44 UTC; 1 years 10 months ago
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Main PID: 684 (agetty)
Tasks: 1 (limit: 4915)
CGroup: /system.slice/system-getty.slice/getty@ttyGS0.service
└─684 /sbin/agetty -o -p -- \u --noclear ttyGS0 vt220

Feb 14 10:12:44 hostename systemd[1]: Started Getty on ttyGS0.
Feb 14 10:12:44 hostename agetty[684]: /dev/ttyGS0: cannot open as standard input: No such file or dir

Timestamps im Log können ignoriert werden - glaube ich - habe diese noch nicht eingestellt/konfiguriert etc, Log ist von gestern 31.12.2020 fröhlich

Wenn die Meldung already exist (oder so erscheint), erscheint auch keine agetty[684] Meldung :/

Lustig ist jedoch, dass alles USBgadget (removable USB Disk + USB Ethernet) etc funktionieren und ich via pi@hostname.local (und via Bonjour Service) auf den Pi connecten und arbeiten kann.

Also nächste Test:
#!/bin/bash -ex im setup Testen und schauen was passiert
Race condtions kontrollieren - gibt es da einen Tipp wie man am besten Forscht/Entscheided, wann/wo/wie der Service gestartet werden soll?

@[KdM]MrDeath Komisch ist zB. Ich kann am am 30.12 das Image 10 mal generieren und es erscheint immer File Exist und am 31.12 erhalte ich keine Meldung vom mknode bei jeder erzeugung des Images. Es kann aber auch vorkommen, dass 2 mal file exist kommt und dann wieder nicht - es ist einfach immer wieder anders und das "stresst" micht Breites Grinsen
Die restlichen /dev/ ist alles vorhanden so wie es sein soll und das Image bootet auch immer (sofern mein resize Script nicht wieder mal auf die "fresse" fliegt und ich dann div. LVM errors habe beim Booten (aka refusing to activate partial lvm) - das ist aber ein anderes Thema Breites Grinsen)

Ich habe mal die scripts auf Pastebin geladen:
CreateImage.bash - https://pastebin.com/8FHaX2d9
setupDistribution_chroot.bash - https://pastebin.com/3V48BkQB

Inputs Feedback sind gerne gesehen - natürlich sind diese Scripts noch nicht fertig und werden später noch mehr verbessert - aber aktuell funktioniert es schon relativ gut - bis halt diese ttyGS0 errors

Das ganze führe ich in einer Vagrant vm aus, sollte aber auf jedem Linux/WSL2 laufen, welches qemu qemu-user-static unterstützt - für die, welche das script evtl für sich verwenden wollen noch der Hinweis, aktuell darf das LVM nicht exportiert werden, da ansonsten der Pi nicht mehr booted, da dieser keinen import des LVM macht, wenn er gestartet wird.

/e An alle noch ein: "guets neus und gueti gsundheit"
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Dardrai am 01.01.2021 12:03]
01.01.2021 11:54:18  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
[KdM]MrDeath

mrdeath2
wenn man so sieht...


1. du lädst den key per http, bitte entweder per https oder ne andere methode suchen, das verschafft direkt mal nen dämpfer am anfang Augenzwinkern

2. zeile 77
 
Code:
 mount -o bind /dev ${ROOTFS}/dev

da mountest du /dev des hosts rein.
in der chroot fummelst du also in /dev vom host rum, wenn du die chroot schliesst und das image dann bootest ist das da nichtmehr mit drin.
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [KdM]MrDeath am 01.01.2021 12:13]
01.01.2021 12:12:55  Zum letzten Beitrag
[ zitieren ] [ pm ] [ diesen post melden ]
 Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... )
« erste « vorherige 1 ... 170 171 172 173 [174] 175 176 177 178 ... 215 nächste » letzte »

mods.de - Forum » Linux » 

Hop to:  

Thread-Tags:
gnu  linux 
| tech | impressum