Freien Speicher auf andere Partition schieben ubuntu server

[Schnabulator1337]

Hey,
ich habe eine Kiste in meinem Netzwerk mit Ubuntu Server laufen.
Aus mir mittlerweile unbekannten Gründen habe ich es für sinnvoll gehalten eine 10GB Partition für boot einzurichten..
Dieser Speicher fehlt mir jetzt in meiner Root partition.
Ich würde die boot partition gerne auf ~1GB runtersetzen und den Speicher dafür an boot ranhängen.
Outputs von folgenden commands hängen an:
`lsblk`:
`df`:
`du -h --max-depth=1`:

Mit parted kann ich keine partition verschieben, wobei ich da auch Angst habe meine Boot partition zu zerschießen.
Gparted geht (aktuell) mangels desktop natürlich auch nicht..
Oder kann mir jemand sagen welche Dateien man locker löschen kann (zB Logs)

Liebe Grüße und Danke im Vorraus

 

[DKK007]

Logs kannst du natürlich löschen. Müssten unter /var/log liegen.

Alternativ kannst du auch das System neu aufsetzen und dabei die extra Boot-Partition weglassen.

 

[Zeiss]

Geht doch ganz einfach:

1. Inhalt von /boot sichern, nach /tmp/boot oder sowas
2. /boot unmounten, falls gemountet
3. Auf /dev/sda2 ein Verzeichnis /boot erstellen und da die Daten aus Schritt 1 hinkopieren
4. grub anpassen, damit er weiß, dass er jetzt von /dev/sda2 bootet und nicht mehr von /dev/sda3
5. fstab anpassen und den Eintrag für /dev/sda3 rausnehmen
6. Jetzt zur Sicherheit rebooten
7. /dev/sda3 löschen
8. mit gparted die /dev/sda2 vergrößern
9. Fertig

Warum man das System neuaufsetzen soll, ist mir ein Rätsel...

 

[Ellina]

Naja neu aufsetzten würde schon meiner meinung was bringen. Wiso es ein Rätsel ist kann ich dir nicht erklären.

Aber mit einer neu installierten system läuft der server runder vor allen weil die 10gb für boot weg fallen.
Das bleibt für mich ein Räsel wiso man das so groß machen muss. Und mit systemplege bekommt man auch die 1GB padition gut in griff dass die net voll ist.

 

[Zeiss]

Runder, genau..............

 

[EPBAPA]

1. Inhalt von /boot sichern, nach /tmp/boot oder sowas

Nach /tmp/ "sichern", ist immer eine gute Idee - Man kann sich dann jedenfalls eventuell sicher sein, dass die Daten irgendwann weg sind

Also im Ernst: Wenn es maximal schlecht läuft, ist ein tmpfs im RAM auf /tmp gemountet und wenn der Rechner dann abstürzt, sind auch alle Daten direkt weg... Wenn es besser läuft, sind sie wenigstens noch ein paar Tage dort...
In /tmp schreiben in der Regel nur Programme zur Laufzeit Daten wie Benutzereingaben, die jederzeit wiederherstellbar sind.

 

[fotoman]

In /tmp schreiben in der Regel nur Programme zur Laufzeit Daten wie Benutzereingaben, die jederzeit wiederherstellbar sind.

Und an welcher Stele des Ablaufes stört dies, wenn man ihn beachtet und nicht Schritt 6 nach 1 aber vor 3 ausführt?

Wenn es maximal schlecht läuft,

...dann semmelt nach Schitt 2 das System ab, man bootet das System neu, hat /boot immer noch auf der alten Partition und Da Schritt 4+5 noch nicht ausgeführt wurden, ist alles bei Alten und man fängt halt wieder vorne an.

Ich hätte eher Bedenke, ob bei der Kopieraktion von /boot alle Links und /boot/EFI Einträge korrekt übernommen werden. Mit entsprechendem Backup ist der Sebstversuch aber auch kein Problem.

 

[Zeiss]

Nach /tmp/ "sichern", ist immer eine gute Idee - Man kann sich dann jedenfalls sicher sein, dass die Daten irgendwann weg sind

Also im Ernst: Wenn es maximal schlecht läuft, ist ein tmpfs im RAM auf /tmp gemountet und wenn der Rechner dann abstürzt, sind auch alle Daten direkt weg... Wenn es besser läuft, sind sie wenigstens noch ein paar Tage dort...
In /tmp schreiben in der Regel nur Programme zur Laufzeit Daten wie Benutzereingaben, die jederzeit wiederherstellbar sind.

Du kannst uns natürlich auch verraten bei welchem Linux das der Fall sein soll? Ich kenne kein einziges Linux oder HP-UX oder AIX bei denen das der Fall sein soll....

Bei SLES unde Debian ist /tmp ein persistentes Verzeichnis, kein tmpfs und wird auch nicht automatisch aufgeräumt......

tmpfs wird nach /dev/shm gemountet...

ich@rechner:~> cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3
ich@rechner:~>
ich@rechner:~>
ich@rechner:~>
ich@rechner:~> mount
/dev/sda2 on / type ext3 (rw,acl,user_xattr)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,mode=1777)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /boot type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_data on /data type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_home on /home type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_opt on /opt type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_srv on /srv type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_tmp on /tmp type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_usr on /usr type ext3 (rw,acl,user_xattr)
/dev/mapper/system-lv_var on /var type ext3 (rw,acl,user_xattr)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /var/lib/ntp/proc type proc (ro,nosuid,nodev)
ich@rechner:~>

 

[EPBAPA]

Du kannst uns natürlich auch verraten bei welchem Linux das der Fall sein soll?

Das war früher häufiger der Fall, eigentlich auf fast allen Distributionen. Es ist auf jeden Fall unter anderem auch vorgesehen, dass man /tmp in den RAM legt, weil man sich eigentlich sicher ist, dass das, was da drin ist, eben nur während des Betriebs gebraucht wird und das war teilweise von ein paar Jahren sogar noch der Default. Man möchte idR. keine unnötigen Schreibzugriffe auf Festspeicher im Betrieb.
Um /tmp zu leeren, gibt es bspw. den Dienst systemd-tmpfiles-clean. Der kann so eingestellt werden, dass er regelmäßig die Temp-Verzeichnisse leert. Früher wurde das auch per Cron-Job erledigt. Meistens wurde dabei das Programm tmpwatch gestartet, das dann Dateien gelöscht hat, auf die x Tage lang nicht mehr zugegriffen wurde.

Bei SLES unde Debian ist /tmp ein persistentes Verzeichnis, kein tmpfs und wird auch nicht automatisch aufgeräumt......

Das ist richtig, zumindest für die aktuelle openSUSE-Version und somit habe ich mich zu sicher ausgedrückt. Das habe ich jetzt relativiert.
In der Regel sollte ein Programm seine Dateien in /tmp bei Beendigung löschen. Allerdings funktioniert das natürlich nicht zuverlässig, spätestens wenn man das Programm killen muss.

Die Einstellung der zu leerenden Verzeichnisse für den Systemd-Dienst wird in /usr/lib/tmpfiles.d/tmp.conf vorgenommen. Da steht bei openSUSE Leap 15.1:

# SUSE policy: we don't clean those directories

Die Wahrscheinlichkeit, dass die Daten weg sind, ist also relativ gering. Trotzdem ist es auch nicht unwahrscheinlich, dass andere Distributionen eine regelmäßige Pflege des Dateisystems durchführen und dabei auch Temp-Verzeichnisse löschen.

Es ist jedenfalls dem FilesystemHierarchy Standard nach falsch, Dateien nach /tmp zu legen, die evtl. einen Neustart überleben sollen:

Although data stored in /tmp may be deleted in a site-specific manner, it is recommended that files and directories located in /tmp be deleted whenever the system is booted.

Der offizielle Weg ist also eigentlich, dass man mit Sicherheit sagen kann, dass die Daten nach dem Neustart weg sind. Dass viele Distributionen ihre eigenen Wege gehen, steht dann auf einem anderen Blatt.

 

[Tekkla]

Gparted geht (aktuell) mangels desktop natürlich auch nicht..

Klar geht das... GParted -- Download