Hallo zusammen,
mein Hauptrechner bootet nach einen d-u (ein grub-Paket war auch dabei) nicht mehr. Er hängt am "grub rescue" Prompt. Eine Rücksicherung (von einen Live-USB-Stick) des System (Stand vor dem d-u) inklusive des MBR hatte keinen Erfolg, das gleiche Fehlerbild.
Was muss muss ich jetzt tun um die Kiste wieder bootbar zu bekommen?
EDIT: Fehler am grub rescue Prompt
error: symbol 'grub_isprint' not found
Hallo @bluelupo,
leider funktionierte das DU wegen Grub auch bei mir nicht, @melmarker schrieb das auch Qt Probleme machen soll.
Habe meine Sicherung (Image vom 07.03.) über Clonezilla wieder hergestellt.
Aus dem Live-System heraus kannst du nur versuchen den MBR auf der Platte neu zu schreiben.
Werde noch bis Samstag warten mit einem neuen DU.
Hi DeKa,
Qt hat mit grub nichts zu tun. Seltsam ist aber das eine zurückgespielte Sicherung (mit MBR Rücksicherung per dd) vom Vortag (mit alter grub-Version) auch nicht mehr bootbar ist.
Ich habe das Problem etwas unkonventionell gelöst. Einfach mal schnell siduction neu installiert und das soeben frisch installierte System sofort wieder mit dem Backup von gestern überschrieben. Siehe da, die Kiste bootet wieder.
Das neue Grub-Paket macht irgendetwas am MBR, das auch eine Rücksicherung nicht beheben kann, sondern nur eine Neuinstallation.
EDIT: Mein eröffneter Debian Bugreport #741377 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741377)
Schön das du es so lösen konntest, kann es sein das mit dd der MBR nicht richtig hergestellt wird, mit Clonezilla hatte ich keine Probleme.
Quote from: DeKa on 2014/03/11, 21:38:01
Schön das du es so lösen konntest, kann es sein das mit dd der MBR nicht richtig hergestellt wird, mit Clonezilla hatte ich keine Probleme.
..scheint wohl so sein, allerdings hatte ich das Problem in dieser Form noch nie. Bisher konnte ich meine Rücksicherung (inkl. MBR Restore) erfolgreich einspielen. Letztendlich macht Clonezilla das auch nicht anderes als 1:1 Kopie der Partition zu erstellen und so wird sie auch wieder zurückgespielt (blockweise, kein gewöhnliches kopieren).
Das neue Grub-Paket macht irgendetwas am MBR, das auch eine Rücksicherung nicht beheben kann, sondern nur eine Neuinstallation.
Danke für die Warnung! Zum Glück habe ich noch andere Linuxinstallationen auf dem Rechner. Ich habe einfach mit F8 einen anderen MBR ausgewählt und Siduction von diesem gestartet.
Obwohl, gleich drauf gekommen bin ich da auch nicht. Ich wollte erst auch den Weg von Bluelupo gehen, aber die Installation (fromiso) brach mit nichtssagender Fehlermeldung ab (zum Glück).
Hi DeKa,
Hi gypsy56,
habt ihr euch mal die Antwort vom GRUB-Maintainer in meinem Bugreport angesehen (ganz unten), der inzwischen schon geschlossen wurde. Ich finde das schon bisschen komisch sich auf eine Fehlkonfiguration meinerseits heraus zureden. Wieso sollte ich beide Disks (sda und sdb) als bootbare Medien konfigurieren, das erschließt sich mir nicht ganz.
Vergiss Colin Watson - Er hat wie immer recht, natürlich nur in seiner Realität - und die muss nicht notwendigerweise mit unserer übereinstimmen.
<sarcasm>Ein Ubuntu-Mitarbeiter, ctte-Member und debian-Entwicker kann doch gar nicht vollkommen daneben liegen, das ist einfch nicht möglich ... </sarcasm>
EDIT: Wenn man das Verhalten natürlich noch mal sauber provizieren könnte, etwa mit einer reinen Sid-Installation in einer VM, dann sollte man einfach so nervig sein und den Fehler wieder öffnen.
Quote from: melmarker on 2014/03/12, 10:57:23Vergiss Colin Watson - Er hat wie immer recht, natürlich nur in seiner Realität -
Ganz allgemein - nicht nur CW - muss man sagen, dass Upstream Entwickler gerne Bugs abwiegeln. Man kann aber immer versuchen eine genauere Begründung zu liefern und manchmal sieht es Upstream dann auch, es ist ein Bug. (Vielleicht ist es also einfach ein praktisches Verhalten eines Entwicklers informativere Erklärungen zu bekommen, oder eben den Bug zu vergessen.)
Wenn der Mann Upstream-Entwickler wäre, wäre das recht tragisch für Grub. Der betreut das Paket in debian - das ist ein himmelweiter Unterschied.
EDIT: Ups, der mischt auch beim Upstream mit - aber eher im Bereich Dokumentation und kleinere Bugfixes. Sei's drum, trotzdem erschließt sich mir der Sinn des Geschwurbels in Antwort auf den Bug nicht. Zumal der Grub-Bugtracker was von LVM und double-free enthält - jetzt wäre ein log nett, ob der dort berichtete Fehler eventuell zuschlägt.
habt ihr euch mal die Antwort vom GRUB-Maintainer in meinem Bugreport angesehen (ganz unten), der inzwischen schon geschlossen wurde. Ich finde das schon bisschen komisch sich auf eine Fehlkonfiguration meinerseits heraus zureden. Wieso sollte ich beide Disks (sda und sdb) als bootbare Medien konfigurieren, das erschließt sich mir nicht ganz.
Hhmm, erschließt sich mir auch nicht. Wie fixe ich das Ding denn jetzt? Ich will ja nicht jedesmal F8 drücken. ;-) Mit grub-install dürfte das ja wohl nicht hinhauen. Muß ich jetzt downgraden, oder gibt es evtl. in 'Experimental' einen anderen Grub, der das Fehlverhalten nicht zeigt? Wenn nichts gefixt wurde, nützt ja auch eine höhere Version nichts.
Also downgraden und dann auf 'hold' setzen?
Eben gerade doch mal 'grub-install probiert. Hat den Fehler doch, wider Erwarten, gefixt. Das muß ich ja nicht verstehen. 8)
Hi gypsy56,
du hast direkt nach dem d-u ein "grub-install" ausgeführt oder hast via LiveSystem und chroot-Umgebung den "grub-install" abgesetzt?
Ich habe aus der chroot-Umgebung (weil das Kind ja schon in den Brunnen gfallen war) einen "dpkg-reconfigure grub-pc" angestossen - das hat aber nicht gebracht, d.h. das System blieb weiter unbootbar.
du hast direkt nach dem d-u ein "grub-install" ausgeführt oder hast via LiveSystem und chroot-Umgebung den "grub-install" abgesetzt
Nein! Ich bin über den MBR einer anderen Festplatte und eines anderen Linuxsystems direkt zu meiner Installation von Siduction gekommen. Dort, also in dem richtigen System, habe ich ein "grub-install /dev/sdxx" abgesetzt. Das hat hat gereicht, um den alten MBR wieder herzustellen. Konnte ich ja auch kaum glauben. ;-)
Nochmal zur Erklärung: ich habe 3 Festplatten und 3 Linuxsysteme, und alle 3 MBRs sind mit einem Grub2 eingerichtet, der alle 3 Systeme booten kann. Durch F8 vor dem Booten spare ich mir nur die Umstellung im BIOS und kann dann direkt von einem anderen MBR booten.
Ist jetzt hoffentlich etwas klarer. ;-)
Logisch ist das alles trotzdem nicht, denn das aktuelle Grub hat ja schließlich den MBR versaut. Und ein grub-install macht auch nicht mehr, als beim dist-upgrade gemacht wurde.
Jetzt habe ich das ganze nochmal probiert grub upzudaten. Leider wieder ohne Erfolg, d.h. ein d-u hinterlässt ein unbootbares System. Was habe ich getan?
1. d-u durchgeführt inkl. neuer grub Pakete
2. Reboot
3. System bleibt nach dem Bootscreen stehen in der initramfs (Fehler sinngemäß "/dev/disk/by-uid/<uuid> does not exist")
4. UUID der Rootpartition exisistiert bzw. ist korrekt (Kontrolle blkid)
5. Livesystem gestartet und mit chroot in das installierte System gewechselt
6. grub-install "apt-get install --reinstall grub-pc" (kein Fehler) und "dpkg-reconfigure grub-pc" ausgeführt (MBR auf /dev/sda markiert)
7. Livesystem herunter gefahren
8. installiertes System gestartet, wieder die gleiche Fehlermeldung
Danach habe ich ich mein System zurückgesichert, wobei der MBR mit dd zurückgeschrieben wurde. Erneutes Booten brachte wieder eine Fehlermeldung "error: symbol 'grub_isprint' not found" (noch vor dem Bootscreen). Jetzt eine Neuinstallation von siduction (hier wird natürlich der MBR auch geschrieben) und danach wieder Restore-Versuch. Wieder mit dd dem MBR zurückgeschrieben, das System bootet wieder.
Ein sehr seltsames Verhalten das ich mir nicht erklären kann. Hat jemand noch einen Tipp?
Ein sehr seltsames Verhalten das ich mir nicht erklären kann. Hat jemand noch einen Tipp?
Wenn Du mehr als eine Festplatte hast, kanst Du es ja auf die selbe Art wie ich versuchen:
Installiere Grub auch in den MBR der 2. Platte. Dann update auf den fehelerhaften Grub. Wenn dann wieder die Fehlermeldung kommt, gehst Du über den MBR der 2. Platte in Dein System. Dann "grub-install /dev/sdx". Danach sollte der Fehler verschwunden sein. So war es zumindest bei mir.
Quote from: gypsy56 on 2014/03/18, 07:32:29
Ein sehr seltsames Verhalten das ich mir nicht erklären kann. Hat jemand noch einen Tipp?
Wenn Du mehr als eine Festplatte hast, kanst Du es ja auf die selbe Art wie ich versuchen:
Installiere Grub auch in den MBR der 2. Platte. Dann update auf den fehelerhaften Grub. Wenn dann wieder die Fehlermeldung kommt, gehst Du über den MBR der 2. Platte in Dein System. Dann "grub-install /dev/sdx". Danach sollte der Fehler verschwunden sein. So war es zumindest bei mir.
Hi gypsy56,
Danke für deine Hinweise. Ich hatte bei meinem Versuchen von"dpkg -reconfigure grub-pc" tatsächlich immer nur sda angegeben. Wobei ich mir nicht sicher bin wenn ich die zweite Disk sdb angebe das Problem beheben wird, da ich den LVM benutze (auf beiden Disks, sda Systemplatte, sdb Datenplatte).
Bei einem Versuch von "dpkg -reconfigure grub-pc" hatte ich das LVM-Device auf sda (/dev/mapper/VGsys-LVroot) angeben das er aber anmeckerte, weil dort der MBR nicht geschrieben werden konnte. Darum wird mir mit ziemlicher Sicherheit auch die Angabe der zweiten Disk (auch ein LVM-Device) nicht weiter helfen. Außerdem würde ich mit dieser Daten-Platte sehr ungern ein Risiko eingehen.
Ich hatte dazu gestern noch eine Diskussion mit melmarker im Chat, der noch vorschlug die initramfs upzudaten mit "update-initramfs -u -k all". Es kann meiner Meinung nicht sein, das ich bei der Grub-Konfiguration, auf alle Platten im System meinen MBR schreiben muss um ein bootfähiges System zu erhalten. Genau dieses Verhalten ist scheinbar in der neuen Grub-Version so implementiert.
Bei einem Versuch von "dpkg -reconfigure grub-pc" hatte ich das LVM-Device auf sda (/dev/mapper/VGsys-LVroot) angeben das er aber anmeckerte, weil dort der MBR nicht geschrieben werden konnte. Darum wird mir mit ziemlicher Sicherheit auch die Angabe der zweiten Disk (auch ein LVM-Device) nicht weiter helfen. Außerdem würde ich mit dieser Daten-Platte sehr ungern ein Risiko eingehen.
Und wenn Du vorher die Platten im Bios vertauschst? Dann hat er ja keine andere Wahl, als diesen MBR zu nehmen...
Wenn ich bluelupo richtig verstehe, hat er das Problem ja schon gelöst, nur möchte er verstehen, warum dies auch mir nicht erklärliche Phenomen besteht. Ich würde auch gern wissen wollen was da das Problem ist.
Wenn ich bluelupo richtig verstehe, hat er das Problem ja schon gelöst,
Nach meinem Verständnis hat er das nicht. Er hat nur wieder ein arbeitsfähiges System mit dem älteren Grub. Wenn er den wieder updatet, steht er wieder vor dem Problem. Aber ja, ich würde auch gerne verstehen, was da im MBR passiert bei einem Update von Grub. Eigentlich dürfte da gar nichts passieren, d.h nur Version müßte ausgetauscht werden, aber leider scheint da noch mehr zu passieren.
Bei mir klappt das Update auf eine neuere Version auch nicht.
Habe auch zwei Linux-Systeme über einen MBR in betrieb, allerdings auf unterschiedlichen Festplatten (SSD+HDD).
@gypsy56: Wie hast du Grub im Einsatz, einzelne Installation und welche Version nutzt du aktuell?
@gypsy56: Wie hast du Grub im Einsatz, einzelne Installation und welche Version nutzt du aktuel
3 Linuxsysteme auf 3 verschiedenen Festplatten. Bei Siduction nutze ich den letzten Grub, der den MBR zerschießt.
Wenn man mindestens 2 MBRs mit Grub bestückt hat, ist es einfach den alten MBR wieder herzustellen. Einfach über einen anderen MBR Siduction booten. Be mir geht das über F8 problemlos, bei wem es nicht geht, der muß halt im BIOS umstellen. Und dann reicht ein "grub-inst /dev/sdx" um den alten MBR wieder herzustellen, zumindest ging das bei mir so.
Schreibe ich eigentlich so wirr, daß mich niemand versteht? Ich schreibe das jetzt doch schon mindestens zum 3. Mal.
Hi DeKa,
ich habe das Problem mit GRUB leider noch nicht gelöst, z.Zt. bin ich wieder auf der alten Version. Ich habe bereits zwei Versuche unternommen und beide sind fehlgeschlagen. Meine Vermutung ist, das GRUB in der neuen Version versucht auf die bisherige Disk mit dem MBR zu schreiben und dabei auf die Nase fällt. Bei mir kommt erschwerend hinzu das ich den LogicalVolumeManager (LVM) nutze was aber in der Vergangenheit bei einem Versionswechsel noch nie Schwierigkeiten bereitete.
@DeKa: Wir sollten versuchen unsere Gemeinsamkeiten bzgl. der Konfiguration feststellen und dann ggf. nochmal einen Bugreport bei Debian eröffnen. Poste mal deine Plattengeometrie (fdisk Output aller Disks im System).
Bluelupo: Da gabs mal was mit Deiner Fehlermeldung bei Ubuntu - der dortige TE hat dann, nach dem alle normalen Methoden des Behebens erschöpft waren, einen anderen Kernel installiert - das behob dann den Fehler in der Busybox. Is jetzt nur mal so ein Schnellschuss, aber einen Versuch wert, denke ich.
http://aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2764&highlight=
Hi @bluelupo,
hier meine fdisk Einträge:root@siductionbox:/home/deka# fdisk -l
Disk /dev/sdb: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d26e1
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 32770047 16384000 83 Linux
/dev/sdb2 32770048 250068991 108649472 83 Linux
Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000c83f8
Device Boot Start End Blocks Id System
/dev/sda1 2048 17000447 8499200 82 Linux swap / Solaris
/dev/sda2 * 17002496 58945535 20971520 83 Linux
/dev/sda3 58945536 143316991 42185728 83 Linux
/dev/sda4 143316992 1465147391 660915200 83 Linux
Quote from: towo on 2014/03/18, 14:58:26
http://aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2764&highlight=
Es steht leider keine Fehlernummer im aptosid-Forum, aber es könnte der hier sein (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735935). Ein Workaround wird auch genannt von Paul Martin am 15. März 2014:
Quote
A workaround is to edit /etc/default/grub and set
GRUB_DISABLE_LINUX_UUID=true
then run update-grub.
Ist allerdings keine Dauerlösung sondern nur ein
Workaround, denn damit wird die Benutzung der UUID's durch Grub abgeschaltet.
Vornweg, ich habe kein LVM.
Deshalb scheint mir auch bei DeKa, der freundlicherweise seine fdisk-Ausgabe hier einstellt, ein anderes in derartigen Situationen zu sein.
Hier meine:
fdisk -l -u -c
Disk /dev/sda: 1000.2 GB, 1000215724032 bytes
255 heads, 63 sectors/track, 121602 cylinders, total 1953546336 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0aac20df
Device Boot Start End Blocks Id System
/dev/sda1 2048 1953544191 976771072 7 HPFS/NTFS/exFAT
Disk /dev/sdd: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x1d371d36
Device Boot Start End Blocks Id System
/dev/sdd1 63 488392064 244196001 7 HPFS/NTFS/exFAT
Disk /dev/sdc: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0009fef1
Device Boot Start End Blocks Id System
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x2fce0819
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 41977855 20987904 83 Linux
/dev/sdb2 41979861 545406749 251713444+ 5 Extended
/dev/sdb5 41979904 74706943 16363520 82 Linux swap / Solaris
/dev/sdb6 74708992 281552895 103421952 b W95 FAT32
/dev/sdb7 281554944 323117055 20781056 83 Linux
/dev/sdb8 323119104 359362559 18121728 83 Linux
/dev/sdb9 359364608 397178879 18907136 83 Linux
/dev/sdb10 397180928 431874047 17346560 83 Linux
/dev/sdb11 431876096 452863999 10493952 83 Linux
/dev/sdb12 452866048 491671551 19402752 83 Linux
/dev/sdb13 491673600 512661503 10493952 83 Linux
/dev/sdb14 512663552 529036514 8186481+ 83 Linux
/dev/sdb15 529039360 545404927 8182784 83 Linux
Bei ihm haben beide Platten das boot-Flag.
Aus eigener Erfahrung ist das immer Mist im Zusammenspiel-Bios-Platte-Loader. Ich habe nirgendwo
gefunden, daß man das "unterschiedliche melden" der Platten beeinflussen kann. Und, das Bios sucht nun mal zuerst nach der Platte mit dem Flag...
Habe mal die Tipps hier ausprobiert, hier meine fdisk:
root@siductionbox:/home/deka# fdisk -l -u -c
Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000c83f8
Device Boot Start End Blocks Id System
/dev/sda1 2048 17000447 8499200 82 Linux swap / Solaris
/dev/sda2 17002496 58945535 20971520 83 Linux
/dev/sda3 58945536 143316991 42185728 83 Linux
/dev/sda4 143316992 1465147391 660915200 83 Linux
Disk /dev/sdb: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d26e1
Device Boot Start End Blocks Id System
/dev/sdb1 * 2048 32770047 16384000 83 Linux
/dev/sdb2 32770048 250068991 108649472 83 Linux
Diese Änderung bringt leider kein funktionsfähiges Update von Grub nach dessen Installation.
Restore System.
Habe dann noch einmal ein Update von Grub mit allen Einstellungen von dem Systemanbieter gemacht.
Der Neustart brachte die gleiche Fehlermeldung "grub highlightcolor", irgendwie findet er die Farbe nicht ???
Als durch den siduction Patch 2.02~beta2-7+siduction.1 bootet meine Kiste wieder.
grub-pc:
Installiert: 2.02~beta2-7+siduction.1
Installationskandidat: 2.02~beta2-7+siduction.1
Versionstabelle:
*** 2.02~beta2-7+siduction.1 0
500 http://packages.siduction.org/fixes/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
2.02~beta2-7 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
Und so sieht übrigens mein (LVM)System aus:
# fdisk -l /dev/sda
Disk /dev/sda: 120.0 GB, 120034123776 bytes
81 heads, 63 sectors/track, 45941 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xb6ab413a
Device Boot Start End Blocks Id System
/dev/sda1 2048 234441647 117219800 8e Linux LVM
# fdisk -l /dev/sdb
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x5ffd176a
Device Boot Start End Blocks Id System
/dev/sdb1 2048 976773167 488385560 8e Linux LVM
# pvs
PV VG Fmt Attr PSize PFree
/dev/sda1 VGsys lvm2 a-- 111,78g 59,28g
/dev/sdb1 VGdata lvm2 a-- 465,75g 195,75g
# vgs
VG #PV #LV #SN Attr VSize VFree
VGdata 1 6 0 wz--n- 465,75g 195,75g
VGsys 1 5 0 wz--n- 111,78g 59,28g
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Cpy%Sync Convert
LVmisc VGdata -wi-ao---- 60,00g
LVmusic VGdata -wi-ao---- 50,00g
LVphoto VGdata -wi-ao---- 50,00g
LVuserdata VGdata -wi-ao---- 10,00g
LVvideo VGdata -wi-ao---- 20,00g
LVvm VGdata -wi-ao---- 80,00g
LVhome VGsys -wi-ao---- 6,50g
LVroot VGsys -wi-ao---- 7,00g
LVswap VGsys -wi-ao---- 4,00g
LVvar VGsys -wi-ao---- 5,00g
LVvm VGsys -wi-ao---- 30,00g
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111,8G 0 disk
└─sda1 8:1 0 111,8G 0 part
├─VGsys-LVroot (dm-0) 254:0 0 7G 0 lvm /
├─VGsys-LVhome (dm-7) 254:7 0 6,5G 0 lvm /home
├─VGsys-LVvar (dm-8) 254:8 0 5G 0 lvm /var
├─VGsys-LVswap (dm-9) 254:9 0 4G 0 lvm [SWAP]
└─VGsys-LVvm (dm-10) 254:10 0 30G 0 lvm /mnt/vm/fast
sdb 8:16 0 465,8G 0 disk
└─sdb1 8:17 0 465,8G 0 part
├─VGdata-LVuserdata (dm-1) 254:1 0 10G 0 lvm /mnt/share/userdata
├─VGdata-LVmusic (dm-2) 254:2 0 50G 0 lvm /mnt/share/music
├─VGdata-LVphoto (dm-3) 254:3 0 50G 0 lvm /mnt/share/photo
├─VGdata-LVmisc (dm-4) 254:4 0 60G 0 lvm /mnt/share/misc
├─VGdata-LVvm (dm-5) 254:5 0 80G 0 lvm /mnt/vm/normal
└─VGdata-LVvideo (dm-6) 254:6 0 20G 0 lvm /mnt/share/videostream
sr0 11:0 1 1024M 0 rom
Hi @bluelupo,
leider hilft mir das nicht, habe beim upgrade ja schon die Patches die bei dir funktionieren, nur halt bei mir nicht.
root@siductionbox:/home/deka# apt-cache policy grub-pc
grub-pc:
Installiert: 2.00-22
Installationskandidat: 2.02~beta2-7+siduction.1
Versionstabelle:
2.02~beta2-7+siduction.1 0
500 http://packages.siduction.org/fixes/ unstable/main amd64 Packages
2.02~beta2-7 0
500 http://ftp2.de.debian.org/debian/ unstable/main amd64 Packages
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
500 http://ftp.is.debian.org/debian/ unstable/main amd64 Packages
*** 2.00-22 0
100 /var/lib/dpkg/status
root@siductionbox:/home/deka# apt-get install -s grub-pc
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
grub-common grub-efi-amd64-bin grub-pc-bin grub2-common
Vorgeschlagene Pakete:
multiboot-doc grub-emu xorriso desktop-base
Die folgenden Pakete werden aktualisiert (Upgrade):
grub-common grub-efi-amd64-bin grub-pc grub-pc-bin grub2-common
5 aktualisiert, 0 neu installiert, 0 zu entfernen und 1 nicht aktualisiert.
Inst grub-pc [2.00-22] (2.02~beta2-7+siduction.1 unstable [amd64]) []
Inst grub-pc-bin [2.00-22] (2.02~beta2-7+siduction.1 unstable [amd64]) []
Inst grub2-common [2.00-22] (2.02~beta2-7+siduction.1 unstable [amd64]) []
Inst grub-efi-amd64-bin [2.00-22] (2.02~beta2-7+siduction.1 unstable [amd64]) []
Inst grub-common [2.00-22] (2.02~beta2-7+siduction.1 unstable [amd64])
Conf grub-common (2.02~beta2-7+siduction.1 unstable [amd64])
Conf grub2-common (2.02~beta2-7+siduction.1 unstable [amd64])
Conf grub-pc-bin (2.02~beta2-7+siduction.1 unstable [amd64])
Conf grub-pc (2.02~beta2-7+siduction.1 unstable [amd64])
Conf grub-efi-amd64-bin (2.02~beta2-7+siduction.1 unstable [amd64])
Also kann man jetzt gefahrlos auf grub 2.02~beta2-7+siduction.1 updaten oder sollte man das erstmal noch lassen, wenn man mehrere Betriebssysteme und mehrere Platten hat?
@spacepenguin: Meinereiner hat da mal eine Verständnisfrage - war ein sid-upgrade je vollkommen gefahrlos? Meines Erachtens eigentlich nur, wenn dabei maximal eine nicht genutzte Schriftart in eine neue Version gebracht wird. Aber auch daran habe ich Zweifel. Weniger salopp:
* Grub2 ist jetzt in der Version, die slh für aptosid erstellt hat - er hat wohl auf einen Commit gesetzt, bei dem die bekannten Probleme nicht auftreten - ob damit für jeden alle Probleme beseitigt sind, wage ich mal ganz stark zu bezweifeln. Fakt ist, dass die neue Version erst einmal die Probleme von Bluelupo gelöst hat (LVM2)
* ich hab ein System mit mehreren Platten und Installationen, hatte aber keine Probleme zu berichten, was eventuell daran liegen mag, dass ich die Verwendung von UUIDs für meine Platten - so weit es in meiner Macht liegt - vermeide
* User mit einfachen Plattenkonfigurationen hatten wohl auch keine Probleme.
* bisher konnte mir noch niemand erklären, warum in Sid eine Beta-Version von Grub2 zu finden ist. Ich sehe darin erst mal keinerlei Sinn. Fragen zu diesem Thema könnte eventuell Colin Watson beantworten.
Die Zeit wirds also zeigen.
Also ich habe keine Probleme mit der Version 2.02~beta2-7 - die Frage ist halt, ob dann der Fix aus siduction eher schädlich ist?
Since installing today's d-u, which included a grub patch from the Siduction repository, I get a weird error when booting. I get the message "error: no such device: root", then, "Press any key to continue". When I press a key, the system boots, normally.
So, while this is not a major problem, it was introduced by today's patch.
Tim
Hallo zusammen,
Ich werde nochmal genau beobachten ob eine Fehlermeldung bei meinem (LVM)System mit dem gepatchten Grub auftritt und hier berichten. Was ich aus den entsprechenden Bugreports zu Grub bei Debian herauslesen kann, ist das UUID's insbesondere bei LVM-Konfigurationen verstärkt genutzt werden.
Zitat Colin Watson aus Bugreport #735935 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735935)
Quote
[...]
There are really not very many ways in which GRUB gets to affect the
behaviour of the running kernel. The most obvious one is the kernel
command line. Have you compared these before and after? IIRC we use
LVM UUIDs more aggressively in 2.02 than in 2.00; see e.g. commit
63653cfdae32648c93870fd36b2925346aa8ff36. I'm not exactly sure what
parts of userspace this relies on.
[...]
---------Translated with Google---------
Hi there,
I will again observe carefully whether an error message when my (LVM) system occurs with the patched Grub and report here. What I can deduce from the corresponding bug reports to Debian Grub is the UUID's are increasingly used especially in LVM configurations.
Quote from: timc on 2014/03/20, 01:44:37
Since installing today's d-u, which included a grub patch from the Siduction repository, I get a weird error when booting. I get the message "error: no such device: root", then, "Press any key to continue". When I press a key, the system boots, normally.
So, while this is not a major problem, it was introduced by today's patch.
This particular problem was cleared by today's (1-Apr) grub upgrade.
Tim