[gelöst] /usr Partition verschieben

[TennerDent]

Das Forum sieht ganz anders aus ... Wie lange ich nicht mehr hier war. Naja, ist wohl ein gutes Zeichen, daß in der Zwischenzeit alles stabil lief. Aber nun brauche ich einen Rat:

Ich nutze mittlerweile Tumbleweed und stoße jetzt auf die Einschränkung, daß meine root-Partition langsam zu klein wird (20 GB reichen nicht mehr ...). Da ich auf der gleichen Platte spontan noch 40GB ungenutzten Platz entdeckt habe, wollte ich gerne /usr auf diesen ungenutzen Platz verschieben, weil es das größte Verzeichnis auf / ist.

Folgendes habe ich bislang gemacht:
* System von Rescue-CD gestartet
* im dem ungenutzten Platz mit GParted eine ext4-Partition erstellt und formatiert, sie heißt /dev/sdc4
* reboot ins "normale" System, X/KDE beendet und als root in der Konsole

# md /mnt/newusr
# mount /dev/sdc4 /mnt/newusr
# rsync -av /usr/ /mnt/newusr
# umount /mnt/newusr

ausgeführt, das hat ohne Fehler funktioniert
* an meine /etc/fstab folgende Zeile angehängt

/dev/sdc4		/usr		ext4		acl,user_xattr		1 2

* und das bisherige /usr in /usr1 umbenannt
* reboot

Damit startet jetzt noch GRUB und danach erhalte ich nur noch einen schwarzen Bildschirm. Glücklicherweise läßt sich alles relativ einfach rückgängig machen, nur die neue Partition nutzen kann ich halt noch nicht.

Wo liegt mein Fehler?

EDIT: Weil in anderen Foren dazu häufig gefragt wird, warum jemand denn /usr und nicht lieber /home verschieben will -> /home ist bei mir schon auf einer eigenen Platte. Und wenn ich statt /dev/sdc4 die UUID der Partition in fstab schreibe, startet das System auch nicht.

 

[marce]

Grundsätzlich sieht das Vorgehen gut aus, bei den Mount-Optionen bin ich mir nicht sicher, ob das passt / ausreicht.

Wie weit kommt das System denn? Startet nur X nicht? Konsole noch verfügbar? Was steht im boot-log?

 

[josef-wien]

rsync -av

Hast Du schon die wundersame Datenvermehrung festgestellt (die neue Partition hat durch die aufgelösten hardlinks viel mehr Daten als das alte /usr)?

Hast Du dafür gesorgt, daß die initrd die neue Partition kennt (bei openSUSE enthalten /bin und /sbin sehr viele Verknüpfungen nach /usr/bin bzw. /usr/sbin)?

Wenn Du snapper vernünftig konfigurierst, reichen 20 GB immer noch aus (siehe http://linux-club.de/wiki/opensuse/Tipp:_Snapper_entsch%C3%A4rfen und Beiträge hier im Forum).

 

[TennerDent]

Einmal der Reihe nach:

Wie weit kommt das System denn? Startet nur X nicht? Konsole noch verfügbar?

Gar nicht weit. Ich sehe für einen Sekundenbruchteil die ersten Meldungen von systemd beim booten, dann wird der Bildschirm schwarz.

Was steht im boot-log?

/var/log/boot.log enthält dazu überhaupt keine Angaben, sondern nur zum letzten "erfolgreichen" Bootvorgang.
Ich würde gerne schauen, was der Kernel dazu sagt, weiß aber nicht, wie ich dmesg von einem Kernel bekomme, der gar nicht geladen ist (Ich muß dazu ja von Rescue-CD starten)

Hast Du schon die wundersame Datenvermehrung festgestellt (die neue Partition hat durch die aufgelösten hardlinks viel mehr Daten als das alte /usr)?

Nein, erst jezt, aber danke und das würde ich auch gerne ändern ...

Hast Du dafür gesorgt, daß die initrd die neue Partition kennt

Interessante Idee. Wie sag ichs meiner initrd? mkinitrd laufen lassen und dann werden die Werte aus der fstab übernommen? Ich habe keine Ahnung ...

Wenn Du snapper vernünftig konfigurierst, reichen 20 GB immer noch aus

Läuft snapper überhaupt? Es existieren bei mir überhaupt keine Konfigurationen und ich nutze auch kein btrfs. Im Log steht auch nur immer wieder das:

2016-01-19 03:27:21 MIL libsnapper(10462) snapperd.cc(main):270 - Requesting DBus name
2016-01-19 03:27:21 MIL libsnapper(10462) snapperd.cc(main):274 - Loading snapper configs
2016-01-19 03:27:21 MIL libsnapper(10462) Snapper.cc(getConfigs):247 - Snapper get-configs
2016-01-19 03:27:21 MIL libsnapper(10462) Snapper.cc(getConfigs):248 - libsnapper version 0.2.9
2016-01-19 03:27:21 MIL libsnapper(10462) AsciiFile.cc(reload):114 - loading file /etc/sysconfig/snapper
2016-01-19 03:27:21 MIL libsnapper(10462) AsciiFile.cc(getValue):235 - key:SNAPPER_CONFIGS value:
2016-01-19 03:27:21 MIL libsnapper(10462) snapperd.cc(main):278 - Listening for method calls and signals
2016-01-19 03:27:21 WAR libsnapper(10462) Client.cc(dispatch):1458 - CAUGHT: unknown config
2016-01-19 03:29:28 MIL libsnapper(10462) snapperd.cc(main):282 - Exiting

 

[josef-wien]

Ich würde gerne schauen, was der Kernel dazu sagt

http://linux-club.de/wiki/opensuse/Systemd#Wo_sind_meine_Logs_hin.3F (Ich glaube aber nicht, daß das System soweit kommt, etwas zu protokollieren.)

das würde ich auch gerne ändern

Das steht in der manpage bei -a. Ich verwende grundsätzlich: -AHPSXavx

Wie sag ichs meiner initrd?

Diese Frage muß jemand beantworten, der openSUSE einsetzt. Ich vermute, in einem anderen System eine chroot-Umgebung aufbauen, dorthin wechseln, sicherstellen, daß dessen fstab paßt, mit dracut samt den entsprechenden Parametern eine neue initrd erstellen und hoffen, daß die Automatik alles wie gewünscht erledigt.

ich nutze auch kein btrfs

Wie schaffst Du es dann, die Systempartition vollzuschreiben? Was ergibt als root:

du -xh / | grep "[0-9],[0-9]G" | sort

Und noch sicherheitshalber:

cat /proc/mounts

Falls es /tmp betrifft: http://linux-club.de/wiki/opensuse/Tipp:_systemd-tmpfiles

 

[TennerDent]

Ich glaube aber nicht, daß das System soweit kommt, etwas zu protokollieren.

Stimmt, das macht es nicht. Unter journalctl --list-boots tauchen die fehlerhaften Bootvorgänge nicht auf. Genausowenig gibt es ein Kernelprotokoll dazu.

du und cat liefern folgende Ausgaben:

highlander:/ # du -xh / | grep "[0-9],[0-9]G" | sort

2,2G    /usr/src
3,3G    /usr/share
4,2G    /var/lib/systemd
4,2G    /var/lib/systemd/coredump
4,3G    /usr/lib64
4,4G    /var/lib
5,5G    /var

highlander:/ # cat /proc/mounts

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
devtmpfs /dev devtmpfs rw,nosuid,size=1017380k,nr_inodes=254345,mode=755 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/pids cgroup rw,nosuid,nodev,noexec,relatime,pids 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/perf_event cgroup rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/hugetlb cgroup rw,nosuid,nodev,noexec,relatime,hugetlb 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
/dev/sdc1 / ext4 rw,relatime,data=ordered 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
tmpfs /var/run tmpfs rw,nosuid,nodev,mode=755 0 0
/dev/sda1 /old/WD320GB ext4 rw,relatime,data=ordered 0 0
/dev/sdb1 /old/WD500GB ext4 rw,relatime,data=ordered 0 0
/dev/md0 /old/TOSHIBA3000GBEXTERN xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/sdd2 /old/SAMSUNG1780GB xfs rw,relatime,attr2,inode64,noquota 0 0
/dev/sde1 /home ext4 rw,relatime,data=ordered 0 0
/dev/sdc2 /tmp ext4 rw,relatime,data=ordered 0 0
/dev/sdc3 /old/SEAGATE1710GB xfs rw,relatime,attr2,inode64,noquota 0 0
tmpfs /run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=204820k,mode=700,uid=1000,gid=100 0 0
tmpfs /var/run/user/1000 tmpfs rw,nosuid,nodev,relatime,size=204820k,mode=700,uid=1000,gid=100 0 0
tracefs /sys/kernel/debug/tracing tracefs rw,relatime 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0
gvfsd-fuse /var/run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0

So wirklich gut läuft das ja irgendwie nicht. :/
Ich scheue mich davor, meine initrd zu zerlegen. Wahrscheinlich wäre eine Neuinstallation einfacher ...

 

[Anonymous]

Ich nutze mittlerweile Tumbleweed und stoße jetzt auf die Einschränkung, daß meine root-Partition langsam zu klein wird (20 GB reichen nicht mehr ...). Da ich auf der gleichen Platte spontan noch 40GB ungenutzten Platz entdeckt habe, wollte ich gerne /usr auf diesen ungenutzen Platz verschieben, weil es das größte Verzeichnis auf / ist.

Also, 20 GiB für / sind an sich groß genug. Wenn aber sehr viele Programme, Quellcode, Bibliotheken, … installiert sind und reger Gebrauch von /tmp gemacht wird, ist klar, dass es auf Dauer auch ohne snapshots eng wird.

Aber warum trägst Du die Kirche ums Dorf und richtest für ein laufendes System auf dem selben Datenträger extra eine /usr Partition ein?
Viel weniger Arbeit für den Menschen ist es, ungenutzten Speicherplatz hinter die vollgewordene / Partition zu schieben und sie dann einfach zu vergrößern.

Zumindest bei magnetischen Festplatten dauert das Umkopieren natürlich eine Weile.
Bei SSDs gibt es keine lineare Belegung. Theoretisch müssten auf einer SSD beim Verschieben einer Partition gar keine Dateisysteme umkopiert, sondern nur die Partitionsdaten geändert werden. Das wäre dann Sache des SSD-Controllers.

 

[josef-wien]

/usr/share und /usr/lib64 zeigen, daß bei Dir außerordentlich viele Programme installiert sind. Wozu /var/lib/systemd/coredump dient, entzieht sich meiner Kenntnis.

Wie sieht Deine Partitionierung aus? Von der Ausgabe von

fdisk -l

reichen vorerst sdc und die für /usr vorgesehene Platte.

Ich scheue mich davor, meine initrd zu zerlegen.

Du kannst Die alte ja vorher umbenennen, damit sie erhalten bleibt.

 

[drcux]

Du kannst nicht einfach /usr auf eine andere Partition verlegen, /usr wird schon zum booten gebraucht, siehe dir die Links von /bin /sbin etc. an.
Du musst deine initramfs anweisen /usr schon vor dem eigentlichen booten zu mounten. Wie das bei openSUSE geht, kann ich aber nicht sagen...


Edit: openSUSE nutzt dracut, dracut kennt das Modul 98usrmount

 

[TennerDent]

OK, es ist lange her, aber ich hab das Problem mehr oder weniger umgangen und zuletzt nach Booten von der Rescue-CD mittels GParted die /-Partition auf den ungenutzen Speicherplatz vergrößert. Das sollte erst einmal reichen. Es beantwortet zwar meine ursprüngliche Frage nicht, aber es funktioniert.

Vielen Dank!