Update von Wheezy auf Jessie > update-grub hängt sich auf

[agentm]

Gruetzi miteinand,

beim Update von Wheezy auf Jessie hat sich im Schritt

Code: Alles auswählen

sudo apt-get upgrade

an der Stelle

Code: Alles auswählen

update-grub

'unendlich' aufgehangen.

Also ein neues Terminal geöffnet und geschaut:
ein <mount> war auf 100% CPU welcher von update-grub gestartet über den os-prober auf die Partition sda2 zugreifen wollte.

Aha, sda2 ist eine erweiterte Partition, darin steckt die sda5, welche lvm Partitionen enthält.

Im Internet findet man zu dem Thema ein paar ältere Bug-Reporte, die aber nicht genau darauf hin zutreffen.

Auf einem anderen PC hab ich zum Glück eine ähnliche Konstellation, und diesen hatte ich schon erfolgreich auf Jessie umgestellt.

Folgender wesentlicher und wahrscheinlich auch ursächlicher Unterschied fällt auf:

Code: Alles auswählen

sudo cat proc/partitions

listet auf dem Problem-System die erweiterte Partition sda2 auf und auf dem System ohne Problem, das Gut-System, werden keine erweiterten Partitonen angezeigt.

Weiterhin kann ich mit parted auf dem Problem-System auf die erweiterte Partition zugreifen (Achtung, kann gefährlich werden):

Code: Alles auswählen

sudo parted
select /dev/sda2
print

liefert

Code: Alles auswählen

Error: Can't have a partition outside the disk

irgendwie nicht die rechte Fehlermeldung, aber naja...

auf dem Gut-System kann ich gar nicht erst auf eine erweiterete Partition zugreifen:

Code: Alles auswählen

Error: Error opening /dev/sdb2: No such device or address

schön, wäre es, wenn einfach gemeldet würde, daß es sich hier um eine erweiterte Partiton handelt an der man besser nicht frickelt...

Nach dem wiederholten Abschiessen der os-prober Prozesse (den mount konnte ich nicht killen) wurde die Installation zu Ende geführt.
Auch den großen Upgrade hab ich dann auch noch trotzdem gemacht und ist erfolgreich verlaufen.

Ich kann jetzt leider kein aktuelles Linux-Image installieren, da sich dann wieder der upgrade-grub aufhängt.

Wäre interessant ob jemand hierzu Hinweise oder Ideen hat,

AgentM

[Blackbox]

Fehler die als erste ins Auge stechen:

• 1. sudo
  2. upgrade

Vielleicht willst du ja erst einmal deine Abhängigkeiten vollständig auflösen, wenn dies überhaupt noch möglich ist ?
Wolltest du nicht ein Upgrade auf Jessie machen, warum verwendest du dann nicht auch gleich dist-upgrade ?
Aber bitte erst, nachdem du deine Abhängigkeiten in Ordnung gebracht hast !

[Apfelmann]

Ich habe beim dist-upgraden die störenden Pakete deinstalliert und hinterher wieder eingerichtet,
Bei diesen Veränderungen am System sollte immer auf dem Terminal (nie in der Grafik) gearbeitet werden.

Deinstallation der störenden Pakete und danach erst einmal mit apt-get -f install die aktuelle Situation prüfen und bereinigen, danach wieder das dist-upgrade anschieben.
Beim Upgrade werden einige Pakete zurückgehalten, beim Hochziehen auf Jessie unbedingt ein dist-upgrade durchführen.

LG

[NAB]

Sind noch andere Systeme auf dem Rechner? Sonst wäre es am einfachsten, "os-prober" einfach zu deinstallieren.

[agentm]

Sind noch andere Systeme auf dem Rechner? Sonst wäre es am einfachsten, "os-prober" einfach zu deinstallieren.

Sehr gute Idee...

Probier ich gleich mal...

trotzdem bleibt die Frage, warum auf dem einen System erweiterte Partitionen in /proc/partitions stehen und im anderen nicht.

[agentm]

Sind noch andere Systeme auf dem Rechner? Sonst wäre es am einfachsten, "os-prober" einfach zu deinstallieren.

Sehr gute Idee...

Probier ich gleich mal...

trotzdem bleibt die Frage, warum auf dem einen System erweiterte Partitionen in /proc/partitions stehen und im anderen nicht.

os-prober zu deinstallieren hat etwas gebracht.

Ich bekomme von update-grub immer noch eine Fehlermeldung , aber wenigstens hängt sich der Prozess jetzt nicht mehr auf .

UND: ich kann jetzt das Linux-Image installieren

[agentm]

Fehler die als erste ins Auge stechen:

• 1. sudo
  2. upgrade

Vielleicht willst du ja erst einmal deine Abhängigkeiten vollständig auflösen, wenn dies überhaupt noch möglich ist ?
Wolltest du nicht ein Upgrade auf Jessie machen, warum verwendest du dann nicht auch gleich dist-upgrade ?
Aber bitte erst, nachdem du deine Abhängigkeiten in Ordnung gebracht hast !

zu 1. wieso ist sudo ein Fehler?

zu 2. beim Versionen-Wechsel wird empfohlen zunächst

Code: Alles auswählen

sudo apt-get upgrade

durchzuführen. Dies hat den Hintergrund, daß alle Paket, die keine Abhängigkeiten haben, bereits in der neuen Version installiert werden können.
Dieses System ist in der Regel auch boot- und lauffähig.

Danach kann dann das große Update durchgeführt werden:

Code: Alles auswählen

sudo apt-get dist-upgrade

siehe hier: 4.4.4. Minimales System-Upgrade https://www.debian.org/releases/stable/ ... al-upgrade

[agentm]

Ich habe beim dist-upgraden die störenden Pakete deinstalliert und hinterher wieder eingerichtet,
Bei diesen Veränderungen am System sollte immer auf dem Terminal (nie in der Grafik) gearbeitet werden.

Deinstallation der störenden Pakete und danach erst einmal mit apt-get -f install die aktuelle Situation prüfen und bereinigen, danach wieder das dist-upgrade anschieben.
Beim Upgrade werden einige Pakete zurückgehalten, beim Hochziehen auf Jessie unbedingt ein dist-upgrade durchführen.

LG

Wenn ich alle Pakete deinstallieren wollte, die beim Versionen-Upgrade 'stören', dann kann ich ja bald gleich neu installieren

Den Laptop hier hab ich seit 2007 und bisher noch nie neu installiert, sondern immer upgegradet...

[NAB]

Worüber meckert update-grub denn?

trotzdem bleibt die Frage, warum auf dem einen System erweiterte Partitionen in /proc/partitions stehen und im anderen nicht.

Hätte ich darauf eine kompetente Antwort, so hätte ich sie dir verraten. Auf den ersten Blick würde ich vermuten, dass da was mit der Partitionstabelle nicht stimmt, aber ich schlage vor, du bringst erst mal dein dist-upgrade zuende und schaust dann, ob es noch Probleme gibt.

Ansonsten hat mich das Fehlen von /dev/sdb2 auf dem "Gut-System" irritiert. Das System muss die Partition ja erkennen, damit du auf den Inhalt zugreifen kannst. Vielleicht schaust du dir das noch mal näher an, ob das wirklich stimmt.

[agentm]

Worüber meckert update-grub denn?

Code: Alles auswählen

/usr/sbing/grub-probe: warning: couldn't find physical volume 'pv1'. Some modules may be missing from core

auch nach erfolgreichem upgraden auf den Kernel 3.16 bleibt die Fehlermeldung bestehen.

trotzdem bleibt die Frage, warum auf dem einen System erweiterte Partitionen in /proc/partitions stehen und im anderen nicht.

Hätte ich darauf eine kompetente Antwort, so hätte ich sie dir verraten. Auf den ersten Blick würde ich vermuten, dass da was mit der Partitionstabelle nicht stimmt, aber ich schlage vor, du bringst erst mal dein dist-upgrade zuende und schaust dann, ob es noch Probleme gibt.

Ansonsten hat mich das Fehlen von /dev/sdb2 auf dem "Gut-System" irritiert. Das System muss die Partition ja erkennen, damit du auf den Inhalt zugreifen kannst. Vielleicht schaust du dir das noch mal näher an, ob das wirklich stimmt.

Das dist-upgrade hatte ich ja schon vorher fertig bekommen. Ich konnte lediglich auf Grund des Hängers in update-grub keinen aktuellen Kernel installieren. Deswegen hatte ich ja hier gepostet, da ich etwas festgefahren war - passiert ja eher selten, da man im Internet an vielen Stellen etwas findet was einen dann doch auf die Sprünge hilft.

Das hiesse aber, daß in meinem 'Gut-System' genau das fehlen würde, was das Problem-System zum Problem-System macht
Wäre ein großer Zufall, aber natürlich nicht unmöglich.

Das Gut-System:

Code: Alles auswählen

cat /proc/partitions

major minor  #blocks  name

   8        0  976762584 sda
   8        1  472752756 sda1
   8       16  312571224 sdb
   8       17     248832 sdb1
   8       21  312320000 sdb5
   8       32  976762584 sdc
   8       33  894713856 sdc1
  11        0    1048575 sr0
 254        0    1388544 dm-0
 254        1   16166912 dm-1
 254        2   13717504 dm-2
...
 254       19  157704192 dm-19

und KEINE sdb2, wohingegen

Code: Alles auswählen

sudo parted /dev/sdb

GNU Parted 3.2
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.

(parted) print                                                            
Model: ATA ST320DM000-1BD14 (scsi)
Disk /dev/sdb: 320GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type      File system  Flags
 1      1049kB  256MB  255MB  primary   ext2         boot
 2      257MB   320GB  320GB  extended
 5      257MB   320GB  320GB  logical                lvm

liefert. Also die Existenz von sdb2 bestätigt - wurde aber auch nie angezweifelt.

Auf dem Problem-System wird die erweiterte Partition mit einer Länge von 1 in /proc/partitons angezeigt.

Wer schreibt denn eigentlich die Datei /proc/partitions?

[NAB]

Code: Alles auswählen

/usr/sbing/grub-probe: warning: couldn't find physical volume 'pv1'. Some modules may be missing from core

Hier wird grub-probe auf das vermeintliche Gerät "pv1" losgelassen und kann das mit Hilfe seines "core" nicht öffnen. Das liegt vermutlich daran, dass das Modul "lvm" im core fehlt. Das ist auch ganz gut so, denn sonst wird der core so groß, dass er sich nicht mehr in eine MBR-Partitionstabelle quetschen lässt. Solange du nicht direkt von einem LVM booten willst, ist diese Meldung irrelevant.

Auf dem Problem-System wird die erweiterte Partition mit einer Länge von 1 in /proc/partitons angezeigt.

Ah, nun ist es klar. Ich hab grad keine MBR-Partitionierung zur Hand, in der ich nachgucken könnte, wie der aktuelle Kernel die anzeigt, aber das klingt schon nach einer "Anormalie" in der Partitionstabelle.

Wer schreibt denn eigentlich die Datei /proc/partitions?

Die schreibt der Kernel persönlich. /proc ist ein virtuelles Verzeichnis, das der Kernel erzeugt, um dir Einblick in das Innenleben des Systems zu gewähren. Genauer gesagt ist /proc veraltet und wird nur noch mitgeschleppt, um ältere Programme nicht zu verwirren. Inzwischen wurde /proc durch das wesentlich umfangreichere /sys/ ersetzt. Unter /sys/block/ müsstest du alle Informationen zu deinen Festplatten und Partitionen finden, unübersichtlich verteilt in zig kleine Dateien. Darum würde ich /proc auch nicht mehr allzuviel Bedeutung zumessen. Schau dir lieber mal an, was z.B. gparted dir über deine Partitionen verrät.

[agentm]

Hier wird grub-probe auf das vermeintliche Gerät "pv1" losgelassen und kann das mit Hilfe seines "core" nicht öffnen. Das liegt vermutlich daran, dass das Modul "lvm" im core fehlt. Das ist auch ganz gut so, denn sonst wird der core so groß, dass er sich nicht mehr in eine MBR-Partitionstabelle quetschen lässt. Solange du nicht direkt von einem LVM booten willst, ist diese Meldung irrelevant.

Ok gut, das erklärt warum die Fehlermeldung nach Deinstallation von os-prober noch da ist. Es erklärt auch, warum die Installation nun erfolgreich beendet wird. Die Fehlermeldung im Vordergrund hatte also überhaupt nichts mit dem Hänger im Hintergrund zu tun.

Ah, nun ist es klar. Ich hab grad keine MBR-Partitionierung zur Hand, in der ich nachgucken könnte, wie der aktuelle Kernel die anzeigt, aber das klingt schon nach einer "Anormalie" in der Partitionstabelle.

Gut, da muß ich da mal bei Gelegenheit weiter forschen. Ergebnis werde ich hier berichten.

Die schreibt der Kernel persönlich. /proc ist ein virtuelles Verzeichnis, das der Kernel erzeugt, um dir Einblick in das Innenleben des Systems zu gewähren. Genauer gesagt ist /proc veraltet und wird nur noch mitgeschleppt, um ältere Programme nicht zu verwirren. Inzwischen wurde /proc durch das wesentlich umfangreichere /sys/ ersetzt. Unter /sys/block/ müsstest du alle Informationen zu deinen Festplatten und Partitionen finden, unübersichtlich verteilt in zig kleine Dateien. Darum würde ich /proc auch nicht mehr allzuviel Bedeutung zumessen. Schau dir lieber mal an, was z.B. gparted dir über deine Partitionen verrät.

Ich hätte auch erwartet, daß mit dem neuen Kernel die Datei /proc/partitions auch auf den Stand des Gut-Systems kommen wird, war aber nicht so.

Wenn das eh veraltet ist, werde ich so wie Du sagst mal in /sys/ nachschauen und eben auch mal gparted starten.

Ich melde mich dann wieder... Vielen Dank erst mal soweit!

[agentm]

gparted zeigt die erweiteterte Partition /dev/sda2 korrekt an.

Der Fehler wird also von os-prober verursacht.
Etwas quanteln ( http://www.qwant.com googlen tue ich schon lange nicht mehr) hat folgendes hervorgebracht:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=735169

os-prober verwendet blkid aus dem Paket util-linux um alle Partitionen nach einem BS zu durchsuchen.
Beim Problem-System sieht das dann leider so aus:

Code: Alles auswählen

sudo blkid /dev/sda2
/dev/sda2: PTTYPE="dos" PARTUUID="44fb778d-02"

Abfrage des Fehlers mit

Code: Alles auswählen

echo $?
0

also kein Fehler und damit eine gültige Partition
woraufhin dann os-prober sagt: Prima, dann mounte ich die mal... was natürlich schief geht und zum Hängen des mount-Befehls führt.

wieso steht da PTTYPE="dos"? Ist mir ein Rätsel, die Partition wurde 2007 vom etch-Installer angelegt...

auf dem Gut-System wird eine erweiterte Partition mit dem Fehler 2 als ungültige Partition erkannt und os-prober versucht dann entsprechend auch nicht diese zu mounten.

[NAB]

Note that low-level probing also returns information about partition table
type (PTTYPE tag) and partitions (PART_ENTRY_* tags).

Das ist leider auch die einzige Erwähnung von "PTTYPE", aber ich vermute, er will dir damit lediglich sagen, dass es eine msdos-Partitionstabelle ist und keine GPT-Tabelle.

Weiter oben sagtest du schon, dass /dev/sda2 in /proc/partitions als Partition der Größe 1 angezeigt wird. Eine Größe von 1 riecht ja eh schon mal nach Ärger, und anscheinend hält das System sie trotzdem für eine brauchbare Partition. Ich habe keine Ahnung, woher dieser Fehler kommt, aber ich würde die Ursache immer noch auf der Festplatte vermuten, in Form einer ungewöhnlich geformten Partitionstabelle.

Entweder findest du ein Partitionierungsprogramm, das sagt "Stopp, hier ist ein Fehler! Soll ich den korregieren?" oder es wird auf ein Neu-Anlegen der Partitionstabelle hinauslaufen, inklusive Backup ... da fragt sich, ob du dir das wirklich antun willst.

[agentm]

Das ist leider auch die einzige Erwähnung von "PTTYPE", aber ich vermute, er will dir damit lediglich sagen, dass es eine msdos-Partitionstabelle ist und keine GPT-Tabelle.

also jetzt wo ich das nochmal auf meinem Gut-System ausprobieren wollte kommt jetzt auch die gleiche Meldung von blkid -> ergo scheint das mit dem PTTYPE = "dos" normal für eine erweiterte Partition zu sein.

Ich hatte nochmal auf die Debian User List eine Frage zu dem Thema bzgl. blkid gesetzt aber bisher noch keine Antwort erhalten.

Entweder findest du ein Partitionierungsprogramm, das sagt "Stopp, hier ist ein Fehler! Soll ich den korregieren?"

alles was ich so da habe hat nichts an der Partition auszusetzten.

oder es wird auf ein Neu-Anlegen der Partitionstabelle hinauslaufen, inklusive Backup ... da fragt sich, ob du dir das wirklich antun willst.

Um Gottes Willen

Nachdem mein Gut-System jetzt bzgl. blkid genauso aussieht wie das Problem-System ist nicht blkid das Problem sondern vieleicht doch wieder der ominöse os-prober.

Also wieder auf dem Problem-System installiert und mal gestartet.

Code: Alles auswählen

sudo os-prober
/dev/mapper/vincent-xen.testmachine--disk:Debian GNU/Linux (wheezy/sid):Debian:linux

er findet nur - und das ist auch richtig so - eine virtuelles OS...

ABER: man kann sich schön anschauen was passiert wenn man in einem neuen Terminal das syslog tailed:

Code: Alles auswählen

sudo tail -f /var/log/syslog

kommt ein ganzer Rattenschwanz an Meldungen und bei der erweiterten Partition wirds jetzt spannend...

Code: Alles auswählen

Jan  5 18:50:09 vincent os-prober: debug: running /usr/lib/os-probes/50mounted-tests on /dev/sdb2
Jan  5 18:50:09 vincent kernel: [32371.996809] EXT4-fs (sdb2): unable to read superblock
Jan  5 18:50:09 vincent kernel: [32371.997833] EXT4-fs (sdb2): unable to read superblock
Jan  5 18:50:09 vincent kernel: [32371.998894] EXT4-fs (sdb2): unable to read superblock
Jan  5 18:50:09 vincent kernel: [32372.002896] XFS (sdb2): Invalid superblock magic number
Jan  5 18:50:10 vincent kernel: [32372.005258] FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Jan  5 18:50:10 vincent kernel: [32372.005457] FAT-fs (sdb2): bogus number of reserved sectors
Jan  5 18:50:10 vincent kernel: [32372.005460] FAT-fs (sdb2): Can't find a valid FAT filesystem
Jan  5 18:50:10 vincent kernel: [32372.006474] FAT-fs (sdb2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Jan  5 18:50:10 vincent kernel: [32372.006661] FAT-fs (sdb2): bogus number of reserved sectors
Jan  5 18:50:10 vincent kernel: [32372.006663] FAT-fs (sdb2): Can't find a valid FAT filesystem
Jan  5 18:50:10 vincent kernel: [32372.010291] MINIX-fs: unable to read superblock
Jan  5 18:50:10 vincent kernel: [32372.011316] attempt to access beyond end of device
Jan  5 18:50:10 vincent kernel: [32372.011318] sdb2: rw=16, want=3, limit=2
Jan  5 18:50:10 vincent kernel: [32372.011320] hfsplus: unable to find HFS+ superblock
Jan  5 18:50:10 vincent kernel: [32372.012499] qnx4: no qnx4 filesystem (no root dir).
Jan  5 18:50:10 vincent kernel: [32372.013441] You didn't specify the type of your ufs filesystem
Jan  5 18:50:10 vincent kernel: [32372.013441] 
Jan  5 18:50:10 vincent kernel: [32372.013441] mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
Jan  5 18:50:10 vincent kernel: [32372.013441] 
Jan  5 18:50:10 vincent kernel: [32372.013441] >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
Jan  5 18:50:10 vincent kernel: [32372.015547] hfs: can't find a HFS filesystem on dev sdb2

das sieht aber gar nicht fein aus... aber aufhängen tut sich auch nix.
Ein kurzes qwanteln hat gezeigt, daß schon mal wer deswegen einen Bugreport abgegeben hat https://lists.debian.org/debian-boot/20 ... 00064.html

Und da war mir dann klar, daß mein alter Kernel zusammen mit os-prober schuld am Hänger ist.
Also kurz im alten Kernel gebootet und das 'böse' Script direkt auf /dev/sda2 angesetzt

Code: Alles auswählen

sudo /usr/lib/os-probes/50mounted-tests /dev/sda2

und siehe da, der mount-Befehl hängt und frißt 100% CPU Leistung.

Bleibt nur die Frage, warum das vor mir noch niemandem aufgefallen ist. Und wieso hat es bei meinem Gut-System geklappt?

[DeletedUserReAsG]

das sieht aber gar nicht fein aus...

Solange du glaskugel2.deb nicht installiert hast, bleibt ihm aber keine andere Möglichkeit als nachzuschauen, ob andere OS vorhanden sind.

Zu schauen wäre, welche Besonderheiten deine Problempartition denn aufweist.