staging.inyokaproject.org

Ich habe eine kleine Zwischenfrage, es handelt sich um eine Verstädnisfrage. Weil, eine Notwendigkeit für eine/die Funktionalität kann ich nicht erkennen. Es handelt sich um ein UEFI-System, die zu startenden Systeme sind im EFI-Loader eingetragen; soweit ich gesehen habe auch korrekt. Die Systeme wären also somit mit dem UEFI-Loader auswählbar und startbar. Wozu wird dann noch an Grub gebastelt? Und/oder was ist das Anwendungsszenario?

Hej Mylin,

leider ist das nicht ganz so, jedenfalls bei Linux/grub nicht. Der NVRAM Eintrag ruft shimx64.efi auf und benutzt <ESP>/efi/Ubuntu/grub.cfg, um das configfile in /boot/grub/grub.cfg auszuführen und das Menü bereitzustellen. In diesem grub.cfg stehen aber noch die Einträge für die alte Platte. Das muß durch ein sudo update-grub im laufenden System korrigiert werden.

Beispiel

murkel@murkel-320:~$ sudo parted -l
Modell: ATA VBOX HARDDISK (scsi)
Festplatte  /dev/sda:  320GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name                          Flags
 1      1049kB  2097kB  1049kB                                             bios_grub
 2      2097kB  101MB   98,6MB  fat32                                      boot, esp
 3      101MB   26,3GB  26,2GB  ntfs                                       msftdata
 4      26,3GB  27,0GB  690MB   ntfs                                       versteckt, diag
 5      27,0GB  27,0GB  16,8MB               Microsoft reserved partition  msftres
 6      27,0GB  53,9GB  26,8GB  ext4
 7      53,9GB  53,9GB  34,6MB  fat32                                      msftdata
 8      53,9GB  320GB   266GB   ext4


murkel@murkel-320:~$ lsblk -o name,uuid,partuuid
NAME   UUID                                 PARTUUID
loop0                                       
[...]                                
sda                                         
├─sda1                                      ad88bf42-ea2e-4158-b4c9-24df7d89ff48
├─sda2 C0D1-F532                            667bfbf4-fdbd-4f62-8bcd-f2c01fb39e04
├─sda3 6F8CC41273F6FEB6                     eaf63eba-7098-4bce-86a4-99a671576baa
├─sda4 5488A72E88A70E14                     2d50126b-0b6b-42f5-a749-b59227ddb959
├─sda5                                      69c52ebc-576c-4360-a823-132dbb761acd
├─sda6 a4260854-6744-46f7-abb9-8e180d98dde5 5c5a4901-ada8-4b89-aaeb-2ce37a491b9e
├─sda7 544C-B20E                            3777ba47-5e4b-40d2-864a-d99b6d72eb6c
└─sda8 a1dc141c-d281-4426-94dd-279e5d2850a0 8fde7cde-dde3-4ad5-ac03-37352d4e48d4
sr0                                         
murkel@murkel-320:~$ sudo efibootmgr -v
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0008,0004,0000,0001,0003,0002
Boot0000* UiApp	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376 	PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI VBOX HARDDISK VB11fc385f-199ac660 	PciRoot(0x0)/Pci(0xd,0x0)/Sata(2,65535,0)N.....YM....R,Y.
Boot0003  EFI Internal Shell	FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* ubuntu	HD(2,GPT,667bfbf4-fdbd-4f62-8bcd-f2c01fb39e04,0x1000,0x2f000)/File(\EFI\ubuntu\shimx64.efi)
Boot0008  Windows Boot Manager	HD(2,GPT,667bfbf4-fdbd-4f62-8bcd-f2c01fb39e04,0x1000,0x2f000)/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.}....................
murkel@murkel-320:~$ sudo mount /dev/sda2 /mnt && sudo cat /mnt/efi/ubuntu/grub.cfg
search.fs_uuid a4260854-6744-46f7-abb9-8e180d98dde5 root hd0,gpt7 
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
murkel@murkel-320:~$ 

Gruß black tencate

black tencate

Ah, ok. Danke für die ausführliche Erläuterung. Der Verwendung von Grub ist schon eine Weile her, so dass mir nicht mehr gleich klar war, wofür Grub noch benötigt wird.

Was mich stutzig macht, bzw., was ich nicht einordnen kann, ist dieser Eintrag in /etc/fstab

//192.168.178.30/homes/XXXX	/home/XXXX	cifs	rw,XXXX,uid=1000,gid=1000,iocharset=utf8	0	0

Für mich passt das so nicht mit dem Wiki zusammen → https://wiki.ubuntuusers.de/mount.cifs/

Ich kenne mich mit der Materie allerdings nicht aus - aber wie erwähnt, in der Form kann ich das im Wiki-Artikel nicht finden.

Nachtrag: weil nämlich, der Grub-Eintrag scheint korrekt zu sein, UUID, PARTUUID, Mountpoint und Optionen passen soweit - für micht bleibt da dann als Ursache erst mal der Netzwerkeintrag.

Könnte man ja einfach mal auskommentieren, dann sieht man gleich, was passiert und ob es daran liegt. 😉

Ok, also so wie ich das jetzt verstanden habe muss ich die grub.cfg mit einem update-grub aktualisieren und zwar direkt im "installierten/laufenden" System? Und ihr diskutiert jetzt wie der "richtige" Weg ist? Also hab ich mich mal mit der von Frieder108 erwähnten chroot Methode beschäftigt. Mir ist zwar nicht ganz klar welche Verzeichnisse dafür wirklich nötig sind, aber ich habe mich mal am Wiki "chroot/Livesystem" orientiert. Wahrscheinlich zu eurer Belustigung poste ich hier mal den Ablauf 😬 :

ubuntu@ubuntu:~$ sudo mount /dev/nvme0n1p4 /mnt
ubuntu@ubuntu:~$ sudo mkdir /mnt/boot/efi
ubuntu@ubuntu:~$ for dir in /dev /dev/pts /proc /sys /run; do sudo mount --bind $dir /mnt$dir; done
ubuntu@ubuntu:~$ sudo chroot /mnt bin/bash
root@ubuntu:/# update-grub
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.8.0-71-generic
Found initrd image: /boot/initrd.img-6.8.0-71-generic
Found linux image: /boot/vmlinuz-6.8.0-64-generic
Found initrd image: /boot/initrd.img-6.8.0-64-generic
Found linux image: /boot/vmlinuz-6.8.0-63-generic
Found initrd image: /boot/initrd.img-6.8.0-63-generic
Found linux image: /boot/vmlinuz-3.19.0-59-generic
Found initrd image: /boot/initrd.img-3.19.0-59-generic
Found linux image: /boot/vmlinuz-3.2.0-67-generic
Found initrd image: /boot/initrd.img-3.2.0-67-generic
Found linux image: /boot/vmlinuz-2.6.38-11-generic
Found initrd image: /boot/initrd.img-2.6.38-11-generic
Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
root@ubuntu:/# exit
exit
ubuntu@ubuntu:~$ 

Mal sehen ob das was ändert...

ERFOLG!
Vom Grub Menu kann ich Ubuntu booten. Wollte dann die restlichen zwei Schritte noch machen. Aber kein Erfolg ohne Misserfolg.

~$ sudoedit /etc/default/grub
sudoedit: /etc/sudo.conf is world writable
sudoedit: usr/bin/sudoedit muss dem Benutzer mit UID 0 gehören und das >>setuid<<-Bit gesetzt haben

Komischerweise konnte ich aber mit

~$: nano /etc/default/grub

die Datei bearbeiten. Die Einträge waren aber schon vorhanden und nur das "GRUB_DISABLE...." musste ich das Auskommentieren rausnehmen.
Allerdings ist das abschließende update-grub nicht möglich. Muss als root aufgerufen werden und sudo update-grub führt wieder zur oben erwähnten Fehlermeldung. Es scheint aber auch so das da mit den Berechtigungen einiges verbogen ist. Firefox startet zB gar nicht. Der Taschenrechner startet. Nemo auch, allerdings mit dem Hinweis das es ein Problem mit dem Vorschaubildpuffer gibt. Mehr habe ich noch nicht ausprobiert.

Hej Yeti,

mit Live-CD/chroot machst Du nichts verkehrt!

Schlecht sind allerdings solche Meldungen bezügl sudoedit. (nano ohne sudo geht zwar, aber dann muß man erst umständlich die so erzeugbare Datei mit RootRechten auf die /etc/default/grub 'bringen').

(Nebenschauplatz: Warum schleppst Du so uralte 32bit kernel mit Dir rum?)

Absolut unklar ist mir, woher besagte Fehlermeldung (bezügl. sda2) kommt. Zeige mal ein

ls -l /etc/grub.d

Hast Du mal eine 40_custom dort bearbeitet? (nee, kann eigentlich nicht sein)

Zeige mal aus dem laufenden System (oder LiveSystem und dann per chroot)

sudo grub-mkconfig -o test.txt

und hänge die Datei als Anhang hier an.

@Frieder108, wovon sprichst Du?

Nachtrag: weil nämlich, der Grub-Eintrag scheint korrekt zu sein, UUID, PARTUUID, Mountpoint und Optionen passen soweit

diese <ESP>/efi/Ubuntu/grub.cfg und auch diese /boot/grub/grub.cfg haben wir doch noch gar nicht gesehen?

Gruß black tencate

black_tencate schrieb:

@Frieder108, wovon sprichst Du?

Nachtrag: weil nämlich, der Grub-Eintrag scheint korrekt zu sein, UUID, PARTUUID, Mountpoint und Optionen passen soweit

diese <ESP>/efi/Ubuntu/grub.cfg und auch diese /boot/grub/grub.cfg haben wir doch noch gar nicht gesehen?

Ich hab mal versucht, die Masse an Infos "aufzudrösseln". 😉

Yeti schrieb:

ubuntu@ubuntu:~$ lsblk -o name,uuid,partuuid
NAME        UUID                                 PARTUUID
nvme0n1                                          
├─nvme0n1p1 ECD7-5834                            e0e58c9c-1dd7-4fdc-9619-36eab6c8fe1c

ubuntu@ubuntu:~$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0003,0004,0000,0001
Boot0003* Ubuntu	HD(1,GPT,e0e58c9c-1dd7-4fdc-9619-36eab6c8fe1c,0x800,0x32000)/File(\EFI\ubuntu\shimx64.efi)

ubuntu@ubuntu:~$ sudo mount /dev/nvme0n1p4 /mnt && sudo cat /mnt/etc/fstab && sudo ls -R /mnt/boot && sudo umount /mnt
# /etc/fstab: static file system information.
UUID=ECD7-5834	/boot/efi vfat umask=0077 0 1

Für mich sieht das korrekt aus - die PartUUID im UEFI stimmt und die UUID in der fstab ebenfalls → ich will aber nicht ausschließen, dass ich irgend was übersehen habe oder falsch interpretiere. ☺

Grüßle, Frieder

Hi,
jetzt wirds natürlich umständlich. Auf dem Rechner startet der Browser nicht und ich muss die Ausgabe in eine Datei umleiten und per USB Stick vom Laptop aus posten. Also hier die Ausgabe:

insgesamt 148
-rwxrwxrwx 1 root root 10661 Apr  4  2024 00_header
-rwxrwxrwx 1 root root  6260 Apr 15  2022 05_debian_theme
-rwxrwxrwx 1 root root 18133 Apr  4  2024 10_linux
-rwxrwxrwx 1 root root 43202 Apr  4  2024 10_linux_zfs
-rwxrwxrwx 1 root root 14513 Apr  4  2024 20_linux_xen
-rwxrwxrwx 1 root root  4228 Apr  8  2024 20_memtest86+
-rwxrwxrwx 1 root root   786 Apr  4  2024 25_bli
-rwxrwxrwx 1 root root 13120 Apr  4  2024 30_os-prober
-rwxrwxrwx 1 root root  1174 Apr  4  2024 30_uefi-firmware
-rwxrwxrwx 1 root root   722 Aug 21  2024 35_fwupd
-rwxrwxrwx 1 root root   214 Apr 21  2011 40_custom
-rwxrwxrwx 1 root root   215 Apr 15  2022 41_custom
-rwxrwxrwx 1 root root   483 Apr 21  2011 README

Da ja auch sudo nicht klappt muss ich also aufs Livesystem wechseln. Nur habe ich bisher noch keinen Kontakt mit chroot gehabt und habe mir die Befehle nur so zusammengereimt. Daher erst mal die Frage ob ich zB die ganzen Verzeichnisse wie aus dem letzten Post wirklich alle so einbinden muss? Ich fürchte nämlich das ich evtl nur durch mein "rumstochern" die Probleme so habe wie sie jetzt sind.

Yeti schrieb:

jetzt wirds natürlich umständlich.

http://termbin.com wäre eine Möglichkeit, die auch für Headless-Server ganz praktisch sein kann (natürlich auf Credentials achten):

echo just testing! | nc termbin.com 9999

Also hier die Ausgabe

Bitte immer mit dem ausgeführten Befehl zusammen und am besten von Prompt zu Prompt.

...
-rwxrwxrwx 1 root root 10661 Apr  4  2024 00_header
...

Hier und folgend sind schon mal Rechte verbogen. Sollte eigentlich so aussehen bei allen Dateien in dem Verzeichnis:

...
-rwxr-xr-x 1 root root 10661 Mar 17 14:20 00_header
...

Ich fürchte nämlich das ich evtl nur durch mein "rumstochern" die Probleme so habe wie sie jetzt sind.

In deinem Anlauf oben sind ein paar Fehler, die Befehle stehen auch so nicht im Wiki (mkdir erzeugt ein Verzeichnis, statt die EFI-Partition an der richtigen Stelle einzubinden, beim chroot fehlt ein / vor bin/bash), aber die Fehler dürften deine Rechte nicht so verbogen haben, das hast du vermutlich anderweitig eingeleitet.

Prüfe doch mal

ls -l /usr/bin/sudo
ls -l /usr/bin/sudoedit
ls -l /etc/sudo.conf
ls -l /etc/sudoers

Wenn hier auch Rechte verbogen sind, dann womöglich auch noch an weiteren Stellen. Damit wird eine saubere Rekonstruktion wohl kaum mehr möglich/sinnvoll sein. An dem Punkt wären wir dann wohl doch wieder bei Neuinstallation.

Hej Yeti,

ich kann Dir nur zu SG²D (SuperGrubDisk) raten, oder, beim Start eines LiveSystems auf dessen grub console wechseln (ctrl c), dort dann

• insmod part_gpt

• set root=hd0,gpt4

• linux /vmlinuz root=/dev/nvme0n1p4

• initrd /initrd-img

• boot

Wenn dann – oder eben mit SG²D – kein firefox startet, tja dann… Dann könntest Du das Ubuntu erneut, aber dann bitte mit gparted rüberkopieren und den bisherigen Vorgang erneut versuchen.

Evt. solltest Du mal das alte Ubuntu (auf sda) überprüfen, merkwürdig scheint mir z.b. auch

-rwxrwxrwx 1 root root   214 Apr 21  2011 40_custom
-rwxrwxrwx 1 root root   215 Apr 15  2022 41_custom

zeige mal den Inhalt dieser beiden, und auch, was ich oben erbeten hatte (sudo grub-mkconfig -o test.txt)

Gruß black tencate

EDIT.: @san04 meinste hier

die Befehle stehen auch so nicht im Wiki (mkdir erzeugt ein Verzeichnis, statt die EFI-Partition an der richtigen Stelle einzubinden,

dann schau noch mal → post 9484499 und auch GRUB 2 von BIOS nach EFI umstellen (Abschnitt „Voraussetzungen“) 4. Punkt!

black_tencate schrieb:

dann schau noch mal

okay, ich war jetzt im von ihm und dir zitierten chroot-Artikel, da ja nur noch ein update-grub ausgeführt werden sollte.

Und das mounten der ESP fehlt ja trotzdem. (Ich weiß, vermutlich auch nicht kritisch, da wir ja annehmen, dass /boot/efi/EFI/ubuntu/grub.cfg in Ordnung ist und der Fehler noch in /boot/grub/grub.cfg liegt, aber die Rechteproblematik sehe ich auch gerade als gravierender an)

Hej san04

sehe jetzt erst, wo Du das Fehlen von mount<ESP> gemeint hast (12.9. 02:55). In der Tat! Allerdings hat er ja vorher das schon mal (nicht mit chroot) richtig gemacht.

Wegen der Rechte sollte ja mal das alte (Quell)system überprüft werden. So langsam denke ich, eine Neuinstallation wäre der geeignetere Schritt.

Gruß black tencate

Bitte nicht soviel auf einmal.
Ich versuche es noch mal zu erklären. @san04 Deshalb habe ich beschrieben wie der Codeblock entstanden ist. Die Ausgabe wurde in eine Datei umgeleitet und per USB Stick von einem anderen Rechner aus gepostet (wie gesagt der Browser startet nicht). Deswegen ist der Prompt nicht dabei. Sonst hätte ich ja auch gleich alles manuell vom Bildschirm abtippen können.
Von termbin habe ich noch nie etwas gehört. Ich würde ganz gerne zunächst auf Wegen bleiben wo ich mit meinem sehr begrenzten Linux Wissen zumindest die Chance habe nachvollziehen zu können was ich da gerade mache.
Dass das Vorgehen bei chroot nicht 100% richtig war habe ich mir schon gedacht. Deswegen habe ich bisher auch noch nicht die "sudo grub-mkconfig -o test.txt" die von black_tencate angemahnt wurde gepostet. Ich will halt nicht die selben Fehler immer wieder machen. Die mkdir Zeile hat sich da reingeschlichen weil ich mich beim mounten der Partition am Eingangspost von black_tencate orientiert habe. Die macht hier natürlich keinen Sinn, dürfte aber auch nicht geschadet haben? Der (fehlende) Slash vor bin/bash ist mir tatsächlich durchgegangen. Komisch das es trotzdem funktioniert hat.
Der Verweis aufs Wiki bezog sich eigentlich auf die Zeile:

for dir in /dev /dev/pts /proc /sys /run; do sudo mount --bind $dir /mnt$dir; done

Sind dort für chroot immer alle Verzeichnisse so nötig, egal was man macht? So eine lange Zeile kann ja auch recht fehlerträchtig sein.

So, alles andere später.

P.S.
Weil wir ja hier schon einige Tage dran sind, kann man vielleicht nachvollziehen warum ich gerne nicht wieder mit einer Neuinstallation von Null anfangen würde. So einige Sessions dieser Art habe ich schon hinter mir weil immer mal wieder irgendetwas nicht startet oder nicht funktionierte und dann alle möglichen Leute gesagt haben: mach mal hier...zeig mal da....gib mal ein.... usw Am Ende hat es dann (nach jeweils sehr langer Zeit) dann evtl doch funktioniert, aber als Noob war man dann hinterher so Schlau wie am Anfang weil man einfach nicht wusste was man da gerade gemacht hat und wo das eigentliche Problem war. Ein Albtraum wenn ich durch einige Sachen wieder neu durch müsste.
Als Beispiele die mich alleine fürs googlen Stunden gekostet haben sei zB die Einbindung des NAS mit den entsprechenden Rechten genannt wo die Zeile hier ja schon in der fstab aufgetaucht ist, oder das wahrscheinlich bekannte Problem mit der abweichenden Uhrzeit bei Dualboot und Win und Linux. An einige andere kann ich mich leider (oder vielleicht sogar besser zum Glück) nicht mehr erinnern.

So kann weiter gehen.
Hier der Versuch das sudo grub-mkconfig -o test.txt vom chroot zu starten:

ubuntu@ubuntu:~$ sudo mount /dev/nvme0n1p4 /mnt
ubuntu@ubuntu:/$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
ubuntu@ubuntu:/$ for dir in /dev /dev/pts /proc /sys /run; do sudo mount --bind $dir /mnt$dir; done
ubuntu@ubuntu:/$ sudo chroot /mnt /bin/bash
root@ubuntu:/# sudo grub-mkconfig -o test.txt
sudo: /etc/sudo.conf is world writable
sudo: /etc/sudo.conf is world writable
sudo: /etc/sudoers ist für alle beschreibbar (world writable)
sudo: Fehler beim Initialisieren des Audit-Plugins sudoers_audit

Dann noch die von san04 geforderten Informationen (ich gehe hier davon aus es sind auch die vom chroot gemeint?)

root@ubuntu:/# ls -l /usr/bin/sudo
-rwxrwxrwx 1 root root 277936 Jun 25 14:42 /usr/bin/sudo
root@ubuntu:/# ls -l /usr/bin/sudoedit
lrwxrwxrwx 1 root root 4 Jun 25 14:42 /usr/bin/sudoedit -> sudo
root@ubuntu:/# ls -l /etc/sudo.conf
-rwxrwxrwx 1 root root 4343 Apr  8  2024 /etc/sudo.conf
root@ubuntu:/# ls -l /etc/sudoers
-rwxrwxrwx 1 root root 1800 Jan 29  2024 /etc/sudoers
root@ubuntu:/# 

Und dann noch die 40_custom und 41_custom

ubuntu@ubuntu:/$ sudo cat /mnt/etc/grub.d/40_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
ubuntu@ubuntu:/$ sudo cat /mnt/etc/grub.d/41_custom
#!/bin/sh
cat <<EOF
if [ -f  \${config_directory}/custom.cfg ]; then
  source \${config_directory}/custom.cfg
elif [ -z "\${config_directory}" -a -f  \$prefix/custom.cfg ]; then
  source \$prefix/custom.cfg
fi
EOF

Ich werde dann jetzt noch den von black_tencate vorgeschlagenen Weg mit der Grub Console versuchen...