Willkommen Gast. Bitte einloggen oder registrieren. Haben Sie Ihre Aktivierungs E-Mail übersehen?
03.08.2021, 22:34:56

.
Einloggen mit Benutzername, Passwort und Sitzungslänge

Mitglieder
  • Mitglieder insgesamt: 25802
  • Letzte: Duffman
Statistiken
  • Beiträge insgesamt: 748100
  • Themen insgesamt: 60185
  • Heute online: 557
  • Am meisten online: 2287
  • (22.01.2020, 19:20:24)
Benutzer Online

Autor Thema:  LMDE 4 startet nach Installation von LIVE-DVD / USB-Stift nicht von SSD  (Gelesen 1080 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Guten Tag!

Den Hinweis vom gestrigen 20.07.2021 / 22:31:09 Uhr beachtend, habe ich die bisherige SSD-Fesplatte wieder in das Gerät eingebaut und die selbe Routine wie gestern angewandt.


Vorbemerkung:

A) Auf dieser SSD war zunächst ein mit Acronis ATI 2021 erfolgreich wiederhergestelltes WIN-7 64-Bit Ulitimate installiert worden; im UEFI/GPT-Modus. Dieses System startete von der SSD und lief auf der Maschine Toshiba TECRA R950 problemlos.
B) Das System LMDE-4 läuft von einem USB-Stift (Ventoy Vers. 1.0.46 + LMDE-4.ISO) als LIVE-System ebenfalls unproblematisch.
C) Nach Installation von LMDE-4 auf die SSD startete weder Windows, noch LINUX noch erschien ein Menü eines Boot-Managers.
D) Es erscheint – ohne LAN-Anschluß – die Fehlermeldung: „Insert system disk in drive. / Press any key when ready....“.
E) Es erscheinen – mit LAN-Anschluß – die Meldungen: 1. „>>Start PXE over IPv6. / PXE-E99: Unexpected network error.“ 2. gefolgt von: >>Start PXE over IPV4. ...“ Um das Problem näher und unabhängig von WINDOWS einzugrenzen, habe ich mich entschlossen LINUX LMDE-4 zunächst separat auf einer neu formatierten HDD zu installieren; die Maschine blieb unverändert (Toshiba TECRA R950) – die Installation erfolgte wieder von einem LIVE-System, das von einem USB-Stift gestartet wurde, mit „Ventoy“ Version 1.0.46 und einer LMDE-4.ISO konfiguriert war. – Das Fehlerverhalten nach Installation war dasselbe wie bei der Installation MIT Windows 7 ...

Jetzt die Abfrage-Ergebnisse (LMDE installiert auf: „sda11“)

1. sudo mount /dev/sda11 /mnt && sudo cat /mnt/etc/fstab && sudo umount /mnt

mint@mint:~$ sudo mount /dev/sda11 /mnt && sudo cat /mnt/etc/fstab && sudo umount /mnt
# UNCONFIGURED FSTAB FOR BASE SYSTEM
proc    /proc   proc    defaults        0       0
# /dev/sda1
UUID=4925-4785  /boot/efi       vfat    defaults        0       0
# /dev/sda11
UUID=fafe1d64-ac4f-44ee-9b15-94f8683b711a       /       ext4    rw,errors=remount-ro    0       1

2. sudo parted -l

mint@mint:~$ sudo parted -l
Model: ATA TOSHIBA THNSNJ25 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system  Name                  Flags
 1      1049kB  106MB  105MB   fat32                              boot, esp
 3      106MB   106GB  106GB   ntfs                               msftdata
11      106GB   118GB  11,8GB  ext4
 2      118GB   215GB  96,6GB  ntfs                               msftdata
 4      215GB   218GB  3221MB  ntfs                               msftdata
 5      218GB   221GB  3221MB  ntfs                               msftdata
 6      221GB   225GB  3221MB  ntfs                               msftdata
 7      225GB   230GB  5371MB  ntfs                               msftdata
 8      230GB   251GB  21,5GB  ntfs                               msftdata
 9      251GB   252GB  1078MB  ntfs                               msftdata
10      252GB   256GB  3578MB  ntfs         Basic data partition  msftdata


Model: Intenso Basic Line (scsi)
Disk /dev/sdb: 15,5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name       Flags
 1      1049kB  14,4GB  14,4GB               VentoyISO  msftdata
 2      14,4GB  14,4GB  33,6MB  fat16        VTOYEFI    hidden, msftdata
 3      14,4GB  15,5GB  1073MB  ntfs                    msftdata


Model: USB Flash Disk (scsi)
Disk /dev/sdc: 4050MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      12,3kB  4050MB  4050MB  primary  fat32        boot, lba


Model: SD ED4QT (sd/mmc)
Disk /dev/mmcblk0: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End    Size   Type     File system  Flags
 1      16,8MB  128GB  128GB  primary  ntfs

3. [ -d /sys/firmware/efi ] && echo UEFI || echo "legacy"

mint@mint:~$ [ -d /sys/firmware/efi ] && echo UEFI || echo "legacy"
UEFI

Nach dieser Abfrage wurde die Aufgabe vom 13.07.2021 abgearbeitet

4. sudo mount /dev/sda11 /mnt

5. sudoedit /mnt/etc/default/grub

Ergebnis:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=15
GRUB_TIMEOUT_STYLE=menu
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'


6. cat /mnt/boot/grub/grub.cfg > grub.txt

Die Anfrage folgendes Ergebnis: Siehe Anhang

7. Zusätzlich wurde auch noch die „grub.cfg“ in der Boot-Partition abgefragt (Ort: „sda1/EFI/debian/grub.cft“).

search.fs_uuid fafe1d64-ac4f-44ee-9b15-94f8683b711a root hd0,gpt11
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg

8. sudo efibootmgr -v

mint@mint:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0000,0001,0007,0005
Boot0000* USB Memory    PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)
Boot0001* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0002* ODD   PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,1,0)
Boot0003* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0004* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0005* LAN2  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0006* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0007* LAN1  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv6([::]:<->[::]:,0,0)

9. Der Befehl "sudoedit /mnt/etc/default/grub" wurde nach einem Neustart nochmals für sda11 aufgerufen. Die unter 5. eingefügte Befehlszeile "GRUB_TIMEOUT_STYLE=menu" war noch vorhanden.


Der Befehlsablauf scheint keine Fehler aufzuweisen.

Ich bitte um Mitteilung,
a) ob die hier nunmehr angegebene Befehlsabläufe der SSD Fehler enthalten, die eine Start des Systems unterbrechen;
b) sich Unterschiede im Befehlsablauf von HDD (Installation auf SDA3) und SSD (Installation auf SDA11) ergeben;
c) welche weiteren Analysen erforderlich sind, falls ein Fehler nicht auffindbar war.

Vielen Dank für die Bemühungen!

Raimund Frank

(Selbstgespräch, schleierhaft, warum da kein Eintrag im NVRAM steht)

@ Raimund Frank, mach doch mal ein
sudo efibootmgr --create --disk /dev/sda --part 1 --label "LMDE 4 Debbie" --loader \\EFI\\ubuntu\\grubx64.efi
Prüfe aber vorher, ob in der ESP auch das Verzeichnis efi/ubuntu steht, einfach im LiveSystem mit
Korrektur:
 sudo mount /dev/sda1 /mnt && sudo ls -R /mnt && sudo umount /mnt Falls es anders benannt ist ("ubuntu"),dann eben das im obigen Befehl einsetzen.
« Letzte Änderung: 21.07.2021, 18:32:32 von g.rubienne »

Off-Topic:
Nur als TIP:

Wir sind hier bei LMDE4 --> Linux Mint Debian Edition, also heißt das Verzeichnis in der EFI - Partition "debian".
Sieh meine Anleitung: https://www.linuxmintusers.de/index.php?action=wiki;page=Installation_von_LMDE4
Das ist so bei Cinnamon, Mate, Xfce(64 Bit) und auch LXDE der deutschsprachigen ISO's von DeVIL-I386 und Xfce(64) von dphn.
Aber auch der englischen Original ISO mit Cinnamon von Clément Lefèbvre.
« Letzte Änderung: 21.07.2021, 20:05:31 von tommix »

Guten Morgen!

@g.rubinne

1. "(Selbstgespräch, schleierhaft, warum da kein Eintrag im NVRAM steht)" - Diese Bemerkung verstehe ich nicht?

Ist damit die (fette) Zeile gemeint?

mint@mint:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0002,0000,0001,0007,0005
Boot0000* USB Memory    PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)
Boot0001* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0002* ODD   PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,1,0)
Boot0003* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0004* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0005* LAN2  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0006* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0007* LAN1  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv6([::]:<->[::]:,0,0)

Boot0001* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)

Welche Bedeutung hat diese Zeile?

Welche Termini sollte diese Zeile im NVRAM enthalten?

2. Hier die gewünschte Auskunft - da ich eine deutsche LMDE-4 Installation verwendete, ist "debian" im EFI gesetzt.

mint@mint:~$ sudo mount /dev/sda1 /mnt
mint@mint:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0   1,8G  1 loop /lib/live/mount/rootfs/filesystem.squashfs
sda           8:0    0 238,5G  0 disk
├─sda1        8:1    0   100M  0 part /mnt
├─sda2        8:2    0    90G  0 part
├─sda3        8:3    0    99G  0 part
├─sda4        8:4    0     3G  0 part
├─sda5        8:5    0     3G  0 part
├─sda6        8:6    0     3G  0 part
├─sda7        8:7    0     5G  0 part
├─sda8        8:8    0    20G  0 part
├─sda9        8:9    0     1G  0 part
├─sda10       8:10   0   3,3G  0 part
└─sda11       8:11   0    11G  0 part
sdb           8:16   1  14,5G  0 disk
├─sdb1        8:17   1  13,4G  0 part
│ └─ventoy  254:0    0     2G  1 dm   /media/mint/LMDE 4 Cinnamon 64-Bit
├─sdb2        8:18   1    32M  0 part /media/mint/LMDE 4 Cinnamon 64-Bit
└─sdb3        8:19   1  1023M  0 part /media/mint/Ventoy_DAT
sdc           8:32   1   3,8G  0 disk
└─sdc1        8:33   1   3,8G  0 part /media/mint/USB2_H_003
sr0          11:0    1  1024M  0 rom 
mmcblk0     179:0    0 119,3G  0 disk
└─mmcblk0p1 179:1    0 119,2G  0 part /media/mint/SYS_SIC_S1
mint@mint:~$ ls
Bilder  Desktop  Dokumente  Downloads  Musik  Öffentlich  Videos  Vorlagen
mint@mint:~$ cd /mnt
mint@mint:/mnt$ ls
EFI
mint@mint:/mnt$ ls -R
.:
EFI

./EFI:
debian

./EFI/debian:
BOOTX64.CSV  fbx64.efi  grub.cfg  grubx64.efi  mmx64.efi  shimx64.efi

3. Meine Conclusio: Die Art der Festplatte (HDD / SSD) mit Systemen (mit WIN-7 / ohne WIN-7) mit unterschiedlichen Partitionen (LMDE-4 auf sda11 oder sda3) - spielt bei dieser Fehlinstallation keine Rolle: In beiden Fällen startet das LINUX-System nicht! Vielmehr kann auch nach der Installation von LMDE-4 auf WIN-7 nicht mehr zugegriffen werden. Ein Bootmanager erscheint nicht.

4. Beim Start der Maschine wird ein kurzer zweimaliger Zugriff auf die jeweilige Platte (HDD oder SSD) per Leuchtdiode signalisiert, danach erscheint die Fehlermeldung, daß kein System existiert. Ich folgere daraus, daß die Befehlsübergabe an irgend einer Stelle hängt:
a) entweder wird der NVRAM durch die Installation falsch manipuliert - Vorschlag: Ich sollte die HDD, auf der derzeit nur LINUX installiert ist "plattmachen", meine ATI-2021 Sicherung von WIN-7 wiederherstellen und dann mit LMDE-4 LIVE den NVRAM auslesen ... danach LMDE-4 zusätzlich installieren und danach nochmals den NVRAM auslesen. - Ich erinnere mich, irgend wo gelesen zu haben, daß es UEFI/BIOS-Ausgaben gibt, die eine LINUX-Installation nicht zulassen. Andererseits startet LMDE-4 LIVE sowohl von USB als auch von DVD; die Maschine lehnt also LMDE-4 nicht generell ab ...
b) Die Grub.cfg auf sda1 (mein letzter Eintrag vom 21.07.2021 / 17:16:39) sollte korrekt auf die sda11 (LMDE-4-Partition) verweisen. Ist das richtig?
c) Wie Prüfe ich die Befehlsübergabe NVRAM ==> sda1/grub.cfg ==> sda11/grub.cfg?
d) Ist die grub.cfg auf sda11 richtig konfiguriert?

@tommix

Der Verweis auf Deine Anleitung ist mir bekannt - ich habe die Installationsroutine so auf mehreren Platten (SSD / HDD - mit und ohne WIN-7) sowohl mit USB (Ventoy / LMDE-4_DE.ISO) als auch ODD / DVD (LMDE-4_DE) angewendet: "Fehlerfreie Installation". Starten konnten ich LMDE-4 nicht: Es wurde jedesmal die Fehlermeldung angezeigt, daß kein System existiere und dann versucht (da kein USB-Stift gesteckt und keine DVD eingelegt war) die Maschine über LAN zu starten ...

Offensichtlich handelt es sich hier um eine grundsätzlicheres Problem ...

Immerhin habe ich jetzt viel dazugelernt ... die Nutzung des Terminals gelingt mir immer besser. Es ist nur aufwendig, jedesmal das LIVE-System zu nutzen, wenn man z. B. den "Feuerfuchs" konfigurieren muß. Aber auch hier habe ich Abhilfe geschaffen: Ich habe das Profil auf "mmcblk0p1" gesichert und kopiere es einfach beim Neustart des LIVE-Systems ... aber nur so lange, bis LMDE-4 endlich von der Platte startet! Kriegen wir das hin?

Gruß

Raimund Frank

Guten Morgen!

einen ebensolchen zurück
Zitat
@g.rubinne

1. "(Selbstgespräch, schleierhaft, warum da kein Eintrag im NVRAM steht)" - Diese Bemerkung verstehe ich nicht?

Ist damit die (fette) Zeile gemeint?
nein, und es war ein Selbstgespräch!
Nach einer Linux (LM/LMDE) Installation (im EFI Modus) oder Windows wird gewöhnlich eine Eintrag à la
Boot0004* ubuntu HD(2,MBR,0xd9b86ead,0x100800,0x100800)/File(\EFI\ubuntu\shimx64.efi)
Boot001B  Windows Boot Manager HD(2,GPT,d03c5425-0084-4379-8fdd-87514256343a,0x1000,0x20000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
(an die Profis: nicht wundern,ist von verschiedenen Systemen)
Zitat
Boot0001* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)

Welche Bedeutung hat diese Zeile?

Welche Termini sollte diese Zeile im NVRAM enthalten?
die wird sicherlich vom UEFI erzeugt, ebenso wie dort alle anderen (sind die Geräte USB, DVD, HDD etc.)
Zitat
2. Hier die gewünschte Auskunft - da ich eine deutsche LMDE-4 Installation verwendete, ist "debian" im EFI gesetzt.

mint@mint:~$ sudo mount /dev/sda1 /mnt

mint@mint:~$ lsblk
ff.
...
(hatte keiner angefragt, macht das hier nur unübersichtlicher, meine Anfrage – mit der von @tommix aufgezeigten Richtigstellung – hättest du auch gleich den richtigen Eintrag erzeugen können)

Also dann:
sudo efibootmgr --create --disk /dev/sda --part 1 --label "LMDE 4 Debbie" --loader \\EFI\\debian\\grubx64.efi
Was mich allerdings weiterhin erstaunt, auch für Windows gibt es keinen Eintrag im NVRAM, obwohl hier offensichtlich ein Windows auf einer GPT partitionierten Platte installiert ist; eigentlich ein Ding der Unmöglichkeit! Da in der ESP kein …/Windows… vorhanden ist, weiß ich leider nicht, wie man Windows hier booten kann. Im Startpost gab es mal eine /dev/sda2 mit der Markierung, die war die ESP (hat jetzt aber die Markierung "msftdata"). Die ESP ist jetzt plötzlich sda1 (!)

zeige einfach auch mal
sudo mount /dev/sda2 /mnt && sudo ls -R /mnt && sudo umount /mnt

Heute zum Zweiten!

Zuerst habe ich die sda2 abgefragt:

mint@mint:/$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt
.:
bin   dev  home        initrd.img.old  lib64  mnt  proc  run   srv  tmp  var      vmlinuz.old
boot  etc  initrd.img  lib             media  opt  root  sbin  sys  usr  vmlinuz

./bin:
bash                dmesg          live-config         ntfsinfo      systemd-ask-password
brltty              dnsdomainname  live-config-update  ntfsls        systemd-escape
btrfs               domainname     live-swapfile       ntfsmove      systemd-hwdb
btrfsck             dumpkeys       ln                  ntfsrecover   systemd-inhibit
btrfs-find-root     echo           loadkeys            ntfssecaudit  systemd-machine-id-setup
btrfs-image         ed             login               ntfstruncate  systemd-notify
btrfs-map-logical   efibootdump    loginctl            ntfsusermap   systemd-sysusers
btrfs-select-super  efibootmgr     lowntfs-3g          ntfswipe      systemd-tmpfiles
btrfstune           egrep          ls                  openvt        systemd-tty-ask-password-agent
bunzip2             false          lsblk               pidof         tar
busybox             fgconsole      lsmod               ping          tempfile
bzcat               fgrep          mkdir               ping4         touch
bzcmp               findmnt        mkfs.btrfs          ping6         true
bzdiff              fsck.btrfs     mknod               plymouth      udevadm
bzegrep             fuser          mktemp              ps            ulockmgr_server
bzexe               fusermount     more                pwd           umount
bzfgrep             getfacl        mount               rbash         uname
bzgrep              grep           mountpoint          readlink      uncompress
bzip2               gunzip         mt                  red           unicode_start
bzip2recover        gzexe          mt-gnu              rm            vdir
bzless              gzip           mv                  rmdir         wdctl
bzmore              hciconfig      nano                rnano         which
cat                 hostname       nc                  run-parts     ypdomainname
chacl               ip             nc.openbsd          sed           zcat
chgrp               journalctl     netcat              setfacl       zcmp
chmod               kbd_mode       netstat             setfont       zdiff
chown               keyctl         networkctl          setupcon      zegrep
chvt                kill           nisdomainname       sh            zfgrep
cp                  kmod           ntfs-3g             sleep         zforce
cpio                less           ntfs-3g.probe       ss            zgrep
dash                lessecho       ntfscat             stty          zless
date                lessfile       ntfscluster         su            zmore
dd                  lesskey        ntfscmp             sync          znew
df                  lesspipe       ntfsfallocate       systemctl
dir                 live-boot      ntfsfix             systemd

./boot:
config-4.19.0-8-amd64  grub  memtest86+.bin  memtest86+_multiboot.bin  System.map-4.19.0-8-amd64

./boot/grub:
fonts  themes  unicode.pf2

./boot/grub/fonts:
UbuntuMono16.pf2

./boot/grub/themes:
linuxmint

./boot/grub/themes/linuxmint:
background.png  item_c.png  select_c.png         select_e.png  terminal_box_c.png
icons           LICENSE     selected_item_c.png  select_w.png  theme.txt

... den Rest spare ich mir - es ging noch seitenweise so weiter. Um nur die Verzeichnisse abzurufen wollte ich den Befehl "sudo ls -d" ausführen - das wurde nicht umgesetzt und stattdessen eine Fehlermeldung angezeigt. Darum habe ich den "sudo ls -R"-Befehl nochmals exikutiert (um das Ergebnis in eine Textdatei zu übertragen) - erhielt aber ein völlig anderes Ergebnis:

mint@mint:~$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt
.:
 Bilder    Dokumente   gz13761   Öffentlich                         Videos
 Desktop   Downloads   Musik    &apos;tname nc run-parts ypdomainname&apos;   Vorlagen

./Bilder:

./Desktop:
debian-installer-launcher.desktop

./Dokumente:

./Downloads:
zoom_amd64.deb

./Musik:

./Öffentlich:

./Videos:

./Vorlagen:

Ist das nicht seltsam? - Nach Einstein soll man nicht auf ein anderes Ergebnis hoffen, wenn man dasselbe tut - aber LINUX macht's möglich!?

Hier die Resultate des Befehls "efibootmgr" (ich habe danach gleich ein "sudo efibootmgr -v" ausgeführt):

mint@mint:~$ sudo efibootmgr --create --disk /dev/sda --part 1 -- label "LMDE 4 Debbie" -- loader \\EFI\\debian\\grub64.efi
mint@mint:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0008,0002,0000,0001,0007,0005
Boot0000* USB Memory    PciRoot(0x0)/Pci(0x14,0x0)/USB(0,0)
Boot0001* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0002* ODD   PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,1,0)
Boot0003* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0004* LAN1  BBS(128,p�,0x0)........................A..............................................
Boot0005* LAN2  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv4(0.0.0.00.0.0.0,0,0)
Boot0006* HDD/SSD       PciRoot(0x0)/Pci(0x1f,0x2)/Ata(0,0,0)
Boot0007* LAN1  PciRoot(0x0)/Pci(0x19,0x0)/MAC(b86b230ae112,0)/IPv6([::]:<->[::]:,0,0)
Boot0008* Linux HD(1,GPT,7b0beb5e-eaf0-4c1a-b073-18114128527a,0x800,0x32000)/File(\EFI\debian\grub.efi)label.LMDE 4 Debbie.--.loader.\EFI\debian\grub64.efi...............................................................................

Die Zeile "Boot0008* Linux ..." ist neu.

Die Maschine habe ich noch nicht wieder neu gestartet, falls noch Abfragen zu erfolgen haben ...

Wie es scheint, ist das Windows-7-System verschwunden ... es war auf sda2 mit 90 GB installiert. Was ist sda2 jetzt? Eine LINUX-Swap-Partition ... Das ganze erscheint mir wie ein Irrgarten - aber einer der beweglichen Sorte, der die Irrwege ständig umstellt ...

Bis später - es sind noch Früchte zu ernten!

Raimund Frank


Ist das nicht seltsam? - Nach Einstein soll man nicht auf ein anderes Ergebnis hoffen, wenn man dasselbe tut - aber LINUX macht's möglich!?
nöö, überhaupt nicht, beim 2. fehlt schlicht ein …/mnt
Zitat
Hier die Resultate des Befehls "efibootmgr" (ich habe danach gleich ein "sudo efibootmgr -v" ausgeführt):

mint@mint:~$ sudo efibootmgr --create --disk /dev/sda --part 1 -- label "LMDE 4 Debbie" -- loader \\EFI\\debian\\grub64.efi
mint@mint:~$ sudo efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0008,0002,0000,0001,0007,0005
...
Boot0008* Linux HD(1,GPT,7b0beb5e-eaf0-4c1a-b073-18114128527a,0x800,0x32000)/File(\EFI\debian\grub.efi)label.LMDE 4 Debbie.--.loader.\EFI\debian\grub64.efi...............................................................................

Die Zeile "Boot0008* Linux ..." ist neu.
w. z. e. w. (was zu erwarten war!)
Zitat
Die Maschine habe ich noch nicht wieder neu gestartet, falls noch Abfragen zu erfolgen haben ...
na, dann mal los!
Zitat
Wie es scheint, ist das Windows-7-System verschwunden ... es war auf sda2 mit 90 GB installiert. Was ist sda2 jetzt? Eine LINUX-Swap-Partition
danach
2. sudo parted -l

mint@mint:~$ sudo parted -l
Model: ATA TOSHIBA THNSNJ25 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size    File system  Name                  Flags
 1      1049kB  106MB  105MB   fat32                              boot, esp
 3      106MB   106GB  106GB   ntfs                               msftdata
11      106GB   118GB  11,8GB  ext4
2      118GB   215GB  96,6GB  ntfs                               msftdata
 4      215GB   218GB  3221MB  ntfs                               msftdata
 5      218GB   221GB  3221MB  ntfs                               msftdata
 6      221GB   225GB  3221MB  ntfs                               msftdata
 7      225GB   230GB  5371MB  ntfs                               msftdata
 8      230GB   251GB  21,5GB  ntfs                               msftdata
 9      251GB   252GB  1078MB  ntfs                               msftdata
10      252GB   256GB  3578MB  ntfs         Basic data partition  msftdata


scheint es noch vorhanden zu sein, solltest aber mal mit einem erneuten 'parted -l' überprüfen

Guten Abend!

1. Befehlszeileneingabe

Bevor ich die Maschine neu startete – ich hatte über das LIVE-System mit Feuerfuchs noch einige dringende Arbeiten zu erledigen – habe ich mir die beiden Befehlszeilen, die die Inhalte der Partition „sda2“ abfragen, noch einmal angesehen und mich gefragt: „Habe ich einen Knick in der Optik? Wo fehlt dort ein /mnt“

Dann habe ich die beiden Befehlszeilen direkt untereinandergesetzt

mint@mint:/$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt
mint@mint:~$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt

und beim Vergleich festgestellt, daß nicht das „/mnt“ fehlt, sondern – laienhaft ausgedrückt – sich der Terminal-Cursor an zwei unterschiedlichen Orten im „Maschienenraum“ befindet
a) „:/$“ = im obersten (Root-)Verzeichnis oder in einem beliebigen Unterverzeichnis?
b) „:~$“ = im Home-Verzeichnis?

Ist das richtig?

Ferner: Sorgt dieser unterschiedlicher „Standort“ für unterschiedliche Ergebnisse?

Schlußfolgerungsfrage: Von welchem Verzeichnis muß ich Befehle auslösen, wenn ich „richtige“ Ergebnisse erzielen will?

Mir geht es nicht um „Rechthaberei“, sondern die Frage: Warum erhalte ich unterschiedliche Ergebnisse?

2. „sudo parted –l“

Die heutige erneute Abfrage ergab keine Änderung:

„2      118GB   215GB  96,6GB  ntfs                               msftdata“

Wenn ich allerdings in die gestrige Befehlsausgabe von

„sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt“

schaue, dann meine ich KEIN Windows-7-System zu entdecken. Eine Bewertung der gestern, 22.07.2021 / 14:59:19 Uhr, von mir eingstellten Verzeichnis-Angaben zu „sda2“ steht noch aus ...

3. Neustart

Nach der Umsetzung des Befehls „efibootmgr“ mit den angegebenen Parametern wurde die Maschine neu gestartet.

Diesmal hat die Festplatten-Diode 3x geflackert statt vorher nur 2x.

Schließlich wollte die Maschine wieder über LAN (Ipv6, danach Ipv4) starten.

Nach Entfernung des LAN-Kabels und einem weiteren Neustart kam erwartungsgemäß die Mitteilung, daß kein System vorhanden sei ...

Das Einstellen der Photographie habe ich mir erspart ...

Ist es sinnvoll noch einmal den NVRAM abzufragen?

Schönen Abend!

Raimund Frank

Sorgt dieser unterschiedlicher „Standort“ für unterschiedliche Ergebnisse?
Es kommt auf die Abfrage an!
Mit "sudo ls -R" wird der Inhalt des jeweiligen Arbeitsverzeichnisses (Standort ~ "Home" oder / "Root") angezeigt. Also unterschiedliche Ergebisse.

Wenn Du in der Abfrage ein Verzeichnis angibst (/mnt), spielt das Arbeitsvezeichnis (der Standort) keine Rolle:
sudo ls -R /mnt
Gesucht wird ja nach dem Inhalt der Partition /dev/sda2, die vorher unter /mnt eingehängt wurde:
sudo mount /dev/sda2 /mnt
Und zum Schluss ordentlich wieder ausgehängt wird. sudo mount /dev/sda2 /mnt && sudo ls -R /mnt && sudo umount /mnt
« Letzte Änderung: 23.07.2021, 22:29:50 von aexe »

...
Ist es sinnvoll noch einmal den NVRAM abzufragen?
kannst ja mal mit dem vom 22. 14:57 vergleichen, wenn er anders ist, posten.

Aber
  • kommst du irgendwie in das UEFI Menü des Rechners, wo die Booteinträge zur Auswahl stehen und kannst dort den Debian Eintrag wählen?
  • liefere vom Livesystem ein "  sudo mount /dev/sda1 /mnt && sudo cat /mnt/efi/debian/grub.cfg && sudo umount /mnt  "
  • ferner ein "  lsblk -f  "

Tipp: Für solche Terminalein- und ausgaben benutzt Du copy&past (zwar bin auch ich nicht fehlerfrei, und genau der Fehler mit dem fehlenden …/mnt ist mir auch schon unterlaufen  :-[ )

Guten Morgen!

@aexe

So langsam dämmert es ...

In beiden Befehlen

mint@mint:/$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt
mint@mint:~$ sudo mount /dev/sda2 /mnt && sudo ls -R && sudo umount /mnt

fehlte der Ausdruck "/mnt" - aber nicht am Anfang oder am Ende des Terms, sondern im der "Mitte":

statt "sudo ls -R" hätte also ein "sudo ls /mnt -R" stehen müssen!?

Ist das richtig?

Wenn ja dann: Künstliche Intelligenz trifft natürliche Dummheit ... allerdings nicht mehr ganz so dumm.

@g.rubienne

Abfrage NVRAM - keine Änderung ersichtlich: Eintrag "Boot0008* Linux" ist noch vorhanden

zu 1.: Leider nein; Toshiba hat das nur das nötigste programmiert.

Schon die Installation von WIN-7 64-Bit im UEFI-Modus war ein Ding der Unmöglichkeit! Wegen fehlender Treiber bei WIN-7 muß im UEFI ein "ODD-UEFI" definiert sein, damit WIN-7 überhaupt von der DVD gestartet werden kann (so jedenfalls beim Desktop-Rechner eines Freundes); fehlt beim TECRA R950. Mit Windows 8 dann kein Problem mehr - aber das wollte ich nicht, deshalb LINUX LMDE-4.

Ich installierte dann das WIN-7 auf einer kleinen Platte im CSM/MBR-Modus und formatierte dann die Platte von MBR zu GPT, gleichzeitig habe ich vor dem Neustart von CSM auf UEFI umgestellt. Dann lief das System tatsächlich im UEFI-Modus (bis auf den Fenster-Begrüßungsschirm mit den wehenden Windows-Flaggen - aber darauf kann ich verzichten). Dann habe ich das System WIN-7 zu ATI-2021 zu sichern versucht, was zunächst auch nicht klappte, da das Notfallmedium auf LINUX-Basis (von ATI-2021 erstellt) nicht im UEFI-Modus erkannt wird (anders als die LMDE-4-DVD: die wird erkannt).

Erst der Hinweis hier bei LinuxMintUsers in einem anderen Forum auf das Programm "Ventoy" konnte ich die ATI-2021-Notfall-ISO lauffähig machen, das WIN-7 sichern und auf meine 4 TB SSD erfolgreich "wiederherstellen".

Die jetzige SSD ist nur eine für die Testinstallation, damit mir das WIN-7 nicht zerschossen wird ...

zu 2.: Ich verstehe - vielleicht gibt es einen Fehler bei der Befehlsübergabe - eventuell durch falsche Adressierung.

Hatte ich vermutet und schon - etwas umständlicher - in eine txt-Datei gesetzt. Hier das neue Abfrageergebnis:

mint@mint:~$ sudo mount /dev/sda1 /mnt && sudo cat /mnt/efi/debian/grub.cfg && sudo umount /mnt
search.fs_uuid fafe1d64-ac4f-44ee-9b15-94f8683b711a root hd0,gpt11
set prefix=($root)&apos;/boot/grub&apos;
configfile $prefix/grub.cfg

zu 3.: ... und der "lsblk -f" mit den UUID's - scheint übereinzustimmen!?

mint@mint:~$ lsblk -f
NAME        FSTYPE   LABEL                  UUID                                 FSAVAIL FSUSE% MOUNTPOINT
loop0       squashfs                                                                   0   100% /lib/live/mount/r
sda                                                                                             
├─sda1      vfat                            4925-4785                                           
├─sda2      ntfs     ZusatzSpeicher         77D506F72AED0F02                                   
├─sda3      ntfs     R90_SYS_7              14AC17E0AC17BAE6                                   
├─sda4      ntfs     EXPORT                 3561A3CDEDCB655F                                   
├─sda5      ntfs     FORSCHUNG              902D7EE15DEF9C3E                                   
├─sda6      ntfs     GRAPHIK                14B6F77DC5B0D0E8                                   
├─sda7      ntfs     HINTERLEGEN            2100D658F4001B84                                   
├─sda8      ntfs     IMPORT                 A822AEEFE1DE1046                                   
├─sda9      ntfs     JENSEITS               B6ECA304C9E5414E                                   
├─sda10     ntfs     LINUX_LAGER            0C5A1A1A0C5A1A1A                                   
└─sda11     ext4                            fafe1d64-ac4f-44ee-9b15-94f8683b711a               
sdb                                                                                             
├─sdb1      exfat    Ventoy                 4E21-0000                                           
│ └─ventoy                                                                             0   100% /media/mint/LMDE
├─sdb2      iso9660  LMDE 4 Cinnamon 64-Bit 2020-03-22-12-22-43-00                     0   100% /media/mint/LMDE
└─sdb3      ntfs     Ventoy_DAT             5AD80D2DAAC82661                     1010,1M     1% /media/mint/Vento
sr0                                                                                             
mmcblk0                                                                                         
└─mmcblk0p1 ntfs     SYS_SIC_S1             62E43E9CE43E7281                       17,4G    85% /media/mint/SYS_S

Gruß

Raimund Frank

zu 1.: Leider nein; Toshiba hat das nur das nötigste programmiert.
möglicherweise mußt du ein "Superuser Paßwort" im UEFI setzen?
Zitat
Schon die Installation von WIN-7 64-Bit im UEFI-Modus war ein Ding der Unmöglichkeit!
Windows 7 ist EOL! Und im EFI Modus geht das ohnehin erst ab SP1!

tl;tr konzentrier dich auf das hier nötige.
Zitat
zu 2.:...eventuell durch falsche Adressierung.
nein, sieht soweit alles richtig aus

Versuche ein " sudo efibootmgr -n 0008 "
Falls dann immer noch LMDE nicht bootet, fällt mir nur noch ein, es von einem grub aus per  SymLinks zu starten, mußt du aber entsprechend an die Debian Gegebenheiten anpassen.

« Letzte Änderung: 24.07.2021, 16:04:24 von g.rubienne »

Off-Topic:
Wenn ja dann: Künstliche Intelligenz trifft natürliche Dummheit ..
"Ja" ist richtig.
Edit: fast richtig, denn "sudo ls /mnt -R" ist falsch. Das hat aber auch niemand vorgeschlagen.  ::)

Allerdings ist das Terminal (die Bash-Shell) weniger ein Beispiel für künstliche Intelligenz, sondern ein elender Pedant.
Jedes Zeichen zählt und wird befolgt – auch fehlende Zeichen und die Reihenfolge.  ;)
Wenn man Glück hat kommen im Zweifel Fehlermeldungen oder Rückfragen.
« Letzte Änderung: 24.07.2021, 18:52:13 von aexe »

Danke für die rasche Antwort!

Da ich LMDE-4 zusammen mit WIN-7 (wegen älterer lizensierter Programme) nutzen will und durch LMDE-4 kein Systemstart von WIN-7 mehr möglich ist, gehören die Auswirkungen von LMDE-4 zur NOT die ich wenden will; die Erörterung ist daher für mich notwendig.

Ferner besteht auch ein direkter Zusammenhang zwischen UEFI / WIN-7 und LMDE-4. Warum zum Beispiel startet LMDE von einer DVD problemlos ins LIVE-System? Warum wird der Ventoy-USB-Stift von der Maschine erkannt und LMDE-4-ISO als LIVE-System ausgeführt? Vielleicht gibt es auf diese Fragen keine direkte Antwort - aber ich nutze die Fragen um Alternativen zu bedenken ...

Was ich noch erinnern möchte: Wie darf ich nun die am 22.07.2021 von mir abgefragten Daten von "sda2" interpretieren: existiert nach der Verzeichnisstruktur noch ein WIN-7?


Aufgabe
Versuche ein " sudo efibootmgr -n 0008 "
Frage:
Wenn ich es richtig verstanden habe, greift "efibootmgr" auf den NVRAM des Rechners zu und ist damit unabhängig von der Frage LIVE-System oder FIX-System von HDD/SSD?

Sollte dieser Befehl nicht wirken, werde ich versuchen ein SUPERUSER-Paßwort zu setzen und wenn auch dies nicht hilft, testweise ein Installation im CSM/MBR-Modus versuchen - dann besteht Gewißheit, daß es an der Maschinen liegen muß ...

SymLinks sagt mir noch garnichts - ich könnte aber auch erst LMDE und dann WIN-7 starten und es mit dem Bootmanager in WIN-7 versuchen, falls der funktioniert ...

Bleiben also noch einige Möglichkeiten!

Wenn das Ergebnis steht, bin ich zurück ... es sind auch andere Dinge zu erledigen.

Gruß

Raimund Ferdinand

...Warum ..startet ..von einer DVD
...Warum ..USB.. erkannt und LMDE-4-ISO als LIVE-System ausgeführt?
ganz einfach: in der BootOrder: 0008,0002,0000,0001,0007,0005
wird – warum auch immer – 0008 (LMDE) übergangen, als nächstes wird 0002=ODD, dann 0000=USB usw.gesucht, und sobald sort etwas zum Booten vorhanden ist (DVD, USB Stick), dann wird davon gebootet; so ist es vorgesehen
Zitat
...um Alternativen zu bedenken
eine habe ich ja schon auf gezeigt
Zitat
...von mir abgefragten Daten von "sda2" interpretieren: existiert nach der Verzeichnisstruktur noch ein WIN-7?
dazu hat dir doch @aexe in aller Ausführlichkeit erklärt, was an den von dir eingetippten Befehlen verkehrt war! Und ich hoff,du kannst noch einfach nachsehen, ob auf der Windowspartition noch ein Windows vorhanden ist. allerdings, das allein reicht nicht, es muß auch der Bootloader in der ESP vorhanden sein! kannst dumit
... sudo mount /dev/sda1 /mnt && sudo ls -R /mnt && sudo umount /mnt...
herausfinden
Zitat

Aufgabe
Versuche ein " sudo efibootmgr -n 0008 "
wie jetzt, das hast du noch nicht ausgeführt ?  :-X
Zitat
... testweise ein Installation im CSM/MBR-Modus versuchen - dann besteht Gewißheit, daß es an der Maschinen liegen muß ...
kannst du denn im Setup umstellen? Ich dachte, da kommst du gar nicht hinein?
Zitat
ich könnte aber auch erst LMDE und dann WIN-7 starten und es mit dem Bootmanager in WIN-7 versuchen, falls der funktioniert ...
da denk doch bitte über die Aussage nochmal ganz scharf nach  :o
Off-Topic:
Mal am Rande, habe gerade ein LMDE (inoffizielles-lmde-4-mate-64bit-de-20120322-rc2_keine_Updates.iso) in einer VM mit EFI "automatisch" (d.h., ganze Platte) installiert. Das ist aber sowas von gründlich in die Hose gegangen, s. Anhang  (swap 4,3, "/" 3,9 !! VB hat 8 GB vorgeben) Verdammt schnell ging 's auch (?) Erst eine "manuelle" Installation führt zum Ziel

Das mit den Symlinks geht so nicht bei Debian, da werden keine beim kernel update generiert! (das ist Mist! Weil man dann bei jeden kernel update in einem stanalone grub die Dateien /boot/vmlinuz-4.19.0-8-amd64) und /boot/initrd.img-4.19.0-8-amd64 händisch anpassen muß.

Das heißt jetzt für @Raimund Frank, wenn es über den NVRAM Eintrag nicht funktioniert, kann man von der grub Konsole – Livesystem starten und beim ersten Auswahlbildschirm Taste C drücken – aus die richtigen Befehle mit der "autovervollständigen Funktion" zusammen basteln (die kursiv geschriebenen Befehle einen nach dem anderen
ls liefert die Partitionen (-> (hd0,1), (hd0,2 usw) hier die vom "/" raussuchen, dürfte (hd0,11) sein
set root=(hd0,11) return
linux /boot/ hier ein TAB listet mögliche Dateien/Verzeichnisse; weiter bis eben linux /boot/vmlinuz-4.19.0-8-amd64  (oder was auch immer) return
initrd /boot/initrd.img TAB... return
boot return