Sie sind nicht angemeldet.

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

21

05.12.2017, 21:04

Nach 3 Tagen Datensicherung (mit verschiedenen Werkzeugen und vielen Fehlern bis endlich mal 2 in Ordnung waren) bin ich heute dazu gekommen, Linux Mint als Versuchskaninchen (Laborratte) zu operieren. Es schaut noch nicht hoffnungslos aus.

Zunächst kam mir ein Zufall zu Hilfe, indem ich nämlich einen USB-Stock mit SuperGrub2Disk im EFI-modus fand; zumindestens tauchte er im EFI-Startmenü mit dem Vorsatz "UEFI: ..." auf. Der Bootvorgang lief auch deutlich anders als früher ab; wie man nachprüfen kann, ob ein System wirklich im EFI-Modus gestartet ist konnte ich leider (außer für Windows - habe ich aber nicht) nirgends finden.

Danach habe ich im laufenden Mint mit Synaptic das Übergangspaket grub-efi installiert, das erwartungsgemäß grub-pc samt Abhängigkeiten entfernt hat. Neustart habe ich bis jetzt noch keinen gemacht. Diese Installation hat leider sich nicht so eingebunden, wie es laut der vielen Beschreibungen sein sollte. Also habe ich im Verzeichnis /boot eine Verzeichniskette efi/EFI/mint eingerichtet, wobei ich vorher (bevor die Verzeichnisse EFI und mint angelegt waren) die ESP am Punkt /boot/efi eingehängt hatte. Die beiden letzten Verzeichnisse müßten also auf der ESP stehen.

Quellcode

1
2
3
4
5
6
7
8
ebbi@i5tuxedo /boot $ sudo mount /dev/sda2 /boot/efi
ebbi@i5tuxedo /boot $ mount
 ...
/dev/sda7 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
 ...
/dev/sr0 on /media/ebbi/LinuxWelt_2018-1 type iso9660 (ro,nosuid,nodev,relatime,uid=1000,gid=1000,iocharset=utf8,mode=0400,dmode=0500,uhelper=udisks2)
/dev/sdb3 on /mnt/timeshift/backup type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)


Meine Hoffnung ist, in Zukunft dort noch Verzeichnisse namens xubuntu und manjaro zu haben, welche die Bootloader der jeweiligen Distribution enthalten sollen. Jetzt komme ich allerdings nicht weiter, denn ich müßte eine Datei namens grubx64.efi hineinkopieren, die ich aber nirgendwo habe. Folgender Versuch ist auch nicht gelungen:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
ebbi@i5tuxedo /boot $ locate grubx64

ebbi@i5tuxedo /boot $ efibootmgr
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0002,0001,0003,0004,0005
Boot0001* Hard Drive 
Boot0002* CD/DVD Drive 
Boot0003* USB 
Boot0004* UEFI: KingstonDataTraveler 2.0PMAP
Boot0005* UEFI: (FAT) S31B0804USB DISK 1100

ebbi@i5tuxedo /boot $ grub-install --bootloader-id mint /dev/sda
unshare failed: Operation not permitted
Installing for x86_64-efi platform.
grub-install.real: Warnung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-install.real: Warnung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-install.real: Warnung: Platte existiert nicht, ersatzweise wird Partition des Geräts /dev/sda2 verwendet.
grub-install.real: Fehler: Laufwerk »hostdisk//dev/sda2« wurde nicht gefunden..

Jetzt werde ich erstmal drüber schlafen. Überlege gerade, ob ich den Rechner durchlaufen lassen soll oder ob ich mich darauf verlassen kann, nach einem Neustart morgen früh immer noch alle Systeme erreichen zu können.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »ebbi97a« (05.12.2017, 21:24)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

22

08.12.2017, 20:14

Frage zum Einhängen der ESP

Weil ich mit dem direkten Hinbasteln der Bootstruktur nicht erfolgreich war, habe ich auf der /dev/sda Platz für eine weitere Partition geschaffen und ein weiteres Linux-System von Grund auf installiert. Obwohl ich darauf geachtet habe, daß das Installationmedium im EFI-Modus und nicht im BIOS-Modus gestartet war, hat der Installer die ESP vollständig ignoriert, nichts hineingeschrieben und trotzdem verkündet, die Installation sei erfolgreich verlaufen. Das neue Testsystem (Antergos) läßt sich jedoch nicht starten wie es sich gehört, wohl aber über den Umweg mit SuperGrubDisk wie alle anderen auch. Zufällig ist mir in anderem Zusammenhang aufgefallen, daß es unmöglich ist, in einer BTRFS-formatierten Partition solche mit einem anderen Dateityp einzuhängen (Einzelheiten folgen weiter unten).

Die ESP ist vfat und die Systempartition /dev/sda3 ist btrfs. Allerdings habe ich keinerlei Fehlermeldungen während der Installation gesehen; ein gescheiterter Mount hätte doch eine Meldung auswerfen müssen !?

EINZELHEITEN

Die grundsätzliche Überlegung, die der Installation vorausging war, daß eine Neuinstallation grundsätzlich gelingen müsse, wenn die wesentlichen Voraussetzungen erfüllt sind. Als solche waren mit bekannt:
  1. Die Platte besitzt eine GPT
  2. (U)EFI ist in der Firmware verfügbar
  3. Das Installationsmedium wird im EFI-Modus gestartet
  4. Es ist bereits eine ESP (vfat, > 100MB, richtige Markierung EF00) in der Installationspartition auf der gleichen Platte vorhanden

Die ESP (/dev/sda2) wurde auch nicht in /boot/efi oder /boot eingehängt, sondern nirgends. /dev/sda3 ist btrfs, /dev/sda2 ist vfat.

Zunächst fiel mir nicht weiter dazu ein, bis ich in einem anderem Zusammenhang auf folgendes gestoßen bin:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
[ebbi@i5tuxedo ~]$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
dev             7,8G       0  7,8G    0% /dev
run             7,9G    1,4M  7,9G    1% /run
/dev/sda3        93G    5,6G   85G    7% /
tmpfs           7,9G       0  7,9G    0% /dev/shm
tmpfs           7,9G       0  7,9G    0% /sys/fs/cgroup
tmpfs           7,9G     34M  7,8G    1% /tmp
tmpfs           1,6G     28K  1,6G    1% /run/user/1000

[ebbi@i5tuxedo ~]$ mount
 ‥ ‥ ‥
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type btrfs (rw,relatime,space_cache,autodefrag,inode_cache,subvolid=5,subvol=/)
 ‥ ‥ ‥

[ebbi@i5tuxedo ~]$ ls /mnt

[ebbi@i5tuxedo ~]$ sudo mount -o ro /dev/sdb1 /mnt
Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat.  Normalerweise läuft es auf drei Regeln hinaus:
    #1) Respektieren Sie die Privatsphäre anderer.
    #2) Denken Sie nach, bevor Sie tippen.
    #3) Mit großer Macht kommt große Verantwortung.
[sudo] Passwort für ebbi:
mount: /mnt: unbekannter Dateisystemtyp „ext4“.

[ebbi@i5tuxedo ~]$ sudo mount /dev/sda2 /boot
mount: /boot: unbekannter Dateisystemtyp „vfat“.


Ist irgendetwas bekannt, was das Einhängen in ein btrfs-Dateisystem verhindert? Würde es möglicherweise helfen, die neue Systempartition in ext4 umzuwandeln?
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (08.12.2017, 20:27)


  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

23

09.12.2017, 19:30

Kleiner, aber wichtiger Teilerfolg!

Weil ich mit dem direkten Hinbasteln der Bootstruktur nicht erfolgreich war, habe ich auf der /dev/sda Platz für eine weitere Partition geschaffen und ein weiteres Linux-System von Grund auf installiert. Obwohl ich darauf geachtet habe, daß das Installationmedium im EFI-Modus und nicht im BIOS-Modus gestartet war, hat der Installer die ESP vollständig ignoriert, nichts hineingeschrieben und trotzdem verkündet, die Installation sei erfolgreich verlaufen. ...
... ...
Ist irgendetwas bekannt, was das Einhängen in ein btrfs-Dateisystem verhindert? Würde es möglicherweise helfen, die neue Systempartition in ext4 umzuwandeln?

Hat sich erledigt. Gerade eben habe ich es erneut versucht, die Systempartition mit ext4 formatiert und danach ganz sorgfältig hingeschaut. Vermutlich hatte ich beim ersten Versuch nur vergessen, der ESP den Einhängepunkt /boot/efi zuzuweisen, wie er vom Installer vorgeschlagen wird. Meine Phantasie, daß das btrfs-Dateisystem schuld gewesen sei, ist wohl abwegig. Diesmal war wohl alles richtig eingestellt, die Installation ist wieder fehlerfrei gelaufen und danach beim Neustart ist es (das Antergos-System) ohne Fremdhilfe hochgekommen.

Weitere Einzelheiten (auf langatmige Schilderung von Zusammenhängen kann ich einfach nicht verzichten ;) )
:
Vorher hatte ich noch ein fünftes System hinzugebastelt, nämlich das Debian-Derivat PointLinux. Leider ist mir der USB-Stock zum Installieren wieder mal mißlungen. Diesmal habe ich Etcher verwendet und obwohl die ISO-Datei einen efi-Ordner enthielt wurde nur vom BIOS gebootet (MBR-Modus); das installierte System ist unter EFI also wieder unbrauchbar. Den USB-Stock werde ich nochmal mit einem anderen Werkzeug beschreiben und es erneut versuchen. Im Erfolgsfall hätte ich dann 2 fehlerfreie Muster/Vorlagen, wonach ich die Bootmimik der 3 Altsysteme nachbauen kann.

Partitionen des laufenden Antergos-Systems:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
[ebbi@i5tuxedo ~]$ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
dev             7,8G       0  7,8G    0% /dev
run             7,9G    1,4M  7,9G    1% /run
/dev/sda3        91G    5,2G   85G    6% /
tmpfs           7,9G       0  7,9G    0% /dev/shm
tmpfs           7,9G       0  7,9G    0% /sys/fs/cgroup
tmpfs           7,9G     29M  7,8G    1% /tmp
/dev/sda2       112M    366K  111M    1% /boot/efi
tmpfs           1,6G     36K  1,6G    1% /run/user/1000
/dev/sdh        954M    642M  313M   68% /run/media/ebbi/KINGSTON-DT

Auszug aus der mount-Tabelle:

Quellcode

1
2
3
4
5
6
7
8
9
[ebbi@i5tuxedo ~]$ mount
 ...
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
 ...
/dev/sda2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
 ...
/dev/sdh on /run/media/ebbi/KINGSTON-DT type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
/dev/sdc1 on /run/media/ebbi/ANTERGOS type iso9660 (ro,nosuid,nodev,relatime,nojoliet,check=s,map=n,blocksize=2048,uid=1000,gid=100,dmode=500,fmode=400,uhelper=udisks2)

und die /etc/fstab (automatisch erstellt):

Quellcode

1
2
3
4
5
6
7
8
9
10
11
[ebbi@i5tuxedo ~]$ more /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
#
UUID=FF79-8166 /boot/efi vfat defaults,relatime 0 0
UUID=b64c9970-64bc-40f7-98a9-64eb8d426b54 / ext4 defaults,relatime,data=ordered 0 1
_______________________________
Welches System hätten's denn gern?

24

10.12.2017, 14:23

Ist irgendetwas bekannt, was das Einhängen in ein btrfs-Dateisystem verhindert?
ext4 und vfat wurden als unbekannte Typen gemeldet. Und da würde ich als erstes nachsehen, ob vielleicht die Module dafür fehlen.

Quellcode

1
cat /proc/filesystems

Wenn sie nur beim booten nicht erkannt werden, fehlen sie wahrscheinlich in der initrd.
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

25

10.12.2017, 22:30

Was bedeutet das:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
[ebbi@i5tuxedo ~]$ cat /proc/filesystems
nodev	sysfs
nodev	rootfs
nodev	ramfs
nodev	bdev
nodev	proc
nodev	cpuset
nodev	cgroup
nodev	cgroup2
nodev	tmpfs
nodev	devtmpfs
nodev	binfmt_misc
nodev	configfs
nodev	debugfs
nodev	tracefs
nodev	securityfs
nodev	sockfs
nodev	bpf
nodev	pipefs
nodev	hugetlbfs
nodev	devpts
nodev	autofs
nodev	pstore
nodev	efivarfs
nodev	mqueue
	ext3
	ext2
	ext4
	vfat
	btrfs
	fuseblk
nodev	fuse
nodev	fusectl

Sofern ich mich recht erinnere habe ich den Fehler nach der ersten Installation von Antergos gemeldet. Inzwischen habe ich aber ein zweites Mal installiert und dieses Mal erfolgreich; kann also durchaus sein, daß mit dem nicht richtig funktionierenden System ein anderes Ergebnis herausgekommen wäre.

Mit dem Grubeintrag von Antergos im EFI-Modus ist es ohne weitere Hilfsmitten vom Startmenü aus hochgefahren. Danach habe ich GeckoLinux ebenfalls erfolgreich installiert, welches vermutlich das Startmenü überschrieben hat. Darin sind die beiden ARCH-Derivate zwar eingetragen, verenden aber mit Kernel Panic. Mit der externen SuperGrub2Disk sind dagegen alle 5 Systeme zu starten, solange man aus den vielen Einträgen im angebotenen Menü (mehrere Seiten lang) die richtigen auswählt.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (10.12.2017, 22:41)


26

11.12.2017, 00:20

Was bedeutet das
Daß zumindest das laufende System mit den Typen ext2/3/4, vfat, btrfs und anderen umgehen kann. Wenn es beim Hochfahren die Systempartition einbinden kann, dann ist zumindest das zugehörige Modul auch in der initrd drin. Muss es aber beim letzten Mal schon gewesen sein, denn btrfs wurde ja als solches verwendet. Die übrigen hätten von dort nachgeladen werden müssen und haben vielleicht gefehlt oder so...
Beim Erstellen dieser Nachricht kamen keine Tiere zu Schaden.
me is all sausage
but don't call me Ferdl

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

27

12.12.2017, 09:28

noch ein kleiner Teilerfolg

Gerade ist es mir gelungen, das bestehende Manjaro-System händisch so hinzubasteln, daß es reproduzierbar aus dem von EFI erzeugten Startmenü ohne weitere Hilfsmittel startet.
Ob wirklich alles regelkonform eingerichtet ist wird sich wohl erst dann zeigen, wenn die Manjaro-Repositories einen neuen Kernel mitbringen und dieser automatisch eingerichtet werden soll.
Bleibt nur Abwarten.
_______________________________
Welches System hätten's denn gern?

  • »ebbi97a« ist männlich
  • »ebbi97a« ist der Autor dieses Themas

Beiträge: 181

Registrierungsdatum: 28.11.2005

Derivat: Xubuntu

Version: Ubuntu 18.04 LTS - Bionic Beaver

Architektur: 64-Bit PC

Desktop: XFCE

Andere Betriebssysteme: Debian, Devuan, Mint, Manjaro, MacOS X, Android, Windows 7

  • Nachricht senden

28

13.12.2017, 06:57

Geschafft!

Seit gestern laufen alle Systeme im EFI-Modus. Nachdem ich gelernt hatte eine unvorstellbare Anzahl von Fehlern - die aus der Unübersichtlichkeit der ganzen Materie herrührten - zu vermeiden, war es am Schluß ziemlich einfach. Ich bedanke mich bei allen, die mir geholfen haben.

Fazit: es ist nicht nur möglich, sondern auch mit vernünftigem Aufwand machbar, ein Multibboot-System (ohne Windows!) von BIOS/MBR auf EFI/GPT umzustellen, ohne neu zu installieren. Meine Platten schauen jetzt so aus:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[ebbi@i5Tuxedo ~]$ sudo lsblk -o NAME,FSTYPE,LABEL,UUID,MOUNTPOINT
[sudo] Passwort für ebbi: 
NAME   FSTYPE LABEL       UUID                                 MOUNTPOINT
sda                                                            
├─sda1 swap               13c0bf09-6d17-462a-9383-8505ebd5c935 [SWAP]
├─sda2 vfat   EF00        FF79-8166                            /boot/efi
├─sda3 ext4   Antergos    b64c9970-64bc-40f7-98a9-64eb8d426b54 
├─sda4 ext4   Gecko       27be2b7a-90ee-41e0-881a-f8ed63b1ecee 
├─sda5 ext4   Xubuntu     57fad0b2-4ce5-4cae-82c3-d3794f3c2887 
├─sda6 ext4               29463195-f864-40d1-a2e9-5ef11815dce3 
├─sda7 ext4   Mint        fc669513-df7e-42df-9df1-7cf9374d439d 
└─sda8 ext4   Manjaro     cf74d943-21a2-42ad-8d72-66335c755f74 /
sdb                                                            
├─sdb1 ext4               948157c2-855b-47b4-b084-5eca13d5861e 
├─sdb2 swap               45a93cd8-0b4d-4bc1-a90b-42deb9870f52 [SWAP]
└─sdb3 btrfs              e29062e9-3de1-4d73-a8e7-1ff82f96b5f9 
sdg    vfat   KINGSTON-DT 3AE8-5DA8                            
sr0 

2 Systeme werde ich wieder löschen, weil die nur als Vorlagen dienten, was anzustreben war; sie waren nicht umgestellt, sondern gleich unter EFI installiert worden.

Für den komfortablen Betrieb bleibt noch die Schwierigkeit, daß in einem der Bequemlichkeit halber eingerichteten Grub2-Menü das Manjaro-System die federührende Rolle einnehmen muß; Antergos geht auch, aber Xubuntu, Mint und Gecko können das nicht. Das hat hier jedoch nichts zu suchen und ich werde diese Frage im Manjaro-Forum ausdiskutieren.
_______________________________
Welches System hätten's denn gern?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »ebbi97a« (13.12.2017, 07:04)