Arch Linux

Falsche Partition wird als "Wurzelverzeichnis /" gemounten

twi

Hallo,

Ich habe einen "dual-boot" PC mit Arch Linux (sda1), Ubuntu(sdb1), Debian Lenny(sdc6mit grub als botloader) und Windows(sdc2).

Wenn ich Arch boote, kommt es sporatisch vor, dass zwar das richtige Image geladen wird (ich sehe auch links oben das Arch-Logo beim booten) ... jedoch wird im laufe des Boot-Vorganges dann /dev/sdb1 anstatt /dev/sda1 als / gemountet. Und das schlimme:
auf /dev/sdb1 befindet sich ein Ubuntu... und nun startet das Arch-Image den bootvorgang von Ubuntu.. dort passieren einige fehler.. und ich komme in eine shell als root. Wenn ich dort mount eingebe bekomme ich (in etwa):

root@towi04:/# mount
/dev/sdb1   ext3 on /
...usw...

Das komische dabei ist, dass dieses Problem besonders vorkommt, wenn ich meinen PC aus kaltem Zustand boote. (Fehler tritt jedoch nur beim Booten von Arch-Linux auf)

Mein bootloader (grub) ist auf /dev/sdc6 (debian) installiert.

Meine Festplattenkonfiguration sieht wie folgt aus:

arch-bez. steht für die partitions-bezeichnung unter arch
deb-bez. steht für die partitions-bezeichnung unter debian (lenny)
+-typ-+-arch-bez-+-deb-bez-+-FS-+-inhalt------+
| SATA| sda1	 | sda1    |ext3| Arch-Linux  |
| SATA| ...	 | ....    |... | Daten       |
| IDE | sdb1	 | hda1    |ext3| Ubuntu      |
| IDE | ...	 | ...     |... | ...         |
| IDE | sdc2	 | hdb2    |fat | Windows XP  |
| IDE | sdc5	 | hdb5    |swap|swap Deb&Arch|
| IDE | sdc6	 | hdb6    |ext3| Debian&grub |
+-----+----------+---------+----+-------------+

Meine /etc/fstab: (von arch linux)

# <file system>        <dir>         <type>    <options>          <dump> <pass>
none                   /dev/pts      devpts    defaults            0      0
none                   /dev/shm      tmpfs     defaults            0      0

#/dev/cdrom             /media/cd   auto    ro,user,noauto,unhide   0      0
#/dev/dvd               /media/dvd  auto    ro,user,noauto,unhide   0      0
#/dev/fd0               /media/fl   auto    user,noauto             0      0

UUID=265563ba-cb4d-4fc7-ad56-e8269e7d2fa7 swap swap defaults 0 0
#UUID=982b58c9-9100-4101-bcd4-1a6c37bc0a5c / ext3 defaults 0 1
/dev/sda1		 / 			ext3 defaults 0 1
/dev/sda2		/home/unterhaltung/     ext2 defaults 0 0
/dev/sdc6		/mnt/debian/	ext3	defaults 0 0
/dev/sdc3		/mnt/home/	reiserfs defaults 0 0

Ausschnitt aus der grub/menu.lst (grub ist auf der /dev/sdc6 debian lenny partiton!)

title Arch Linux
root (hd2,0)
kernel /boot/vmlinuz26 root=/dev/sda1 vga=795 ro
initrd /boot/kernel26.img
boot

und die grub/device.map:

(hd0)	/dev/hda
(hd1)	/dev/hdb
(hd2)	/dev/sda

Wenn ich unter arch ein ls -l /boot mache erhalte ich:

[thorsten@towi04 ~]$ ls -l /boot
insgesamt 7064
-rw-r--r-- 1 root root  807149 22. Feb 12:06 System.map26
drwxr-xr-x 2 root root    4096 28. Dez 20:26 grub
-rw-r--r-- 1 root root 3241416 25. Feb 21:44 kernel26-fallback.img
-rw-r--r-- 1 root root  675644 25. Feb 21:44 kernel26.img
-rw-r--r-- 1 root root  702024 24. Feb 19:12 kernel26.imgBU20090224
-rw-r--r-- 1 root root 1771344 22. Feb 12:06 vmlinuz26

Ich habe leider keine Ahnung, in welche Richtung ich suchen muss.. 🙁
Ich hoffe ihr habt einige Tipps für mich.!.

thorsten

DeJe

Da werden wohl immer mal deine Platten "umsortiert". 😉

Ich würde versuchen / über die UUIDs zu mounten, also "...root=/dev/disk/by-uuid/xxxxxxxx ...". Die uuids bekommst du über "ls -l /dev/disk/by-uuid/" raus.

twi

DeJe schrieb Da werden wohl immer mal deine Platten "umsortiert". 😉

Ja... ich weiß allerdings auch nicht wie ich verhindern kann, dass bei neueren Kerneln (bei Arch und Ubuntu) die IDE-Festplatten sdxX heißen :/...

Ich würde versuchen / über die UUIDs zu mounten, also "...root=/dev/disk/by-uuid/xxxxxxxx ...". Die uuids bekommst du über "ls -l /dev/disk/by-uuid/" raus.

In der fstab hatte ich das auch zuvor, (eben so, wie in der einen auskommentierten zeile über /dev/sda1..)

Aber wie kann ich in der grub/menu.lst die UUID der root-partition dem kernel übergeben ?
ich habe es damit versucht:

kernel /boot/vmlinuz26 root=UUID=982b58c9-9100-4101-bcd4-1a6c37bc0a5c vga=795 ro

Dadurch entsteht dann jedoch nur irgendein Kernel-Panic!

Übrigens:
Weshalb hab ich da eigentlich als parameter des kernels ro stehen ?(ich hab das so aus dem Wiki übernommen)
Wäre es nicht besser, ohne readonly zu booten ?... schließlich bin ich die ganze zeit am ruminstallieren.

Dirk

twi schrieb Aber wie kann ich in der grub/menu.lst die UUID der root-partition dem kernel übergeben ?
ich habe es damit versucht:
kernel /boot/vmlinuz26 root=UUID=982b58c9-9100-4101-bcd4-1a6c37bc0a5c vga=795 ro
Dadurch entsteht dann jedoch nur irgendein Kernel-Panic!

kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/982b58c9-9100-4101-bcd4-1a6c37bc0a5c vga=795 ro

Die Schreibrechte sind schon richtig so, der macht sich das im weiteren Bootprozess schon passend 😉

Aber ich an deiner Stelle würde überlegen, ob du die vga-Angabe nicht weg lässt. Wenn du nicht hauptsächlich an der Shell arbeitest, hat das keine Vorteile, und braucht nur unnötig zeit beim Booten – Und wenn du hauptsächlich an der Shell arbeitest wäre radeonfb (bzw. die Nvidia-Entsprechung) wohl besser, weil performanter.

twi

DeJe schrieb Ich würde versuchen / über die UUIDs zu mounten, also "...root=/dev/disk/by-uuid/xxxxxxxx ...". Die uuids bekommst du über "ls -l /dev/disk/by-uuid/" raus.

Dirk Sohler schrieb
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/982b58c9-9100-4101-bcd4-1a6c37bc0a5c vga=795 ro
Die Schreibrechte sind schon richtig so, der macht sich das im weiteren Bootprozess schon passend 😉

Aber ich an deiner Stelle würde überlegen, ob du die vga-Angabe nicht weg lässt. Wenn du nicht hauptsächlich an der Shell arbeitest, hat das keine Vorteile, und braucht nur unnötig zeit beim Booten – Und wenn du hauptsächlich an der Shell arbeitest wäre radeonfb (bzw. die Nvidia-Entsprechung) wohl besser, weil performanter.

Dankeschön! Jetzt funktioniert das booten per UUID : )
Ich hoffe mal, dass es beim nächsten Kaltstart morgen früh auch klappt !

zu vga=795:
Ich habe zum vergleich jetzt einmal mit und einmal ohne vga parameter gebootet
mit vga dauert der Bootvorgang zwischen Grub und login-manager(gdm) 25 sekunden
ohne vga parameter "nur" 23 sekunden..
Es macht bei mir also nicht so viel aus.
Ich arbeite nicht direkt an der Shell... bin eher GUI-verwöhnt 😉

Doch beim Thema gdm habe ich noch ein weiteres "problem":
Wenn ich aus dem Gdm Menü (Aktionen->Herunterfahren) den pc herunterfahre,
dann kommt bei mir die zeile:

Stopping GDM ...                     [ FAIL ]

Und ettliche Zeilen später (erst nach Stopping alsa .. usw.)
Wird erneut vergeblich versucht, gdm zu stoppen:

Stopping GDM ...                     [ FAIL ]

Wenn ich jedoch in einer shell zuerst gdm starte und dann einen shutdown per hand mache, dann funktioniert alles wunderbar:

[root@towi04]: /etc/rc.d/gdm stop
Stopping GDM ...                     [ DONE ]
[root@towi04]: shutdown -r now

Wie bringe ich jetzt gdm dazu, sich selbst beim herunterfahren richtig zu beenden ?

Dirk

twi schrieb Ich habe zum vergleich jetzt einmal mit und einmal ohne vga parameter gebootet
mit vga dauert der Bootvorgang zwischen Grub und login-manager(gdm) 25 sekunden
ohne vga parameter "nur" 23 sekunden..
Es macht bei mir also nicht so viel aus.

Bei einer gesamt-Bootzeit von (bei mir) 15 Sekunden bis benutzbar machen 2 Sekunden eine ganze Menge aus. Die Kernel-Meldungen beim Booten kannst du dir auch schenken (bei Fehlern wird sich das System schon bemerkbar machen, bzw. gar nichts mehr machen – die anderen Meldungen haben allenfalls informierenden Charakter), einfach quiet an die Kernel-Zeile hängen. Spart auch noch mal etwas Bootzeit.

Tipp dazu: http://wiki.archlinux.de/title/Bootchart

twi schrieb Wie bringe ich jetzt gdm dazu, sich selbst beim herunterfahren richtig zu beenden ?

Auch hier wieder die Frage: Brauchst du GDM zwangsweise? Tut es der Login auf der Shell mit dem Autostart-Tipp von hier nicht genau so?

Ansonsten GDM vielleicht einfach über die inittab starten, anstatt als Daemon? (Ist eh besser.)

http://wiki.archlinux.de/title/Login-Manager#per_inittab

twi

Dirk Sohler schrieb Auch hier wieder die Frage: Brauchst du GDM zwangsweise? Tut es der Login auf der Shell mit dem Autostart-Tipp von hier nicht genau so?

Ansonsten GDM vielleicht einfach über die inittab starten, anstatt als Daemon? (Ist eh besser.)

http://wiki.archlinux.de/title/Login-Manager#per_inittab

also wenn ich gdm per inittab starte, dann fuehlt es sich noch laenger an als zuvor.. (und irgendwelche Warnmeldungen kommen noch dazu)
ich habe jetzt gdm komplett entfernt und starte x jetzt per .bash_profile
Ich hatte gdm benutzt, damit ich vor dem Einloggen die Sitzungsart/den Fenstermanager auswählen konnte. Gibt es eine Moeglichkeit die Sitzungsart beim Verwenden von startx irgendwie auszuwählen?
(Abgesehen von ständigem Editieren der .xinitrc oder parametrieren von startx ?)

Dirk Sohler schrieb Bei einer gesamt-Bootzeit von (bei mir) 15 Sekunden bis benutzbar machen 2 Sekunden eine ganze Menge aus. Die Kernel-Meldungen beim Booten kannst du dir auch schenken (bei Fehlern wird sich das System schon bemerkbar machen, bzw. gar nichts mehr machen – die anderen Meldungen haben allenfalls informierenden Charakter), einfach quiet an die Kernel-Zeile hängen. Spart auch noch mal etwas Bootzeit.

Tipp dazu: http://wiki.archlinux.de/title/Bootchart

Das mit dem quiet ist wunderbar ! 🙂 Die Meldungen am Anfang lese ich sowieso nicht.
(Bin trotzdem noch bei 21 Sekunden Bootzeit)
Ich habe die Bootchart einfach mal an diesen Post angehängt.
Gibt es darin irgendeinen Prozess, den ich mir Sparen könnte ?

Dirk

twi schrieb Gibt es darin irgendeinen Prozess, den ich mir Sparen könnte ?

Lade die Daemons im Hintergrund (einfach im DAEMONS-Array in der rc.conf ein @ vor den jeweiligen Daemon setzen).

Bei mir sieht das so aus:

DAEMONS=(@syslog-ng network @acpid @crond @sshd hal fam @netfs @ntpd)

network, hal und fam brauchen sich ja irgendwie (nein, ich werde NICHT Gamin verwenden, da startet bei mir netfs nicht mehr, wenn ich das mache), daher sind die nicht im Hintergrund, der Rest kann getrost „weg“. Sonst würde der Startprozess jeweils so lange warten, bis der Daemon sich meldet, und sagt, dass er fertig ist. Da von den Daemons aber normaler weise nichts weiteres abhängt, und die Dinger eh so schnell starten, dass sie laufen, wenn man sich einloggt, kann der startprozess ja auch ruhig nebenbei schon weitergehen.

Das bringt auch noch mal ein, zwei Sekunden, wenn dein System da sehr hängt.

Netzwerk natürlich NICHT per DHCP, was dauert, sondern fest eingestellt und im Hintergrund, wenn du keine NFS-Shares gemountet hast.

Hab mal ne ältere bootchart von mir angehängt 😉

twi

Gut! dankeschön : )
Ich habe jetzt einige Daemons im Hintergrund starten lassen:

DAEMONS=(@syslog-ng network @crond hal @alsa)

Ich brauche kein dhcp, ich habe eine statische IP
ich brauche zwar immernoch 21 sekunden... aber ich denke das ist okey ; )
Das einzige, was mich irritiert, ist, dass bei mir in der Bootchart bootchartd zweimal zu sehen ist. Bei dir jedoch nur einmal!
(da ich jedoch standardmäßig ohne Bootchart hochfahre, kann ich das denk ich vernachlässigen)

Der Vorteil von gdm war, dass ich dank gdm-control auch aus der Sitzung heraus den PC neu starten konnte. Das funktioniert seit gerade eben dank sudo und einem bash-skript wunderbar!

Noch ein Nachtrag zum eigentlich Thema:
Jetzt hat Arch die bezeichnungen der Festplatten völlig durcheinandergeworfen :-0
noch heute morgen war
die SATA-Platte: /dev/sda
und die IDE-Platten: /dev/sdb und /dev/sdc/
Doch jetzt (habe ein update gemacht) ist
die SATA-Platte /dev/sdc
und die IDE-Platten: /dev/sda und /dev/sdb

Deshalb musste ich in meiner /etc/fstab alle Partitionen per UUIDs mounten lassen : (

Dirk

twi schrieb Ich habe jetzt einige Daemons im Hintergrund starten lassen:

network und hal kannst du auch noch in den Hintergrund setzen, da hängt nichts von ab, bei deiner jetzigen Konfiguration.

twi schrieb Das einzige, was mich irritiert, ist, dass bei mir in der Bootchart bootchartd zweimal zu sehen ist.

Bei dir wird auch ein zweiter init-Prozess gestartet, der aber nur kurz läuft. Vielleicht einfach nur ein Darstellungsfehler von Bootchart, kommt vor. Einfach noch mal laufen lassen. Sollte eigentlich nicht vorkommen, dass da zwei Init-Prozesse gestartet werden, wenn du dich an die Bootchart-Anleitung aus dem Wiki hältst, sollte eigentlich nichts schiefgehen.

twi schrieb Der Vorteil von gdm war, dass ich dank gdm-control auch aus der Sitzung heraus den PC neu starten konnte. Das funktioniert seit gerade eben dank sudo und einem bash-skript wunderbar!

Alternativ über DBUS.

dbus-send --system --print-reply --dest="org.freedesktop.Hal" /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Shutdown

Wenn DBUS installiert und konfiguriert ist, und der User die nötigen Rechte hat (iirc muss er dazu in der power-Gruppe sein), kann er das System so ohne Umweg über sudo, etc. runterfahren. Und da du HAL schon verwendest, und dieser DBUS automatisch mitstartet, musst du dem User nur die entsprechenden Rechte einräumen.

twi schrieb Jetzt hat Arch die bezeichnungen der Festplatten völlig durcheinandergeworfen :-0

Ignorieren, du kannst es (ohne unverhältnismäßig großen Aufwand) sowieso nicht beeinflussen 😉

twi schrieb Deshalb musste ich in meiner /etc/fstab alle Partitionen per UUIDs mounten lassen : (

Sehe ich nicht als Nachteil.

twi

Dirk Sohler schrieb network und hal kannst du auch noch in den Hintergrund setzen, da hängt nichts von ab, bei deiner jetzigen Konfiguration.

Okey hab ich gemacht. Bin jetzt bei 19 Sekunden Bootzeit.

Dirk Sohler schrieb
twi schrieb Das einzige, was mich irritiert, ist, dass bei mir in der Bootchart bootchartd zweimal zu sehen ist.
Bei dir wird auch ein zweiter init-Prozess gestartet, der aber nur kurz läuft. Vielleicht einfach nur ein Darstellungsfehler von Bootchart, kommt vor. Einfach noch mal laufen lassen. Sollte eigentlich nicht vorkommen, dass da zwei Init-Prozesse gestartet werden, wenn du dich an die Bootchart-Anleitung aus dem Wiki hältst, sollte eigentlich nichts schiefgehen.

Komisch. Mal ist bootchartd 2mal da.. manchmal nur einmal.
Mit den zwei init-Prozessen hoffe ich einfahc mal auf einen Darstellungsfehler (Bei allen Bootcharts, die ich bisher gesehen habe waren bisher 2 inits)

Das mit per dbus - Herunterfahren habe ich mir mal in nem kleine Skript gespeichert und werde es, später mal ausprobieren.

Dirk Sohler schrieb
twi schrieb Deshalb musste ich in meiner /etc/fstab alle Partitionen per UUIDs mounten lassen : (
Sehe ich nicht als Nachteil.

Dadurch geht - finde ich - ein ziemliches Stück Einfachheit verloren:
Früher, als die Festplatten-Partitionen hdxY und die Usb-/Flashdisk-Sachen sdxY waren, sah die fstab richtig einfach & intuitiv zu verstehen. (Und die fstab hat in vi auf die Standard-Konsolenbreite - also ohne vga-parameter - gepasst! Durch die UUID wird die Zeile viel zu lang, und der Tabellen-Look wird zerstört)
Aber, wie man sieht: Geschmackssache 😉

Dirk

twi schrieb Früher, als die Festplatten-Partitionen hdxY und die Usb-/Flashdisk-Sachen sdxY waren, sah die fstab richtig einfach & intuitiv zu verstehen. (Und die fstab hat in vi auf die Standard-Konsolenbreite - also ohne vga-parameter - gepasst! Durch die UUID wird die Zeile viel zu lang, und der Tabellen-Look wird zerstört)

Na ja, was ist denn daran heute anders?

# VIRTUAL
# <fs>   <mp>       <ty>     <op>      <d p>
none     /dev/pts   devpts   defaults   0 0
none     /dev/shm   tmpfs    defaults   0 0

# REMOVABLE
# <fs>       <mp>           <ty>  <op>                    <d p>
/dev/cdrom   /media/cdrom   auto   ro,user,noauto,unhide   0 0
/dev/dvd     /media/dvd     auto   ro,user,noauto,unhide   0 0

# FIXED
# <fs>                                      <mp>    <ty>   <op>      <d p>
UUID=287a4bb7-d90e-4d81-9308-382867f55eb5   swap    swap   defaults   0 0
UUID=609cf1b0-3009-4075-9349-1df0d3b50ba9   /       ext3   defaults   0 1
UUID=acf2cd86-7ad3-41ac-9e7f-aa9439136e23   /home   ext3   defaults   0 1

An der breitesten Stelle 74 Zeichen. Und wenn dir das rumhantieren mit UUIDs zu umständlich ist, im Wiki-Artikel zum Thema Mounten im fstab-Abschnitt ist auch beschrieben, wie man Partitionen mit Labels versehen kann (diese sind ebenfalls unabhängig vom Device-Node), statt mit UUID=… zu mounten, benutzt du dann eben LABEL=… zum mounten, geht genau so, und ist noch kürzer.

In der menu.lst von Grub kannst du dann als root-Angabe /dev/disk/by-label/… verwenden.

bernarcher

Nur als Ergänzung:
Die UUIDs werden beim ersten Einrichten der Laufwerke vergeben. Welche auf dem System gerade bekannt sind, erfährst du mit.

ls -lF /dev/disk/by-uuid/

Hier zum Beispiel ergibt das

lrwxrwxrwx 1 root root 10  8. Mär 18:07 114b95bf-30b6-4953-8158-28ee150c0c4c -> ../../sdb2
lrwxrwxrwx 1 root root 10  8. Mär 18:07 6c164f7e-93f8-4d04-ae08-eed42ecd9197 -> ../../sda1
lrwxrwxrwx 1 root root 10  8. Mär 18:07 a077f168-44b7-4efc-95a1-727e22f67e7f -> ../../sdb3
lrwxrwxrwx 1 root root 10  8. Mär 18:07 b1cba4fa-df6b-4308-816e-e4868dbf3d51 -> ../../sdb4
lrwxrwxrwx 1 root root 10  8. Mär 18:07 e0439e35-f730-4710-b3d9-cfcb3dba08f5 -> ../../sda3

Also alles eigentlich kein Problem, oder?

Dirk

bernarcher schrieb Die UUIDs werden beim ersten Einrichten der Laufwerke vergeben. Welche auf dem System gerade bekannt sind, erfährst du mit.
ls -lF /dev/disk/by-uuid/

Jo, oder mit dem Tool blkid.

Außerdem sind die Angaben in /dev/disk/by-uuid nicht statisch einmalig gesetzt, sondern werden bei jedem Systemstart neu ermittelt, die UUID wird beim generieren des Dateisystems in eben dieses geschrieben, und beim Booten ausgelesen. Deswegen ist die UUID auch immer diesem Dateisystem zuzuordnen, egal, wo du die Platte ranklemmst, oder wie der Kernel sie einliest.

bernarcher

Richtig!
Beachte dabei: Die UUIDs ändern sich auch, sobald man die betreffende Partition ändert (z.B. mit gparted verkleinert). Dann müssen in der Regel auch menu.lst und fstab angepasst werden. (Hat mich mal Schweißperlen treibende Stunden gekostet 🙁 )

Dirk

bernarcher schrieb Die UUIDs ändern sich auch, sobald man die betreffende Partition ändert (z.B. mit gparted verkleinert).

Ja, natürlich tun sie das! UUID und Dateisystem gehören nun mal zusammen. Wenn man das Dateisystem ändert, bekommt es natürlich eine andere UUID, da es sich nach der Änderung um ein anderes Dateisystem handelt.

Wenn man sich da einmischen will, kann man dies aber natürlich (vgl. man tune2fs, dort vor allem der Parameter -U) – Man muss sich nur vorher die UUID notieren 😉

Genereller Hinweis: Vor jeglichen Arbeiten an Partitionen und dem Dateisystem immer ein Backup auf einer anderen Platte, oder zumindest auf einem anderen Dateisystem machen!

Sodom

Guten Tag,

ich bin vor einigen Wochen auf x86_64 umgestiegen und habe seitdem folgendes Problem: Der Kernel (oder udev?) weist Partitionen unterschiedlicher Festplatten beim Booten unterschiedliche Devicenamen zu. Ich hab /dev/sda und /dev/sdb und seit ich Anfang 2002 mit Linux anfing, war die erste Platte auch immer sda und die zweite sdb (oder hda, was aber vollkommen egal ist).
Gut, vorläufig, damit der Bootvorgang durchläuft, habe ich in der /etc/fstab die devicenamen durch die mittels blkid ermittelte UUID ersetzt - aber damit kommt schon das nächste problem: ein script mountet mittels truecrypt mein /home, so daß ich nur noch mit der Passwort-Abfrage belästigt werde, aber truecrypt erkennt die UUID der verschlüsselten Partition irgendwie nicht. Ergo: in nicht reproduzierbaren Abständen geht das mounten schief, weil sda1 auf einmal sdb1 und schon als / eingehängt ist und/oder umgekehrt.

Naja, kann man diesen UUID-Mist nicht einfach abstellen?

Danke!

bernarcher schrieb Dadurch geht - finde ich - ein ziemliches Stück Einfachheit verloren:
Früher, als die Festplatten-Partitionen hdxY und die Usb-/Flashdisk-Sachen sdxY waren, sah die fstab richtig einfach & intuitiv zu verstehen. (Und die fstab hat in vi auf die Standard-Konsolenbreite - also ohne vga-parameter - gepasst! Durch die UUID wird die Zeile viel zu lang, und der Tabellen-Look wird zerstört)
Aber, wie man sieht: Geschmackssache 😉

Sehe ich genauso. Ein Blick in die fstab reicht nicht mehr. Und ich rede jetzt nicht von 2 Partitionen ... Nervtötend dieses Geraffel.

Dirk

Sodom schrieb
bernarcher schrieb Früher, als die Festplatten-Partitionen hdxY und die Usb-/Flashdisk-Sachen sdxY waren, sah die fstab richtig einfach & intuitiv zu verstehen. (Und die fstab hat in vi auf die Standard-Konsolenbreite - also ohne vga-parameter - gepasst! Durch die UUID wird die Zeile viel zu lang, und der Tabellen-Look wird zerstört)
Sehe ich genauso. Ein Blick in die fstab reicht nicht mehr. Und ich rede jetzt nicht von 2 Partitionen ... Nervtötend dieses Geraffel.

man e2label

koch

lustig, hab ich grade vor 2 minten zugemacht. du weisst ja warum.

Sodom

Dirk Sohler schrieb
man e2label

Hallo nochmal.
Danke erstmal für den Tipp. Ich habe mich mit der ganzen Geschichte jetzt "angefreundet". Mein Problem mit der truecrypt-Partition ist allerdings nicht behoben: Nach

e2label /dev/disk/by-uuid/{truecrypt-uuid} /dev/home

kann ich zwar /dev/home mounten, aber nach dem nächsten Reboot ist das manuell erstellte label wieder weg.
Nach einem Reboot zeigt mir

ls -lh /dev/disk/by-uuid/

alle Partitionen an, aber nicht die truecrypt-Partition. Diese erscheint in /dev/disk/by-uuid/ erst nach manuellem Mounten über /dev/sd{a,b}1 als link auf ../../dev/mapper/truecrypt1.
Hat irgendjemand einen Tip?

Gruß

Nächste Seite »