ext2 für /boot zu alt?

[rhHeini]

Weil das über ladbare Module gemacht wird.

Und wenn man die nicht läd ...

Ich weiss das weil ich selber mal nicht aufgepasst und den Fehler gemacht habe den Menupunkt zu überspringen.

[Livingston]

Ein Anwendungsfall, warum man ext2 heute noch benötigt, steht hier bei mir zuhause. Beim Debianisieren meines NAS aus dem Jahr 2012 lässt sich der uboot-Loader nicht austauschen (kein serieller Anschluss), und der verlangt auf einer bestimmten Partition ext2 mit einer Inode-size von 128 (mke2fs -I 128 -t ext2) für das Verzeichnis /boot. Das ist also quasi fest verdrahtet.
Ich könnte ganz bösartig den Lötkolben schwingen und zwei Drähte als seriellen Anschluss reinfummeln, aber das Risiko, da was zu verhunzen, ist mir zu groß. Für die Restlaufzeit des Gerätes bleibt's also, wie es ist.

[slandail]

Wasserstandsmeldung:
angeheizt durch eure Beiträge habe ich gestern von einer aktuellen 12.05 netinst.iso neu installiert, als lvm mit luks mit extra /home und was wurde beim partitionieren angeboten: ext2 für /root --> edit: /boot

[MSfree]

...und was wurde beim partitionieren angeboten: ext2 für /root

Das glaube ich dir nicht.

/root ist nämlich das Homeverzeichnis des Benutzers root und das liegt nicht auf einer eigenen Partition.

[reox]

Wasserstandsmeldung:
angeheizt durch eure Beiträge habe ich gestern von einer aktuellen 12.05 netinst.iso neu installiert, als lvm mit luks mit extra /home und was wurde beim partitionieren angeboten: ext2 für /root --> edit: /boot

Ahja, tatsächlich:

[slandail]

... womit ich wieder am Anfang meiner Frage stehe...

[rhHeini]

Und das bei Guided Partitioning?

[cosinus]

... womit ich wieder am Anfang meiner Frage stehe...

Man kann's auch echt übertreiben mit dem durchlabern von Themen. Künftig kein ext2 mehr nehmen, fertig.

[schorsch_76]

ext2 für Boot hat den Vorteil das es kein journal hat. Es ist ziemlich einfach zu lesen und wird von auch sehr alten Bootloadern unterstützt. Uboot, Lilo, loadlin etc. Da bei der Partitionierung noch nicht 100% feststeht welcher Bootloader verwendet wird, nimmt man ext2 da es von praktisch allen Loader gelesen werden kann. Danach übernimmt ja der Kernel.

[Livingston]

Bug-Report schreiben, kann helfen. Ist zwar mit einem Handgriff zu klären, aber in zukünftigen Installern kann das ja mal sauber auf Linie gezogen werden.

[ernohl]

Ich sehe auch keinen Grund, für jedes quasi statische Filesystem (wie /boot) nicht ext2 zu nehmen. Jedes zusätzliche feature (auch wenn es nicht benötigt/genutzt wird) ist eine potentielle Fehlerquelle.

[cosinus]

Ich sehe auch keinen Grund, für jedes quasi statische Filesystem (wie /boot) nicht ext2 zu nehmen. Jedes zusätzliche feature (auch wenn es nicht benötigt/genutzt wird) ist eine potentielle Fehlerquelle.

Warum nicht gleich FAT16...ist noch einfacher als ext2 und wieder potentielle Fehlerquellen vermieden.

[rhHeini]

... womit ich wieder am Anfang meiner Frage stehe...

Die 12.5 netinstall in einer Legacy-VM installiert mit geführter Verschlüsselung: die angelegt GPT wird durch eine MBR-Partitionierung überschrieben, eine /boot mit ext2 angelegt, / im LVM mit ext4. Swap hat gerade 1 GByte. Ich hätte 4G spendiert. Da haben wir den Salat.

Meine Meinung dazu: Der Installer mit seinen Automatismen gehört für mich irgendwie vernünftig angepasst. Oft zu kleine Partitionen, swap zu knapp, veraltete Filesysteme. Ich würd auf heutigen Computern kein ext2 mehr verwenden, nur noch ext4. Warum auf das Journal verzichten? Es funktioniert.

Ich mache seit Jahren nur noch Installationen im Expert-Modus mit manueller Partitionierung. Dabei lege ich in der Regel mit einem gparted-Live die Partitionstabelle an (heutzutage in der Regel nur noch GPT), und partitioniere nach meiner Erfahrung relativ großzügig, so daß ich nicht in die Klemme mit zu kleinen Partitionen komme, und ich vermeide auch inzwischen das Auslagern von var/tmp was man früher gerne gemacht hat ... Ausnahme ist immer /home auf einer eigenen Platte (nicht in einer VM).

[slandail]

Vielen Dank für die hier geschriebene Hilfe und Einschätzungen.

[reox]

Dennoch bleibt die Frage, wieso der Installer grundsätzlich ext4 nimmt aber genau für das guided crypt setup dann auf ext2 zurückgeht. In den Bugreports finde ich nichts was darauf hindeutet: https://bugs.debian.org/cgi-bin/pkgrepo ... debian.org
Also entweder hat sich das noch keiner gefragt oder es ist so gewollt.

Ich hab in partman-crypto geschaut und dort finde ich das: https://salsa.debian.org/installer-team ... ems/crypto
Ob es tatsächlich das Script ist was dann boot auf ext2 setzt weiß ich nicht, aber dort steht

Veto filesystems unsuitable for certain crypto setups

Möglicherweise ist das der Grund warum dort boot auf ext2 gesetzt wird? (Das Script wurde zuletzt vor 16 Jahren geändert - evt ist das auch einfach nur outdated)

[cosinus]

Meine Meinung dazu: Der Installer mit seinen Automatismen gehört für mich irgendwie vernünftig angepasst. Oft zu kleine Partitionen, swap zu knapp, veraltete Filesysteme. Ich würd auf heutigen Computern kein ext2 mehr verwenden, nur noch ext4. Warum auf das Journal verzichten? Es funktioniert.

Solche Automatismen finde ich grundsätzlich nicht sinnvoll. Wie du schon sagst sind die vorgeschlagenen Partitionsgrößen oft unsinnig, Laien ist damit nicht wirklich geholfen, es sei denn man setzt auf ein Minimalpartitionsschema, also nur die ESP und Rootpartition.

[cosinus]

Dennoch bleibt die Frage, wieso der Installer grundsätzlich ext4 nimmt aber genau für das guided crypt setup dann auf ext2 zurückgeht.

Ich hab hier in einer VM mal etwas herumgespielt mit der Partitionierung. Zum EInsatz kam das aktuelle ISO-File von Debian testing. Hab dort manuell partitioniert, eine ESP (FAT32) und eine Partition für /boot angelegt mit ext4. Die dritte Partition dann als Crypto-Device. Wenn ich dann auf das verschlüsselte Volume ganz oben gehe um dort Partitionen anzulegen, hab ich keine Möglichkeit ext4 zu wählen! (LVM geht natürlich und dann innerhalb des LVM-Containers gehen auch wieder ext4-Volumes)

[reox]

Wenn ich dann auf das verschlüsselte Volume ganz oben gehe um dort Partitionen anzulegen, hab ich keine Möglichkeit ext4 zu wählen!

Ich rate hier nur, aber meine Vermutung ist, dass dieses Script etwas anderes als ext2 unterbindet:

Ich hab in Debianpartman-crypto geschaut und dort finde ich das: https://salsa.debian.org/installer-team ... ems/crypto

Verlinkt ist da übrigens dieser Bug: https://bugs.debian.org/cgi-bin/bugrepo ... bug=414638
Offenbar ist das schon lange obsolet aber hat sich wohl nie jemand darum gekümmert das wieder zu entfernen.

[ernohl]

Warum nicht gleich FAT16...ist noch einfacher als ext2 und wieder potentielle Fehlerquellen vermieden.

Wie wäre es mit einem belastbaren Argument?

[cosinus]

Wie wäre es mit einem belastbaren Argument?

Wozu? Anhand meines Smilies sollte man erkennen, dass das nicht ganz ernst gemeint war

[mampfi]

Und Gedächtnistest für mich: Kam vor FAT16 nicht FAT12?

Kommando zurück: das WWW antwortet

[cosinus]

Und Gedächtnistest für mich: Kam vor FAT16 nicht FAT12?

Kommando zurück: das WWW antwortet

Ja. FAT16 war das Standarddateisystem von DOS bis hin zur Urversion von Windows 95. Ab Windows 95 Version B konnte man auch FAT32 nutzen siehe https://de.wikipedia.org/wiki/Microsoft ... #Versionen

[Livingston]

Und 12 Bit für Disketten.

[cosinus]

Und 12 Bit für Disketten.

Richtig, FAT12 für Disketten, aber das konnte man unter DOS eh nicht beeinflussen. Oder ging das doch irgendwie?

[Livingston]

Bei Disketten war das auf 12 Bit festgenagelt. Bei Platten hing es von der Partitionsgröße ab. Ab 32 MB wurde FAT32, darunter FAT16 verwendet.
In dem Dateisystem wurden die Sektoren der Disk/Platte von 0 bis Ende durchnummeriert, und in die jeweils 12, 16 oder 32 Bit großen Einträge in der FAT (File Allocation Table) wurden dann die Nummern des jeweils folgenden Sektors eingetragen. Der letzte Sektor war dann hexadezimal mit 0xFFF, 0xFFFF oder 0xFFFFFFFF gekennzeichnet. Leere Sektoren bekamen die Kennzeichnung 0.
Jede Datei bekam also eine Kette von Belegungen um die Ohren. Schön einfach, aber wenn man mal was vom Ende einer Datei lesen wollte, musste sich das Betriebssystem erst durch alle vorhergehenden Sektoren hangeln.
Dauert natürlich zu lange, und deshalb nutzen ext und andere baumartige Strukturen, um schneller zum Ziel zu kommen.
So, Ende der Geschichtsstunde.