[gelöst] Eintrag für grub (Bootmenü) hinzufügen

[raiuns]

Liebe alle,

Ich habe einen Laptop mit mehreren Partitionen: 2x NTFS (Windows) und einmal Debian. Nach vergrößern der Debian-Partition ist grub (der PC) nicht mehr gestartet, nur noch bis "grub restore>"

Nach erfolglosen Versuchen der manuellen Grub-Reparatur musste ich einsehen, dass ich zu wenig Übung habe, und ich habe daraufhin die Debian-Partition wieder etwas verkleinert und danach noch ein kleines Debian (Standardinstallation von DVD) installiert.

Das hat funktioniert, und ich kann nun das alte Windows und das "kleine" Debian am Ende der Platte problemlos starten und benutzen. Ich kann auch die Partition vom ursprünglichen Debian unter "Dateien" sehen und ich sehe alle Dateien.

Um auch das "ursprüngliche" Debian wieder zu starten - reicht es, einen Eintrag im Grub-Menü zu erstellen? Wenn ja wie bzw. was muss ich tun ?

Ich frag lieber, nachdem ich gestern erfolglos viel Zeit mit Wikis und rescue-CDs verbracht habe..

[rendegast]

Hier ist der chroot-Weg ganz gut
https://wiki.manjaro.org/index.php/Rest ... Bootloader
geht dabei um die Mounts in das chroot.

Und hier eine nette Anleitung für die restore-Shell des grub
http://mintguide.org/system/186-repair- ... guyos.html
gegebenenfalls sollte auch das Modul linux geladen werden.

Auch, oder gerade
https://help.ubuntu.com/community/Grub2/Troubleshooting

[raiuns]

Danke für die Links, ich bin noch nicht sicher, ob ich das richtig verstanden habe, deshalb bitte ich um Kommentare:

1) Die Grub-Installation, die im Rahmen der normalen Installation von CD passiert, ändert den MBR -> somit weiß der Laptop, welche Partition er booten soll (bei mir ist das z.B. sda8)

2) In dieser Partition gibt es /boot/grub; und dort holt er sich den Rest von Grub sowie das eigentliche Grub-Menü (etc/default grub..) und zeigt es an

3) Außerdem sucht er bei der Standard-Installation von CD nach schon vorhandenen Betriebssystemen und fügt je eine Zeile in das Grub-Menü ein, damit man es starten kann. Dabei hat er Windows gefunden und richtig eingebunden (sda1 und sda2). Ich kann also wählen (und beide funktionieren) zwischen Windows und dem neuen "hilfs-"Debian.

4) meine alte Debian-INstallation in sda7 hat er wohl nicht erkannt, jedenfalls keine bei (3) keine Zeile hinzugefügt, so dass ich sie nicht über das Menü starten kann.

-> Wie füge ich die im Bootmenü hinzu?

[raiuns]

Hmm.. je mehr ich lese, desto mehr bin ich im Zweifel, ob das so einfach funktionieren wird mit 3 Systemen zum Start..

Ich werde wohl mal ein Backup aller Partitionen machen, dann nur noch die eine ("alte") Debian Partition auf de Platte behalten und schauen, ob sich dann der Bootloader/grub reparieren lässt, damit ich die booten kann..

Verwirrend kommt hinzu, dass teilweise von grub (legacy) und teilweise von grub2 als "grub" geschrieben wird, naja.

[rendegast]

1)
2)
3)

gut

Das 'grub rescue>' mit 'set root=..', 'set prefix=...' usw. hätte 2) wieder ermöglichen sollen.

Diese Situation ist mit der Hilfsinstallation obsolet.
Mich stört jetzt aber, daß das os-prober der Hilfsinstallation die alte Installation nicht "findet".
Existieren Besonderheiten? lvm, crypt o.ä.?

Code: Alles auswählen

fdisk -l
blkid | sort -V
file -s /dev/sd*

Dann bräuchte es gegebenenfalls weitere Pakete in der Hilfsinstallation,
zBsp. lvm2, mdadm (raid), ...

[raiuns]

Mich stört jetzt aber, daß das os-prober der Hilfsinstallation die alte Installation nicht "findet".
Existieren Besonderheiten? lvm, crypt o.ä.?

Danke für Dein Interesse!

Nein, keine Besonderheiten. Wenn ich (vor der Hilfsinstallation) grub installieren wollt, ging das immer schief mit der Fehlermeldung "unknown Filesystem". Fdisk zeigt aber ganz normal eine 83 (das ist wohl ext4). Ich will nicht ausschließen, dass mit der Partition etwas nicht stimmt, aber wie gesagt - nach dem Vergrößern hat sie funktioniert bis zum nächsten booten, und auch jettz, wenn ich sie mounte, sind alle Dateien da.

Ich will sie doch nur starten

Ich habe auch schon überlegt, Die Windows-Partitionen runterzunehmen und auf der Platte eine leere ext4-Partition zu erzeugen (sda1) und alles 'rüberzukopieren, also aus der Hilfsinstallation heraus als root

Code: Alles auswählen

mkdir msda1
mkdir msda7
mount /sda/sda1 msda1
mount /sda/sda7 msda7
cp -r msda7/* msda1/*

Und dann versuchen, grub da in sda1 wiederherzustellen. Ist das ein guter Weg? Ich bräuchte wohl eine schrittweise Hilfe. Aber andere Ideen (Partition prüfen / reparieren, ggf, wie?) sind mir auch willkommen - es sind halt immer ziemlich viele Daten auf einem nicht ganz so neuen Gerät zu kopieren, und das dauert..

PS: Die Statements oben kann ich erst heute abend laufen lassen..

[rendegast]

Wenn ich (vor der Hilfsinstallation) grub installieren wollt,

Wie sollte das vonstatten gehen?
'dpkg-reconfigure grub-pc' / 'dpkg-reconfigure grub-efi' / 'grub-install ...' / ....?

Nach vergrößern der Debian-Partition

Wie ist das abgelaufen?
Händisch? Mit einem Tool? Aus dem System heraus oder offline?
Das ändert aber erstmal nichts an der Partitionsstruktur (major/minor (sdXY), Partitions-ID (grub nicht betreffend), Dateisystem/-ID),
und das System hätte weiterhin starten sollen.



Die Hilfsinstallation oder ein live-System läuft eigentlich aufs Gleiche hinaus.
Maßnahme wäre benötigte Verzeichnisse ins gemountete Ziel-System mounten (/proc, /sys, /dev, usw.),
dann chroot in das Ziel-System.
Für das chroot sollte das Hilfs-/Life-System von gleicher Architektur und am besten irgendwie ähnlich sein (Ein live-sarge 32bit -chroot-> jessie 64bit ist nicht gut).
Im chroot am besten nur Notmaßnahmen durchführen,
wie zBsp. grub neu machen (efi / mbr), nur nötige beschädigte oder unbeabsichtigt gelöschte Pakete installieren/reparieren
(Fehlerhafte Konfigurationen korrigieren benötigt normalerweise kein chroot).
Dann Reboot ins Zielsystem.
Der Grund ist, daß die Mounts ins chroot, die ja eigentlich zum Hilfs-/Live-System gehören,
später meist nicht zurückgenommen werden können, was ein laufendes System in einem "Misch-Zustand" ergibt. Und das ist nicht wünschenswert.

[raiuns]

Wie sollte das vonstatten gehen?
'dpkg-reconfigure grub-pc' / 'dpkg-reconfigure grub-efi' / 'grub-install ...' / ....?

siehe hier: viewtopic.php?f=12&t=158202
Im vierten Beitrag ist ein Link - die dort verwendete Schrittfolge hab ich probiert.

Nach vergrößern der Debian-Partition ...
Wie ist das abgelaufen?
Händisch? Mit einem Tool? Aus dem System heraus oder offline?

Ich hab als root aufgerufen (aus dem laufenden System heraus) "resize2fs -p /dev/sda7" (maximal verfügbare Größe nutzen). Danach war die Partition größer und alles ok (hab auch weiter dran gearbeitet) - bis zum nächsten booten halt.

[raiuns]

Die Hilfsinstallation oder ein live-System läuft eigentlich aufs Gleiche hinaus.
Maßnahme wäre benötigte Verzeichnisse ins gemountete Ziel-System mounten (/proc, /sys, /dev, usw.),
dann chroot in das Ziel-System.
Für das chroot sollte das Hilfs-/Life-System von gleicher Architektur und am besten irgendwie ähnlich sein (Ein live-sarge 32bit -chroot-> jessie 64bit ist nicht gut).
Im chroot am besten nur Notmaßnahmen durchführen,
wie zBsp. grub neu machen (efi / mbr), nur nötige beschädigte oder unbeabsichtigt gelöschte Pakete installieren/reparieren
(Fehlerhafte Konfigurationen korrigieren benötigt normalerweise kein chroot).
Dann Reboot ins Zielsystem.
Der Grund ist, daß die Mounts ins chroot, die ja eigentlich zum Hilfs-/Live-System gehören,
später meist nicht zurückgenommen werden können, was ein laufendes System in einem "Misch-Zustand" ergibt. Und das ist nicht wünschenswert.

Ok, also Du empfiehlst mir, eine "normale" Installation von Debian8 auf eine ausreichend große Partition zu machen, und dann über das Hilfssystem in sda8 alle benötigen Daten von sda7 nach sda1 "drüberzukopieren"?

Also wenn ich jetzt einen neuen Reparatur-Anlauf nehme - was mache ich als Erstes?

[rendegast]

Ich habe den Weg dargelegt, den grub eines Systems per chroot neu zu setzen
(Mit eigenen Worten das aus den Links wiederholt).
Nix von Kopieren von einer Partition auf eine andere.
Und auch nix davon, ein weiteres System zu installieren.

Wie wäre es, mit super-grub-disk booten,
Dein System zum Start auswählen und darin grub neu setzen.
http://www.supergrubdisk.org
Etwas eleganter, als in der grub-shell des jetzt installierten grub des Hilfssystems die Optionen dafür händisch zu setzen (wenn auch mit Unterstützung der command-Completion).
Es braucht dafür eigentlich nur

Code: Alles auswählen

grub> linux (...)/.../vmlinuz..... root=/dev/...
grub> initrd (...)/.../initrd.....
grub> boot

------------------------------------
EDIT

Ich hab als root aufgerufen (aus dem laufenden System heraus) "resize2fs -p /dev/sda7" (maximal verfügbare Größe nutzen). Danach war die Partition größer und alles ok (hab auch weiter dran gearbeitet) - bis zum nächsten booten halt.

Das ist das Dateisystem.
Du erwähnst aber nicht, wie die Partition zu mehr verfügbarem Platz gekommen ist.

[raiuns]

Wie wäre es, mit super-grub-disk booten,
Dein System zum Start auswählen und darin grub neu setzen.
http://www.supergrubdisk.org

Das habe ich probiert, hat aber nicht funktioniert (Fehlermeldung, wenn ich das log richtig interpretiert habe: unknown filesystem). Vielleicht habe ich aber auch einen Fehler gemacht, aber es sah alles plausibel aus - zuerst wollte er die Partition wissen (sda7) und dann die Festplatte (sda). Ich werd mit mal eine neue supergrubdisk machen und es nochmal probieren.

Das ist das Dateisystem.
Du erwähnst aber nicht, wie die Partition zu mehr verfügbarem Platz gekommen ist.

Ach so ja - der war noch da (ungenutzter Speicherplatz direkt hinter der Partition). Ursprünglich wollte ich die mit gparted "aufziehen", das hatte bisher immer funktioniert, hier aber nicht.

[raiuns]

Also auch der "neue" rescatux verhält sich genauso, aber ich habe das installationslog, und gleich darunter die Ausgaben der o.g. Befehle (fdisk usw)

Ich hoffe, dass jemand damit etwas anfangen kann:

http://pastebin.com/1wED7V0p

[raiuns]

Hier die Ausgaben von fdisk usw noch mal extra - da muss man nicht so weit runter blättern..

http://pastebin.com/f3x1J8pq

[rendegast]

/dev/sda6 218181632 223234047 5052416 2,4G 82 Linux swap / Solaris
/dev/sda6: UUID="9f827b76-ba12-4bb5-b655-d0e042a5d0a0" TYPE="swsuspend" PARTUUID="23f12d67-06"

"swsuspend" ?
Ich arbeite nicht mit susp-to-disk, aber dieser Typ könnte ein Hinweis auf ein entsprechendes Speicherabbild sein.
Fragt sich nur von welchem System.

/dev/sda1 4096 118194175 118190080 56,4G 83 Linux
...
/dev/sda7 223236096 303466495 80230400 38,3G 83 Linux

Welches der beiden ist das debian?
Und wo ist der / sind die kernel versteckt?

Code: Alles auswählen

debugfs -R 'ls -l /' /dev/sda1
debugfs -R 'ls -l /boot' /dev/sda1
debugfs -R 'ls -l /' /dev/sda7
debugfs -R 'ls -l /boot' /dev/sda7

[raiuns]

... "swsuspend" ?
Ich arbeite nicht mit susp-to-disk, aber dieser Typ könnte ein Hinweis auf ein entsprechendes Speicherabbild sein.
Fragt sich nur von welchem System.

Muss wohl von sda7 sein, das Debian da hatte ich so eingestellt, dass ich beim Zuklappen des Laptops den Ruhezustand (hibernate) aktiviere. Hat auch funktioniert.

/dev/sda1 4096 118194175 118190080 56,4G 83 Linux
/dev/sda7 223236096 303466495 80230400 38,3G 83 Linux
Welches der beiden ist das debian?

sda7. Die andere Partition hatte ich nur testweise angelegt, weil ich dachte, ich könnte das System einfach da rein kopieren. Die kannst Du ignorieren. Debugfs kann ich dann wieder erst heute Abend aufrufen / werde berichten.

[raiuns]

Code: Alles auswählen

debugfs -R 'ls -l /' /dev/sda7
debugfs -R 'ls -l /boot' /dev/sda7

hier die Ausgaben (nur von sda7, weil sda1 nicht relevant)

Code: Alles auswählen

      2   40755 (2)      0      0    4096 12-Nov-2015 17:07 .
      2   40755 (2)      0      0    4096 12-Nov-2015 17:07 ..
     11   40700 (2)      0      0   16384 20-Feb-2014 09:08 lost+found
 103537   40755 (2)      0      0    4096 20-Feb-2014 10:24 var
  14465   40755 (2)      0      0   12288  9-Nov-2015 22:52 etc
  80209   40755 (2)      0      0    4096 17-Oct-2015 20:15 media
  14600  120777 (7)      0      0      29 17-Oct-2015 18:33 vmlinuz
 111617   40755 (2)      0      0    4096  8-Sep-2014 21:16 usr
  32817   40755 (2)      0      0   12288 20-Oct-2015 10:37 sbin
  66129   40755 (2)      0      0    4096 17-Oct-2015 14:13 lib
 1308161   40700 (2)      0      0    4096 10-Nov-2015 21:53 .config
  32825   40755 (2)      0      0    4096 17-Oct-2015 14:15 bin
  97042   41777 (2)      0      0    4096 12-Nov-2015 17:07 tmp
 145731   40755 (2)      0      0    4096 18-Jul-2013 05:10 sys
 145732   40755 (2)      0      0    4096 10-Nov-2015 20:31 run
     12   40700 (2)      0      0    4096 22-Oct-2015 16:17 root
  32858   40755 (2)      0      0    4096  7-Oct-2013 17:25 proc
 523266   40755 (2)      0      0    4096 17-Oct-2015 13:00 mnt
  32859   40755 (2)      0      0    4096 20-Feb-2014 12:24 home
     13   40755 (2)      0      0    4096 20-Feb-2014 09:11 dev
 145733   40755 (2)      0      0    4096 17-Oct-2015 18:50 boot
  80214   40755 (2)      0      0    4096 20-Feb-2014 09:09 srv
  97044   40755 (2)      0      0    4096 10-Jun-2015 22:53 opt
  14613  120777 (7)      0      0      33 17-Oct-2015 18:33 initrd.img
  14436  100600 (1)      0      0     256 20-Feb-2014 12:27 .pulse-cookie
  97045   40700 (2)      0      0    4096  3-Sep-2015 17:17 .pulse
 1831425   40700 (2)      0      0    4096 10-Nov-2015 21:53 .cache
     62  120777 (7)      0      0      28 20-Feb-2014 09:12 vmlinuz.old
     63  120777 (7)      0      0      32 20-Feb-2014 09:12 initrd.img.old
 1438977   40700 (2)      0      0    4096 10-Nov-2015 21:53 .local
    278  100644 (1)      0      0      66 10-Nov-2015 21:54 .selected_editor
    623  100600 (1)      0      0       6 10-Nov-2015 22:00 .nano_history

und

Code: Alles auswählen

 145733   40755 (2)      0      0    4096 17-Oct-2015 18:50 .
      2   40755 (2)      0      0    4096 12-Nov-2015 17:07 ..
 181360  100644 (1)      0      0   1670070 11-Oct-2015 21:29 System.map-3.2.0-4-686-pae
 181361  100644 (1)      0      0   134796 11-Oct-2015 21:29 config-3.2.0-4-686-pae
 158658   40755 (2)      0      0   12288 12-Nov-2015 17:07 grub
 233815  100644 (1)      0      0   162317 11-Oct-2015 22:01 config-3.16.0-4-686-pae
 181362  100644 (1)      0      0   2701024 11-Oct-2015 21:28 vmlinuz-3.2.0-4-686-pae
 150746  100644 (1)      0      0   10171007 17-Oct-2015 12:47 initrd.img-3.2.0-4-686-pae
 233816  100644 (1)      0      0   3013584 11-Oct-2015 22:00 vmlinuz-3.16.0-4-686-pae
 233814  100644 (1)      0      0   2093682 11-Oct-2015 22:01 System.map-3.16.0-4-686-pae
 131370  100644 (1)      0      0   14604687 17-Oct-2015 18:50 initrd.img-3.16.0-4-686-pae

[rendegast]

und
....
233816 100644 (1) 0 0 3013584 11-Oct-2015 22:00 vmlinuz-3.16.0-4-686-pae
..
131370 100644 (1) 0 0 14604687 17-Oct-2015 18:50 initrd.img-3.16.0-4-686-pae

Sollte sich direkt aufgerufen in der grub-shell eigentlich starten lassen.
Seltsam, daß sie vom os-prober der Hilfsinstallation oder der super-grub-disk nicht gefunden werden.

und das "kleine" Debian am Ende der Platte problemlos starten und benutzen. Ich kann auch die Partition vom ursprünglichen Debian unter "Dateien" sehen und ich sehe alle Dateien.

Das "kleine Debian am Ende der Platte", die Hilfsinstallation,
befindet sich nach Deinen Angaben aber am Anfang der Platte.

Egal, vom grub der Hilfsinstallation aus

Code: Alles auswählen

grub-shell> insmod part_msdos
grub-shell> insmod ext2
grub-shell>
grub-shell> linux (...)/boot/vmlinuz-3.16.0-4-686-pae  root=/dev/sda7  noresume  ...
grub-shell> initrd (...)/boot/initrd.img-3.16.0-4-686-pae
grub-shell> boot

(Hilfsmittel TAB-Completion) sollte das System starten.
Wegen der vorhandenen Links ginge wohl auch

Code: Alles auswählen

grub-shell> linux (...)/vmlinuz  root=/dev/sda7  noresume  ...
grub-shell> initrd (...)/initrd.img
grub-shell> boot

Weitere Reparaturen dann aus dem System heraus.

[raiuns]

ok, mein Prompt ist anders, nur "grub>" - und wenn ich nach "linux" (an der Stelle mit den (...) ) TAB drücke, komtm als Auswahl nur linux und linux16

Du meinst doch die Grub shell, die erscheint, wenn man gleich nach dem booten / Anzeige der Startzeilen ein "c" eingibt ?

oder anders?

[raiuns]

Das "kleine Debian am Ende der Platte", die Hilfsinstallation,
befindet sich nach Deinen Angaben aber am Anfang der Platte.

hmm - wenn man es mit gparted aus rescatux anschaut, sind sda8 und sda9 rechts (hinten).. aber ist ja auch egal.

Ich muß nachher nochmal weg, aber bin immer dankbar für Tips - es sieht ja aus als ob Du dicht dran wärst..

[rendegast]

und wenn ich nach "linux" (an der Stelle mit den (...) ) TAB drücke, komtm als Auswahl nur linux und linux16

Die Shell braucht die offene Klammer, um zu erkennen, daß sie jetzt blockdevices angeben soll:

Code: Alles auswählen

grub> linux (          <TAB>
-> Eine Liste von Platten
     hd0
     hd1
     hd2
...

Wonach entweder abgeschlossen wird
grub> linux (hd1) (weniger sinnvoll, aber das ist nicht die Aufgabe der Completion)
oder mit einem Komma weitergesucht

Code: Alles auswählen

grub> linux (hd1,       <TAB> 
-> eine Liste von Partitonen, zBsp.
     (hd1,msdos1)           
     (hd1,msdos2)           
     (hd1,msdos3)           
....

->

Code: Alles auswählen

grub> linux (hd1,msdos3)/       <TAB> 
-> eine Liste von Verzeichnissen
....
....

(falls grub dieses Dateisystem lesen kann,
gegebenenfalls muss ein grub-Modul nachgeladen werden, zBsp. 'insmod btrfs')
usw.

Die (hdX,msdosY) sind dabei erstmal Plain-Partitionen
(in dem Fall die einer DOS-Partitionierung, und unter grub2.
Bei grub1 war es in der Form '(hdX,Y)').
Mit entsprechend geladenen Modulen können auch raid- oder lvm-"Partitionen" aufgelöst resp. angesprochen werden.
-> Umsehen in /boot/grub/*/*mod (früher /boot/grub/*.mod).
Aktuellste Doku wohl in https://www.gnu.org/software/grub/.

[raiuns]

Danke für die Erläuterungen, jetzt hab ich es kapiert! (wieder was gelernt

Er sagt aber auch da "unbekanntes Filesystem" - ich hab mal ein Foto gemacht:

[rendegast]

Böses, böses grub.

Das einzig erklärende bisher könnte

/dev/sda7: Linux rev 1.0 ext4 filesystem data, UUID=1d20cde8-3b79-4699-97a5-555204b4aff8 (extents)
/dev/sda8: Linux rev 1.0 ext4 filesystem data, UUID=32a92cda-4f13-46f5-ad9b-2c14bbdf87c2 (needs journal recovery) (extents) (large files) (huge files)

Wenn ich das mit einem frisch formatierten Image probiere, bekomme ich

Code: Alles auswählen

# mkfs.ext4 -F /dev/loop0
mke2fs 1.42.12 (29-Aug-2014)
/dev/loop0 contains a ext4 file system
        created on Sat Nov 14 21:27:24 2015
Discarding device blocks: done                            
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 999fa66a-05ba-496c-9020-022a5cf444c7
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

# file -s /dev/loop0
/dev/loop0: Linux rev 1.0 ext4 filesystem data, UUID=999fa66a-05ba-496c-9020-022a5cf444c7 (extents) (large files) (huge files)

# tune2fs -O ^huge_file,^large_file /dev/loop0
tune2fs 1.42.12 (29-Aug-2014)

Please run e2fsck on the filesystem.

# e2fsck -f /dev/loop0
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Filesystem contains large files, but lacks LARGE_FILE flag in superblock.
Fix<y>? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/loop0: ***** FILE SYSTEM WAS MODIFIED *****
/dev/loop0: 11/65536 files (0.0% non-contiguous), 12635/262144 blocks

# file -s /dev/loop0
/dev/loop0: Linux rev 1.0 ext4 filesystem data, UUID=999fa66a-05ba-496c-9020-022a5cf444c7 (extents) (large files)

das large_file nicht weg!?

Egal, wenn aber ein laufendes System resp. der Kernel wohl damit zurecht kommt:
- Kopieren von vmlinuz und initrd auf eine erreichbare Position, zBsp. die Partition des Hilssystems.
Oder sogar in das /boot/ des Hilfssystems, dann 'update-grub'.
- Nun muß beim nächsten Start der Eintrag mit diesem Kernel nur mehr editiert werden: "root=......." -> "root=/dev/sda7".
In den Editiermodus des Grub-Menü mit 'e'
(statt wie mit 'c' in den Kommandomodus), booten des editierten Eintrags mit F10 oder CTRL-x.




Ein fsck auf sda7 wäre vielleicht auch mal durchzuführen.

[raiuns]

Ein fsck auf sda7 wäre vielleicht auch mal durchzuführen.

[/quote]

also aus dem Hilfssystem heraus, so wie Du es gemacht hast? (# e2fsck -f /dev/sda7) ? Ich dachte ich hätte das schonmal gemacht, aber ich hab inzwischen so viel ausprobiert..

das large_file nicht weg!?

Na es tröstet mich ein bischen, dass bei Dir auch nicht alles perfekt funktioniert

- Kopieren von vmlinuz und initrd auf eine erreichbare Position, zBsp. die Partition des Hilssystems.
Oder sogar in das /boot/ des Hilfssystems, dann 'update-grub'.

Mach ich gerne, aber nur so als Frage: Wenn beides Debian Jessie ist mit Updatestand ungefähr Ende Oktober 2015, sollten die dann nicht gleich sein? Oder stehen da partitionsspezifische Daten drin? (USerdaten ja wohl nicht..)

- Nun muß beim nächsten Start der Eintrag mit diesem Kernel nur mehr editiert werden: "root=......." -> "root=/dev/sda7".
In den Editiermodus des Grub-Menü mit 'e'
(statt wie mit 'c' in den Kommandomodus), booten des editierten Eintrags mit F10 oder CTRL-x.

Ich hab mal in die Einträge reingeschaut, wahrscheinlich muss ich "hd0,msdos8" in "hd0,msdos7" ändern. Aber bevor ich loslege warte ich nochmal, ob ich alles richtig verstanden habe..

[rendegast]

wahrscheinlich muss ich "hd0,msdos8" in "hd0,msdos7"

Nein, das ist das root des grub resp. bestimmt den Ort des zu ladenden Kernels (auf der verfügbaren Hilfssystem-Partition).
Ich meine die Angabe 'root=' in der Kernel-Commandline 'linux ......' für das root des zu startenden Systems.
Das 'root=UUID=....' in 'root=/dev/sda7' zu ändern geht imo flotter als die Einträge mit tab-Completion zu konstruieren.
Das 'noresume' im Hinterkopf behalten.
Erst der startende Kernel öffnet dann das Dateisystem in sda7.




Ein extX, welches mit den anderen Mitteln (file, blkid, mount) zugänglich,
unter grub aber "unbekannt" ist.
Hatten wir hier schonmal? Wie im google suchen?
Ein Fehler im ext2-Modul des grub? Ein Fehler im verwendeten resize-Tool?
Für zweiteres sprächen die zumindest zwei(?) verschwundenen ext4-Features.

Im Hilfssystem vielleicht mal grub-pc / grub-efi aus testing/sid versuchen?
Oder die Alternative extlinux? (noch nie benutzt, keine Erfahrung)

http://ubuntuforums.org/showthread.php?t=1374315
von 2010 sieht diesem ähnlich und wurde durch Einsatz einer boot-Partition unterhalb von 137GB gelöst.
Das sollte aber heute obsolet sein.

[raiuns]

Hurra, da ist sie wieder!

Ich schreibe schon von meinem "guten alten" Debian aus. Also Was ich gemacht hab:

- Hilfssystem gebootet, /dev/sda7 nach msda7 gemounted
- gewechselt nach /boot und dann als root

Code: Alles auswählen

cp /home/kannweg/msda7/boot/in*3.16* .
cp /home/kannweg/msda7/boot/vm*3.16* .

danach *arrgh* update-grub vergessen und gebootet, "e" gedrückt und die Zeile, die mit "linux anfängt, editiert ab "root=" (da stand eine UUID drin)

STRG-X gedrückt - gebootet (mal sehen welches Debian startet) - und gefreut.

Was ist noch zu reparieren?