[Gelöst]Upgrade auf Jessie nicht vollständig

[UserNrX]

Hallo,
von Wheezy auf Jessie aufzugraden erfolgte nicht vollständig. Dennoch wurde das System neugestartet und Jessie scheint ja zu laufen, die Aktualisierung der Pakete schlägt aber fehl mit der Meldung, dass auf dem Wurzelverzeichnis zu wenig Speicherplatz sei.
Mit apt-get update & apt-get upgrade & apt-get dist-upgrade habe ich versucht das System zu aktualisieren, leider ohne Erfolg. Die Meldungen lauten:

Code: Alles auswählen

Es müssen noch 0 B von 66,1 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 240 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] j
Vorkonfiguration der Pakete ...
(Lese Datenbank ... 194186 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../linux-image-3.16.0-4-586_3.16.7-ckt9-2_i386.deb ...
Entpacken von linux-image-3.16.0-4-586 (3.16.7-ckt9-2) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/linux-image-3.16.0-4-586_3.16.7-ckt9-2_i386.deb (--unpack):
 Extrahierte Daten für »./lib/modules/3.16.0-4-586/kernel/drivers/scsi/esas2r/esas2r.ko« können nicht nach »/lib/modules/3.16.0-4-586/kernel/drivers/scsi/esas2r/esas2r.ko.dpkg-new« kopiert werden: Es konnte nicht geschrieben werden (Auf dem Gerät ist kein Speicherplatz mehr verfügbar)
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet
Vorbereitung zum Entpacken von .../linux-image-3.16.0-4-686-pae_3.16.7-ckt9-2_i386.deb ...
Entpacken von linux-image-3.16.0-4-686-pae (3.16.7-ckt9-2) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/linux-image-3.16.0-4-686-pae_3.16.7-ckt9-2_i386.deb (--unpack):
 Extrahierte Daten für »./lib/modules/3.16.0-4-686-pae/kernel/drivers/scsi/lpfc/lpfc.ko« können nicht nach »/lib/modules/3.16.0-4-686-pae/kernel/drivers/scsi/lpfc/lpfc.ko.dpkg-new« kopiert werden: Es konnte nicht geschrieben werden (Auf dem Gerät ist kein Speicherplatz mehr verfügbar)
dpkg-deb: Fehler: Unterprozess einfügen wurde durch Signal (Datenübergabe unterbrochen (broken pipe)) getötet
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/linux-image-3.16.0-4-586_3.16.7-ckt9-2_i386.deb
 /var/cache/apt/archives/linux-image-3.16.0-4-686-pae_3.16.7-ckt9-2_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Es gibt dpkg-Fehler und Speicherplatzmangel. Wie kann diese Probleme lösen?
Auf meinem Netbook Aspire One von Acer aud dem Jahr 2009 lief Wheezy seit einige Monate und davor Ubuntu. RAM=2,0 GiB; Prozessor=Intel® Atom™ CPU N450 @ 1.66GHz × 2; Grafik= Intel® IGD x86/MMX/SSE2, OS=Debian GNU/Linux 8 (jessie) 32-Bit.
Meine 250 GiB-Festplatte ist wie folgt partitioniert:
/sda1 350MB eingehängt in Dateisystemwurzel(Bootpartition)
/sda2 250 GB erweiterte Partition mit:
/sda5 40 GB eingehängt in /usr
/sda6 3 GB eingehängt in /var
/sda7 4 GB swap
/sda8 400 MB eingehängt in /tmp
/sda9 202 GiB eingehängt in /home
Ich bin um jede Hilfe dankbar.

[CH777]

Die Meldung ist doch ganz eindeutig: Die Festplatte bzw. Partition ist voll.
Wo liegt denn der Ordner /lib? Ist das hier:

/sda1 350MB eingehängt in Dateisystemwurzel(Bootpartition)

? Was sagt ein df -h?

[hikaru]

Mit apt-get update & apt-get upgrade & apt-get dist-upgrade habe ich versucht das System zu aktualisieren, leider ohne Erfolg.

Lass bitte bei Releasewechseln grundsätzlich das einfache upgrade weg, sondern verwende immer dist-upgrade!

Dir fällt deine kleinteilige Partitionierung auf die Füße. Auf der root-Partition ist nicht genug Platz um einen zweiten Kernel zu installieren.
Falls du das System behalten willst zeig mal bitte die Dateien /etc/fstab sowie /boot/grub.cfg und bereite ein Live-System mit Gparted vor. Eine Neuinstallation wäre einfacher.

[debianoli]

Lass bitte bei Releasewechseln grundsätzlich das einfache upgrade weg, sondern verwende immer dist-upgrade!

Wieso das denn bitte? Das Upgrade per apt-get upgrade && apt-get dist-upgrade ist doch die offizielle Empfehlung des Debian-Teams, siehe https://www.debian.org/releases/jessie/ ... al-upgrade

[hikaru]

Wieso das denn bitte?

Weil ich geschlafen habe.
Das upgrade in der Mitte stört natürlich nicht, sofern danach noch ein dist-upgrade folgt. Ich kannte bisher nur die Variante entweder upgrade oder dist-upgrade und da gehen bei mir im Zusammenhang mit Releasewechseln immer die Alarmsirenen an.

Das Upgrade per apt-get upgrade && apt-get dist-upgrade ist doch die offizielle Empfehlung des Debian-Teams, siehe https://www.debian.org/releases/jessie/ ... al-upgrade

Ich halte das in der dort beschriebenen Art trotzdem für unsauber (methodisch, nicht vom Ergebnis her). Wenn Beim upgrade && dist-upgrade weniger Pakete entfernt werden als beim dist-upgrade allein, dann kann das eigentlich nur daran liegen, dass vorher veraltete Pakete installiert waren, deren Abhängigkeiten* sich zwischen der veralteten und aktuellen Version geändert haben. Die saubere Lösung wäre mMn VOR dem aktualisieren der Quellen auf das neue Release ein upgrade auszuführen.


*) Als allgemeines Sammelsurium der "Binary Dependencies":
https://www.debian.org/doc/debian-polic ... binarydeps

[debianoli]

Die saubere Lösung wäre mMn VOR dem aktualisieren der Quellen auf das neue Release ein upgrade auszuführen.

So hätte ich die Upgrade-Anleitung auch verstanden. Aber direkt steht das da nicht.

[UserNrX]

Also, die Ausgabe von df -h lautet:

Code: Alles auswählen

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sda1       323M    269M   38M   88% /
udev             10M       0   10M    0% /dev
tmpfs           404M    6,1M  397M    2% /run
/dev/sda5        37G    8,5G   27G   25% /usr
tmpfs          1008M    152K 1008M    1% /dev/shm
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs          1008M       0 1008M    0% /sys/fs/cgroup
/dev/sda8       368M     11M  339M    3% /tmp
/dev/sda6       2,8G    1,1G  1,6G   42% /var
/dev/sda9       186G    1,7G  175G    1% /home
tmpfs           202M     16K  202M    1% /run/user/1000

Ich vermute, dass lib im Wurzelverzeichnis / liegt, das ist jedenfalls was in den Eigenschaften des Ordners steht. Dort steht auch dass der Inhalt 8.466 Objekte der Gesamtgröße 200,8 MB beträgt. Freier Speicherplatz: 39,6 MB.
Meine Partiionierung für das Wurzelverzeichnis ist so klein, weil ich mich den Empfehlungen die hier https://www.debian.org/releases/stable/ ... 02.html.destehen gefolgt bin.
Was bitte habe ich missverstanden? Ist jetzt ein Upgrade definitv zu schwierig als dass eine neue Installation vorzuziehen wäre?
Hier noch /etc/fstab. Die Datei /boot/grub.cfg ist leer.

Code: Alles auswählen

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=2c3d7659-14f5-4e70-b676-bcf1713738ad /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda9 during installation
UUID=5a557d21-9c81-41b8-a696-afdddb9fef24 /home           ext4    defaults        0       2
# /tmp was on /dev/sda8 during installation
UUID=783094db-c6f8-4920-8444-cc3338380ff0 /tmp            ext4    defaults        0       2
# /usr was on /dev/sda5 during installation
UUID=be2ffc77-0ee2-4d68-a32f-3d0bbcf56154 /usr            ext4    defaults        0       2
# /var was on /dev/sda6 during installation
UUID=372a5d36-ee2f-4dfd-914d-35cdd969487a /var            ext4    defaults        0       2
# swap was on /dev/sda7 during installation
UUID=7c809192-1633-4033-9064-b9fb6f96e5d5 none            swap    sw              0       0
/dev/sdb1       /media/usb0     auto    rw,user,noauto  0       0

Code: Alles auswählen

[hikaru]

Meine Partiionierung für das Wurzelverzeichnis ist so klein, weil ich mich den Empfehlungen die hier https://www.debian.org/releases/stable/ ... 02.html.destehen gefolgt bin.
Was bitte habe ich missverstanden?

Die dort angegebenen Partitionsgrößen sind konservative Mindestangaben. Größer kann also nicht schaden. Gerade die 300MB für boot sind einfach zu klein, wenn man zwei Kernel installiert hat (wie z.B. nach einem dist-upgrade), die jeweils 150MB groß sind.

Außerdem steht da z.B. das:

Es wird jetzt empfohlen, /usr auf die root-Partition / zu legen

Daraus könnte man schließen, dass es klug wäre alles auf eine Partition zu legen, falls einem kein Grund einfällt das anders zu handhaben.
Aber das hätte man dort ruhig so hinschreiben können.

Ist jetzt ein Upgrade definitv zu schwierig als dass eine neue Installation vorzuziehen wäre?

Das kommt darauf an, wie stark du dein aktuelles System angepasst hat. Wenn es weitgehend unverändert ist, dann wäre eine Neuinstallation vorzuziehen, bei der du alles auf eine Partition installierst, wie vom Installer vorgeschlagen.
Wo ich dich jetzt hinlotsen würde wäre ein System mit separater home-Partition (auch einer der Installer-Vorschläge), während deine kleinen Systempartitionen alle zu einer einzigen zusammengefasst werden. Das ist nicht schwierig, wenn man weiß wie es geht, aber es steckt einiger Aufwand dahinter. Inklusive des ganzen Beitragspingpongs das wir dafür wohl führen müssen wäre eine Neuinstallation auf jeden Fall schneller.
Ein Backup deiner Daten solltest du auf jeden Fall machen, falls du das noch nicht getan hast.

Die Datei /boot/grub.cfg ist leer.

War wohl gestern nicht mein Tag. Die Datei liegt unter: /boot/grub/grub.cfg

[rendegast]

Meine Partiionierung für das Wurzelverzeichnis ist so klein, weil ich mich den Empfehlungen die hier https://www.debian.org/releases/stable/ ... l.destehen gefolgt bin.
Was bitte habe ich missverstanden?

Die dort angegebenen Partitionsgrößen sind konservative Mindestangaben. ...

Eher, das howto ist diesbezüglich veraltet.
Da wird noch von Festplatten mit 1,7GB geschwafelt.
Es wurde zwar der Reponame 'jessie' getauscht, der Inhalt verblieb unangetastet.

dann wäre eine Neuinstallation vorzuziehen

Ich würde mit einer live-cd/-stick booten,
/ und /usr mounten,
den Inhalt von /usr nach /usr/usr/ verschieben,
den Inhalt von / nach /usr/ verschieben,
(Die alte /usr-Partition wird also zur neuen /-Partition),
der früheren /usr- also neuen /-Partition wird die UUID der früheren /-Partition vergeben, die der früheren /-Partition wird verändert (so passt die grub.cfg noch),
die Zeile für den /usr-Mount in der fstab entfernen,
-- dann entweder in das "neue" System chrooten für 'grub-install'
(was noch ein paar bind-Mounts in das chroot benötigt)
-- oder in die grub-shell booten, einige Zeilen

Code: Alles auswählen

set root=(hd.,.....)
set prefix=(.....)/boot/grub
linux (......)/boot/vmlinuz..... root=/dev/..... ....
initrd (......)/boot/initrd....

per tab-Completion konstruieren und einen ersten Boot, dann 'grub-install' aus diesem System heraus,
-- oder das /usr/boot-Verzeichnis per bind-Mount nach /boot des live-Systems mounten und im live-System 'grub-install' ausführen (stellt für ungeübte wohl die einfachste Möglichkeit),

[hikaru]

Ja, sowas in der Art schwebte mir auch vor.
Ich würde auch noch /tmp (wird gern mal bei Downloads oder beim CD-Brennen voll) und /var (sieht schon vergleichsweise voll aus) auf die dann neue /-Partition schieben.

[debianoli]

Da im /home nur 1,7 GB belegt sind, würde ich in diesem Fall eine Neu-Installation vorschlagen. Dadurch kann man auch den ganzen Krampf mit erweiterten Partitionen beseitigen, denn das kann in der Praxis manchmal Ärger machen. Stattdessen würde ich hier ganz klassisch 3 bis 4 primäre Partitionen anlegen: 1 Partiton für / mit 15 bis 20 GB, 1 Partition für Swap mit 4 bis 5 GB und den Rest für /home. falls man gerne rumspielen will, kann man sich eine 4. Partiton mit 15 GB für andere Linux-Test-Systeme einrichten.

Die Daten aus /home lassen sich schnell auf einer externen Festplatte oder einem USB-Stick sichern und dann in das neue home zurückspielen.

Code: Alles auswählen

/dev/sda9       186G    1,7G  175G    1% /home

Und wenn man vorher mit dpkg die installierten Pakete der Wheezy-Installation sichert, spart man sich die ganze Arbeit des Installierens von zB zusätzlichen Grafik-programmen etc. Macht aber nur Sinn, wenn man recht viele Programme installiert hat:

Code: Alles auswählen

dpkg --get-selections > Wheezy_Prg.txt #und die Datei Wheezy_Prg.txt natürlich auf USB-Stick sichern

In der Neuinstallation kann man dann mit

Code: Alles auswählen

dpkg --set-selections < Wheezy_Prg.txt 

die ganzen Pakete erneut installieren. Allerdings empfiehlt es sich, aus der Datei vorher Einträge wie zB für den alten Kernel zu entfernen

Edit: Es gibt auch ein Tool, mit dem man eine Logical Partition OHNE Datenverlust in eine Primary Partiton umwandeln kann, aber der Name des Programms fällt mir nicht mehr ein.
Edit2: Jetzt habe ich es wieder, das müsste fixparts aus gdisk sein

[Systemcrasher]

Eher, das howto ist diesbezüglich veraltet.

Könnte es auch sein, daß da ein fehler drin ist?

100-300 MB nimmt man doch normalerweise für /boot, jedenfalls kenne ich das so von anderen Distries.

Für / nehme ich - wenn möglich - immer 10GB, der Rest /home.

Wenn ich mehr als 1 BS drauf habe, dann habe ich noch ein /Daten, welches ich im /home verlinke und worauf dann alle Distries zugreifen können.

[UserNrX]

Liebe Debianer,
ich habe also eine Neueinstallation vor- und voll(ge)zogen, da ich mein System übersichtlich gehalten hatte und nur ein paar wenigen Programme, die ohnehin in der Quellen zu finden sind, dazu installiert hatte.
Jetzt sieht die Partionierung wie folgt:
1. Primär 40 GB /
2. Logisch 7,3 GB swap
3. Logisch 202,8 GB /home.
Also in etwa so wie von debianoli vorgeschlagen.
Jetzt läuft das System rund und die Probleme von Wheezy scheinen beseitigt zu sein: Instabile Kabelverbingung ins Internet, richtige Version des Programms HomeBank für meine Daten.
Das einzige Problem ist, dass das Arbeiten mit den Fenstern und Arbeitsflächen nicht richtig funktioniert: Ich kann ein Fenster nicht auf eine neu Arbeitsfläche ziehen. Es erscheine immer zwei Arbeitsflächen mit den geöffneten Fenstern. Das Ziehen bewirkt keine Ablage auf einer neue Arbeitsfläche.
Was kann ich tun um dies zu beseitigen? Gerade diese Möglichkeit mit Fenstern und Arbeitsflächen zu arbeiten finde ich sehr nützlich.

rendegast hat geschrieben: Eher, das howto ist diesbezüglich veraltet.



Könnte es auch sein, daß da ein fehler drin ist?

100-300 MB nimmt man doch normalerweise für /boot, jedenfalls kenne ich das so von anderen Distries.

Es könnte auch sein, dass ich den Fehler gemacht habe und die /boot-Partition für die /root-Partition gehalten habe. Ich kenne zwar den Unterschied, habe sie aber verwechselt, da sie ja auch zusammenfallen können.

Vielen herzlichen Dank an allen.

[UserNrX]

Hallo, ich melde mich hier nochmal nur, um abzuschließen. Wie wird ein Thema als "gelöst" gesetzt? Ist der derjenige, der den Thread eröffnet hat, auch dafür verantwortlich, dass es geschlossen wird? Ich habe keine Hinweise dazu im Forum oder in den Verhaltensregeln gefunden.
Ich denke, dass dieses Thema als gelöst gesehen werden kann, denn die Probleme sind beseitigt und ich weiß woher sie stammten.
Für die community wäre das Problem gelöst, wenn die Partitionierungsanleitung hier https://www.debian.org/releases/stable/ ... l.destehen aktualisiert wird. Dies ist, aus meiner Sicht jedenfalls, die wichtigste Erkenntnis aus dem Thread.
Eine weitere persönliche Erkenntnis ist dass, für eine Bootpartiion 350MB ausreichen, wenn diese auch nur für die Bootdateien von Grub oder LiLo benutzt wird und sie nicht mit der Rootpartion verwechselt wird. Die Bootdateien können aber auch auf der Rootpartition gepackt werden und machen eine Bootpartition hinfällig. Diese Rootpartition muss dann wesentlich größer sein. Wenn ich richtig verstanden habe, sollte sich diese Größe nach der Größe des Grundsystems orientieren und zumindest 10GB bei einem graphischen System betragen (Patitionsvorschlage von partman bei der Installation).
Somit kann dieser Thread als gelöst gesetzt werden.
Nochmal vielen Dank an allen!

[uname]

Hallo, ich melde mich hier nochmal nur, um abzuschließen. Wie wird ein Thema als "gelöst" gesetzt?

Du kannst deinen ersten Beitrag ganz oben editieren und beim Betreff z.B. "[gelöst] vorne im Betreff hinzufügen.

[dirk11]

Die Bootdateien können aber auch auf der Rootpartition gepackt werden und machen eine Bootpartition hinfällig.

Nur bedingt, denn dadurch vergibst du dir die Möglichkeit, das System voll zu verschlüsseln, denn dafür wird ein separates /boot benötigt.

[UserNrX]

Danke, dirk11, für diesen nicht unerheblichen Hinweis. Ich werde nachlesen, ob ein vollverschlüsseltes System für mich Sinn macht und beim nächsten Release oder bei der nächsten Installation dem entsprechend handeln.