• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] /usr Partition verschieben

T

TennerDent

Newbie
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
Code: 
# 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
Code: 
/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.
 
M

marce

Guru
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?
 
J

josef-wien

Ultimate Guru
TennerDent schrieb:
rsync -av
Zum Vergrößern anklicken....
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).
 
OP
T

TennerDent

Newbie
Einmal der Reihe nach:

Wie weit kommt das System denn? Startet nur X nicht? Konsole noch verfügbar?
Zum Vergrößern anklicken....
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?
Zum Vergrößern anklicken....
/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)?
Zum Vergrößern anklicken....
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
Zum Vergrößern anklicken....
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
Zum Vergrößern anklicken....
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:
Code: 
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
 
J

josef-wien

Ultimate Guru
TennerDent schrieb:
Ich würde gerne schauen, was der Kernel dazu sagt
Zum Vergrößern anklicken....
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.)

TennerDent schrieb:
das würde ich auch gerne ändern
Zum Vergrößern anklicken....
Das steht in der manpage bei -a. Ich verwende grundsätzlich: -AHPSXavx

TennerDent schrieb:
Wie sag ichs meiner initrd?
Zum Vergrößern anklicken....
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.

TennerDent schrieb:
ich nutze auch kein btrfs
Zum Vergrößern anklicken....
Wie schaffst Du es dann, die Systempartition vollzuschreiben? Was ergibt als root:
Code: 
du -xh / | grep "[0-9],[0-9]G" | sort
Und noch sicherheitshalber:
Code: 
cat /proc/mounts
Falls es /tmp betrifft: http://linux-club.de/wiki/opensuse/Tipp:_systemd-tmpfiles
 
OP
T

TennerDent

Newbie
josef-wien schrieb:
Ich glaube aber nicht, daß das System soweit kommt, etwas zu protokollieren.
Zum Vergrößern anklicken....
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:
Code: 
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

Code: 
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 ...
 
A

Anonymous

Gast
TennerDent schrieb:
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.
Zum Vergrößern anklicken....
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.
 
J

josef-wien

Ultimate Guru
/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
Code: 
fdisk -l
reichen vorerst sdc und die für /usr vorgesehene Platte.

TennerDent schrieb:
Ich scheue mich davor, meine initrd zu zerlegen.
Zum Vergrößern anklicken....
Du kannst Die alte ja vorher umbenennen, damit sie erhalten bleibt.
 
D

drcux

Hacker
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
 
OP
T

TennerDent

Newbie
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! :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben