staging.inyokaproject.org

Hallo,

ich habe hier als Hauptsystem noch Ubuntu 16.04 installiert. Auf einer anderen Partition habe ich dann noch zusätzlich Lubuntu 18.04 minimal mit ubuntu-unity-desktop installiert.

Wenn auf letzterem eine Aktualisierung läuft, wird oft GRUB neu in den MBR installiert, was ich aber nicht will, wegen diesem Fehler. Als Folge davon kann ich dann gar nicht mehr booten, und muss GRUB per chroot in die 16.04-Installation reparieren.

Ich suche also nun einen Weg, wie ich die automatische Installation von GRUB auf dem 18.04-System verhindern kann. Folgendes reicht jedenfalls nicht:

sudo apt-get purge grub-common grub-pc

Hej UlfZibis,

UlfZibis schrieb:

... Wenn auf letzterem eine Aktualisierung läuft, wird oft GRUB neu in den MBR installiert,

...oft..., oops, entweder immer, oder gar nicht! Installier doch bei dem fraglichen System in den PBR, dann hast Du Ruhe.

Gruß black tencate

Falls der Installer Ubiquity heißt gäbe es die Option --no-bootloader, dann wird gar kein Bootloader installiert.

black_tencate schrieb:

UlfZibis schrieb:

... Wenn auf letzterem eine Aktualisierung läuft, wird oft GRUB neu in den MBR installiert,

...oft..., oops, entweder immer, oder gar nicht!

EDIT: Nein, eigentlich nicht. Bei der letzten Aktualisierung passierte das nicht, da passiert wohl nur, wenn ein neuer Kernel inststalliert wird, und dann eben auch update-grub ausgeführt wird.

Installier doch bei dem fraglichen System in den PBR, dann hast Du Ruhe.

Den Trick werde ich mal probieren. Eine saubere Lösung wäre natürlich schöner, wenn ich dann irgendwann mal das 18.04 als Hauptsystem nehmen möchte und den workaround evtl. bis dahin vergessen habe. Du meinst also:

sudo apt-get install grub-efi-amd64-signed && sudo grub-install /dev/sda12 && sudo update-grub

Da frage ich mich, wo das System sich /dev/sda12 merkt, um GRUB dann dort bei der nächsten Aktualisierung wieder zu installieren. Dann müsste ich diesen Wert doch dort auch manuell setzten können? In /etc/default/grub scheint dafür keine Variable zu existieren.

Kätzchen schrieb:

Falls der Installer Ubiquity heißt gäbe es die Option --no-bootloader, dann wird gar kein Bootloader installiert.

Das hatte ich sowieso so gemacht, mit ubiquity -b. Das nutzte aber nichts.

Hallo UlfZibis,

Ist dies ein BIOS oder EFI Rechner und wurden die Systeme auch im gleichen Modus installiert ?

PS: Paar Ausgabeinformationen wären vielleicht hilfreich.

Gruss Lidux

Lidux schrieb:

Ist dies ein BIOS oder EFI Rechner und wurden die Systeme auch im gleichen Modus installiert ?

Das ist ein EFI-Rechner, der nach dieser Anleitung installiert wurde.

PS: Paar Ausgabeinformationen wären vielleicht hilfreich.

Hm, an was denkst Du da z.B.?

Danke für Dein Interesse an der Problemfindung, Ulf

Wenn du eine EFI-Installation hast, dann nützt sudo apt-get purge grub-pc nichts, weil grub-pc nur bei einer BIOS-Installation verwendet wird, respektive sowieso bei der Installation entfernt wird.

Ausserdem wird Grub bei einer EFI-Installation nie in den MBR/PBR installiert, sondern immer in eine EFI-System-Partition.

Entweder du entfernst Grub komplett, (also auch die *efi*-Pakete) oder du bastelst dir Grub so zurecht, dass dein Problem-Grub nicht in /boot/efi/EFI/ubuntu installiert wird, sondern beispielsweise nach /boot/efi/EFI/problemgrub. Dann wird der andere Grub nicht überschrieben.

apt-ghetto schrieb:

Wenn du eine EFI-Installation hast, dann nützt sudo apt-get purge grub-pc nichts, weil grub-pc nur bei einer BIOS-Installation verwendet wird, respektive sowieso bei der Installation entfernt wird.

grub-pc wird leider auch auf der EFI-Installation hier immer wieder automatisch installiert – siehe Achtung-Box – was immer wieder die automatische Entfernung von grub-efi-amd64 zu Folge hat. Dass hoffte ich mit dem purge grub-pc verhindern zu können.

Ausserdem wird Grub bei einer EFI-Installation nie in den MBR/PBR installiert, sondern immer in eine EFI-System-Partition.

Stimmt. Meine Annahme war, dass auch bei EFI im MBR und den darauf folgenden versteckten Sektoren Änderungen vorgenommen werden. Also gut, dass ich noch hintenan war mit dem Versuch, in den PBR zu installieren.

Entweder du entfernst Grub komplett, (also auch die *efi*-Pakete)

Genau das ist ja meine Problemstellung hier, denn sudo apt-get purge grub-efi-amd64 grub-efi-amd64-signed nützte ebenfalls nichts (Merkwürdigerweise werden dabei die Inhalte von /boot/grub und der mount von /boot/efi per fstab nicht entfernt). grub-common hatte ich alternativ ausgewählt, da es ja von beiden GRUBs benötigt wird.

oder du bastelst dir Grub so zurecht, dass dein Problem-Grub nicht in /boot/efi/EFI/ubuntu installiert wird, sondern beispielsweise nach /boot/efi/EFI/problemgrub. Dann wird der andere Grub nicht überschrieben.

Könnte evtl. gehen.
EDIT: Ich kenne aber nur grub-install --efi-directory /boot/efi. Damit würde GRUB wieder in /boot/efi/EFI/Ubuntu installiert (Bei mit hat das Verzeichnis ein großes 'U').

Unabhängig davon, ob das hilft, würde mich aber auch interessieren, wie man allgemein die immer wieder neue Installation per apt-get dist-upgrade von explizit deinstallierten Paketen abstellen kann. Deshalb hatte ich die Fragestellung anfangs etwas allgemeiner gefasst und nicht auf die spezielle 32-Bit-Installation auf EFI verwiesen.

EDIT: Um Ideen zu sammeln liste ich hier mal:

 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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

ich@ASUS-F200MA:~$  ls -lR /boot
/boot:
insgesamt 122565
-rw-r--r-- 1 root root  1524942 Mai 15 07:41 abi-4.15.0-22-generic
-rw-r--r-- 1 root root  1524815 Mai 23 18:54 abi-4.15.0-23-generic
-rw-r--r-- 1 root root   218405 Mai 15 07:41 config-4.15.0-22-generic
-rw-r--r-- 1 root root   218405 Mai 23 18:54 config-4.15.0-23-generic
drwx------ 3 root root     1024 Jan  1  1970 efi
drwxr-xr-x 5 root root     4096 Jun 25 01:19 grub
-rw-r--r-- 1 root root 49965912 Jun 25 01:15 initrd.img-4.15.0-22-generic
-rw-r--r-- 1 root root 50109327 Jun 25 01:16 initrd.img-4.15.0-23-generic
-rw-r--r-- 1 root root   182704 Jan 28  2016 memtest86+.bin
-rw-r--r-- 1 root root   184380 Jan 28  2016 memtest86+.elf
-rw-r--r-- 1 root root   184840 Jan 28  2016 memtest86+_multiboot.bin
-rw-r--r-- 1 root root      583 Mai 15 07:41 retpoline-4.15.0-22-generic
-rw-r--r-- 1 root root      583 Mai 23 18:54 retpoline-4.15.0-23-generic
-rw------- 1 root root  3157251 Mai 15 07:41 System.map-4.15.0-22-generic
-rw------- 1 root root  3157118 Mai 23 18:54 System.map-4.15.0-23-generic
-rw------- 1 root root  7517824 Mai 15 07:41 vmlinuz-4.15.0-22-generic
-rw------- 1 root root  7519872 Mai 23 18:54 vmlinuz-4.15.0-23-generic
ls: Öffnen von Verzeichnis '/boot/efi' nicht möglich: Keine Berechtigung

/boot/grub:
insgesamt 2368
drwxr-xr-x 2 root root    4096 Apr 27 23:53 fonts
-rw-r--r-- 1 root root    1024 Jun 25 01:21 grubenv
drwxr-xr-x 2 root root    4096 Jun 25 01:22 locale
-rw-r--r-- 1 root root 2397557 Jun 25 01:21 unicode.pf2
drwxr-xr-x 2 root root   12288 Jun 25 01:22 x86_64-efi

/boot/grub/fonts:
insgesamt 2344
-rw-r--r-- 1 root root 2397557 Jun 25 01:22 unicode.pf2

/boot/grub/locale:
insgesamt 268
-rw-r--r-- 1 root root 134305 Jun 25 01:22 de.mo
-rw-r--r-- 1 root root    976 Jun 25 01:22 en_AU.mo
-rw-r--r-- 1 root root    512 Jun 25 01:22 en_CA.mo
-rw-r--r-- 1 root root   4771 Jun 25 01:22 en_GB.mo
-rw-r--r-- 1 root root 120006 Jun 25 01:22 en@quot.mo

/boot/grub/x86_64-efi:
insgesamt 3212
-rw-r--r-- 1 root root  15392 Jun 25 01:22 acpi.mod
-rw-r--r-- 1 root root   1928 Jun 25 01:22 adler32.mod
-rw-r--r-- 1 root root   7960 Jun 25 01:22 affs.mod
[... und viele mehr ...]

  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
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124

ich@ASUS-F200MA:~$  sudo ls -lR /boot/efi
/boot/efi:
insgesamt 1
drwx------ 7 root root 1024 Dez 13  2016 EFI

/boot/efi/EFI:
insgesamt 5
drwx------ 7 root root 1024 Aug 13  2018 ASUS
drwx------ 2 root root 1024 Dez 13  2016 Boot
drwx------ 3 root root 1024 Jan 30  2016 Microsoft
drwx------ 2 root root 1024 Jun 16  2017 Ubuntu
drwx------ 3 root root 1024 Dez 11  2016 Ubuntu-64

/boot/efi/EFI/ASUS:
insgesamt 61
-rwx------ 1 root root 32768 Aug 13  2018 BCD
-rwx------ 1 root root 24576 Aug 13  2018 BCD.LOG
-rwx------ 1 root root     0 Aug 13  2018 BCD.LOG1
-rwx------ 1 root root     0 Aug 13  2018 BCD.LOG2
drwx------ 2 root root  1024 Aug 13  2018 de-DE
drwx------ 2 root root  1024 Aug 13  2018 en-GB
drwx------ 2 root root  1024 Aug 13  2018 fr-FR
drwx------ 2 root root  1024 Aug 13  2018 it-IT
drwx------ 2 root root  1024 Aug 13  2018 nl-NL

/boot/efi/EFI/ASUS/de-DE:
insgesamt 60
-rwx------ 1 root root 32768 Aug 13  2018 ASBOOT.tag
-rwx------ 1 root root 28672 Aug 13  2018 ASBOOT.tag.LOG

/boot/efi/EFI/ASUS/en-GB:
insgesamt 60
-rwx------ 1 root root 32768 Aug 13  2018 ASBOOT.tag
-rwx------ 1 root root 28672 Aug 13  2018 ASBOOT.tag.LOG

/boot/efi/EFI/ASUS/fr-FR:
insgesamt 60
-rwx------ 1 root root 32768 Aug 13  2018 ASBOOT.tag
-rwx------ 1 root root 28672 Aug 13  2018 ASBOOT.tag.LOG

/boot/efi/EFI/ASUS/it-IT:
insgesamt 60
-rwx------ 1 root root 32768 Aug 13  2018 ASBOOT.tag
-rwx------ 1 root root 28672 Aug 13  2018 ASBOOT.tag.LOG

/boot/efi/EFI/ASUS/nl-NL:
insgesamt 60
-rwx------ 1 root root 32768 Aug 13  2018 ASBOOT.tag
-rwx------ 1 root root 28672 Aug 13  2018 ASBOOT.tag.LOG

/boot/efi/EFI/Boot:
insgesamt 1207
-rwx------ 1 root root 1116024 Jun 25 01:22 bootx64.efi
-rwx------ 1 root root  119808 Dez 12  2016 fallback.efi

/boot/efi/EFI/Microsoft:
insgesamt 4
drwx------ 40 root root 4096 Jan 30  2016 Boot

/boot/efi/EFI/Microsoft/Boot:
insgesamt 4807
-rwx------ 1 root root   40960 Apr 27 16:54 BCD
-rwx------ 1 root root   36864 Aug 13  2018 BCD.LOG
-rwx------ 1 root root       0 Aug 13  2018 BCD.LOG1
-rwx------ 1 root root       0 Aug 13  2018 BCD.LOG2
drwx------ 2 root root    1024 Aug 13  2018 bg-BG
-rwx------ 1 root root 1617240 Jun 14  2014 bootmgfw.efi
-rwx------ 1 root root 1614168 Jun 14  2014 bootmgr.efi
-rwx------ 1 root root   65536 Aug 13  2018 BOOTSTAT.DAT
-rwx------ 1 root root    4247 Jun 18  2013 boot.stl
drwx------ 2 root root    1024 Aug 13  2018 cs-CZ
drwx------ 2 root root    1024 Aug 13  2018 da-DK
drwx------ 2 root root    1024 Aug 13  2018 de-DE
[... und viele mehr ...]

/boot/efi/EFI/Microsoft/Boot/bg-BG:
insgesamt 152
-rwx------ 1 root root 77152 Aug 22  2013 bootmgfw.efi.mui
-rwx------ 1 root root 77152 Aug 22  2013 bootmgr.efi.mui

/boot/efi/EFI/Microsoft/Boot/cs-CZ:
insgesamt 195
-rwx------ 1 root root 76128 Aug 22  2013 bootmgfw.efi.mui
-rwx------ 1 root root 76128 Aug 22  2013 bootmgr.efi.mui
-rwx------ 1 root root 45408 Aug 22  2013 memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/da-DK:
insgesamt 193
-rwx------ 1 root root 75616 Aug 22  2013 bootmgfw.efi.mui
-rwx------ 1 root root 75616 Aug 22  2013 bootmgr.efi.mui
-rwx------ 1 root root 45408 Aug 22  2013 memtest.efi.mui

/boot/efi/EFI/Microsoft/Boot/de-DE:
insgesamt 199
-rwx------ 1 root root 78688 Aug 22  2013 bootmgfw.efi.mui
-rwx------ 1 root root 78688 Aug 22  2013 bootmgr.efi.mui
-rwx------ 1 root root 45920 Aug 22  2013 memtest.efi.mui

[... und viele mehr ...]

/boot/efi/EFI/Ubuntu:
insgesamt 3407
-rwx------ 1 root root     127 Dez 11  2016 grub_10.cfg
-rwx------ 1 root root     126 Dez 11  2016 grub_7.cfg
-rwx------ 1 root root     126 Jun 25 01:50 grub.cfg
-rwx------ 1 root root 1133944 Jun 25 01:50 grubx64.efi
-rwx------ 1 root root 1153336 Jun 25 01:50 mmx64.efi
-rwx------ 1 root root 1196736 Jun 25 01:50 shimx64.efi

/boot/efi/EFI/Ubuntu-64:
insgesamt 5803
drwx------ 2 root root    1024 Nov  7  2016 fw
-rwx------ 1 root root   64352 Nov  7  2016 fwupx64.efi
-rwx------ 1 root root     127 Dez 11  2016 grub_10.cfg
-rwx------ 1 root root     126 Dez 11  2016 grub_7.cfg
-rwx------ 1 root root     127 Dez 11  2016 grub.cfg
-rwx------ 1 root root 1103224 Nov 29  2016 grubx64.efi
-rwx------ 1 root root 1103224 Dez  5  2016 grubx64_orig.efi
-rwx------ 1 root root 1103224 Nov 29  2016 grubx64_ubuntu-64.efi
-rwx------ 1 root root 1271672 Dez  8  2016 MokManager.efi
-rwx------ 1 root root 1289424 Dez  8  2016 shimx64.efi

/boot/efi/EFI/Ubuntu-64/fw:
insgesamt 0

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

ich@ASUS-F200MA:~$  sudo blkid
/dev/sda1: LABEL="SYSTEM" UUID="BC5C-B7DD" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="671281f8-513a-46b7-8cd7-ff6fed6d5eca"
/dev/sda2: LABEL="Recovery" UUID="3C5C0FE55C0F98B2" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="afcadc4b-d094-4fd4-828e-12c41de4ca52"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="a50e2ce3-e04e-46e5-bd68-e264417933cb"
/dev/sda4: LABEL="Windows" UUID="A4FA421DFA41EC5C" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="547fb42a-c27c-4058-8cfe-a2294c254a66"
/dev/sda5: LABEL="Daten" UUID="5006CF502738517B" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="05bd9124-2d60-4daa-b415-8e0b58570750"
/dev/sda6: LABEL="Restore" UUID="1ECA2114CA20E9AB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="db96c46b-c31a-4e9e-8298-c6cc68a0c879"
/dev/sda7: LABEL="Ubuntu" UUID="3f93ffae-d9b6-4784-9d11-55cd73e74a37" TYPE="ext4" PARTLABEL="EXT4 partition 7" PARTUUID="90a7d5cf-4f41-493b-b119-0d7fd7651e12"
/dev/sda8: LABEL="home" UUID="8db5ce9f-7dfb-45b8-a6ad-fa6b64548786" TYPE="ext4" PARTLABEL="EXT4 partition 8" PARTUUID="d99152a0-5667-4a05-b548-8488d45fae52"
/dev/sda9: LABEL="Sicherung" UUID="5AB717412821EE28" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="a20b48bf-a3f8-4211-91a3-8441d0be3138"
/dev/sda10: LABEL="Ubuntu-64" UUID="128c85cf-7bab-4902-81fb-4fdca7aa65c3" TYPE="ext4" PARTLABEL="EXT4 partition 10" PARTUUID="6074faf6-89f8-4d7a-8a76-83830193e89a"
/dev/sda11: LABEL="home-64" UUID="fd2d5698-646f-42af-857b-afb30cb590a4" TYPE="ext4" PARTLABEL="EXT4 partition 11" PARTUUID="66d2fff8-f2c7-47f1-8592-e9b68469037e"
/dev/sda12: LABEL="Ubuntu-18.04" UUID="bf95f41f-5913-480f-9ab5-c100c94f1a9f" TYPE="ext4" PARTLABEL="EXT4 partition 12" PARTUUID="42041a6c-5f98-4b85-a270-4c9921a62e88"
/dev/sda13: UUID="38e6603c-6b17-488a-9613-7341e8e89274" TYPE="swap" PARTLABEL="SWAP partition 13" PARTUUID="d59a2106-69ad-41f1-bd8c-dfcbea20644b"
/dev/sda14: UUID="ee0a1be9-caa7-4313-8d43-a2ddd6109789" TYPE="swap" PARTLABEL="SWAP partition 14" PARTUUID="77683812-7acf-4422-aedb-68b6b037861a"
/dev/sda15: LABEL="home-18.04" UUID="5a6f21f9-c515-44f9-9eb2-03aab7cf362f" TYPE="ext4" PARTLABEL="EXT4 partition 15" PARTUUID="c14da769-a25b-433b-a9fe-d21f754bdaeb"

UlfZibis schrieb:

apt-ghetto schrieb:

Wenn du eine EFI-Installation hast, dann nützt sudo apt-get purge grub-pc nichts, weil grub-pc nur bei einer BIOS-Installation verwendet wird, respektive sowieso bei der Installation entfernt wird.

grub-pc wird leider auch auf der EFI-Installation hier immer wieder automatisch installiert – siehe Achtung-Box – was immer wieder die automatische Entfernung von grub-efi-amd64 zu Folge hat. Dass hoffte ich mit dem purge grub-pc verhindern zu können.

Nein, grub-pc wird bei einer EFI-Installation nicht installiert. Falls das bei dir doch der Fall ist, dann hast du noch weitere Altlasten.

Entweder du entfernst Grub komplett, (also auch die *efi*-Pakete)

Genau das ist ja meine Problemstellung hier, denn sudo apt-get purge grub-efi-amd64 grub-efi-amd64-signed nützte ebenfalls nichts

Dann hast du immer noch grub-common (und grub2-common), die du auch entfernen solltest.

(Merkwürdigerweise werden dabei die Inhalte von /boot/grub und der mount von /boot/efi per fstab nicht entfernt).

Ob die Dateien nach der Deinstallation entfernt werden, hängt meines Wissens davon ab, ob es so im Package angegeben wurde. Aber mit der Paketierung kenne ich mich auch nicht gut genug aus.

Und die fstab wird üblicherweise nur bei der Installation vom System verändert. Alle anderen Änderungen müssen vom Administrator manuell angepasst werden.

oder du bastelst dir Grub so zurecht, dass dein Problem-Grub nicht in /boot/efi/EFI/ubuntu installiert wird, sondern beispielsweise nach /boot/efi/EFI/problemgrub. Dann wird der andere Grub nicht überschrieben.

Könnte evtl. gehen.
EDIT: Ich kenne aber nur grub-install --efi-directory /boot/efi. Damit würde GRUB wieder in /boot/efi/EFI/Ubuntu installiert (Bei mit hat das Verzeichnis ein großes 'U').

In etwa so: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=problemgrub

Aber eigentlich müsstest du herausfinden, wo das bei Ubuntu gesteuert wird. Sonst wird beim nächsten grub-install wieder ins falsche Verzeichnis installiert.

Unabhängig davon, ob das hilft, würde mich aber auch interessieren, wie man allgemein die immer wieder neue Installation von Paketen per apt-get dist-upgrade abstellen kann. Deshalb hatte ich die Fragestellung anfangs etwas allgemeiner gefasst und nicht auf die spezielle 32-Bit-Installation auf EFI verwiesen.

Wahrscheinlich suchst du Apt-Pinning. Aber vermutlich hast du ein grundlegendes Problem und deswegen funktioniert die Paketverwaltung nicht wie gewünscht.

apt-ghetto schrieb:

Nein, grub-pc wird bei einer EFI-Installation nicht installiert. Falls das bei dir doch der Fall ist, dann hast du noch weitere Altlasten.

Hm, welche Altlasten könnten das denn sein, denn das Problem existiert schon mit der Neuinstallation nach der zitierten Anleitung (Verbesserungen gerne erwünscht)?

Entweder du entfernst Grub komplett, (also auch die *efi*-Pakete)

Genau das ist ja meine Problemstellung hier, denn sudo apt-get purge grub-efi-amd64 grub-efi-amd64-signed nützte ebenfalls nichts

Dann hast du immer noch grub-common (und grub2-common), die du auch entfernen solltest.

Soweit mich mich erinnern kann, wurden die dann immer automatisch mit-entfernt, jedenfalls sind sie z.Zt. nicht installiert.

Und die fstab wird üblicherweise nur bei der Installation vom System verändert. Alle anderen Änderungen müssen vom Administrator manuell angepasst werden.

Das passiert hier durch apt-get install grub-efi-amd64 bzw. install-grub (jedenfalls hatte ich da nichts manuell gemacht). Demnach wäre für mich die Logik, dass der Umkehr-Vorgang den Eintrag dann auch wieder löschen müsste.

In etwa so: grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=problemgrub

Gute Idee, danke!

Aber eigentlich müsstest du herausfinden, wo das bei Ubuntu gesteuert wird. Sonst wird beim nächsten grub-install wieder ins falsche Verzeichnis installiert.

Genau die Frage hatte ich dabei schon im Hinterkopf, wollte aber erst mal abwarten, wie das mit dem alternativen Verzeichnis überhaupt gehen könnte.

Unabhängig davon, ob das hilft, würde mich aber auch interessieren, wie man allgemein die immer wieder neue Installation von Paketen per apt-get dist-upgrade abstellen kann. Deshalb hatte ich die Fragestellung anfangs etwas allgemeiner gefasst und nicht auf die spezielle 32-Bit-Installation auf EFI verwiesen.

Wahrscheinlich suchst du Apt-Pinning.

Daran hatte ich gedacht, oder etwas mir nicht bekanntes alternatives. Aber immer, wenn ich mich mit Apt-Pinning versucht habe, funktionierte das nicht so wie erwartet. Beim Firefox z.B. wurden trotz Pinning auf Version 56 die Spachpakete der neueren Versionen installiert, sodass dann nichts mehr funktionierte. Deshalb würde ich mich sehr über Hinweise eines erfahrenen Apt-Pinners freuen, bevor ich mich wieder uferlos verirre, und evtl. alles mögliche zerschieße.

Aber vermutlich hast du ein grundlegendes Problem und deswegen funktioniert die Paketverwaltung nicht wie gewünscht.

Das grundlegende Problem ist, dass an 32-Bit-Ubuntu auf einer 64-Bit-EFI-Umgebung nicht gedacht wurde, und ich deshalb tricksen muss, und dafür suche ich Hinweise.

Hallo UlfZibis,

Es gibt auch eine 32-bit Bootloaderdatei (32-bit Rechner) für ein 64-bit Ubuntusystem. Die muss nur runtergeladen werden und in den entsprechenden Ordner mit Root Rechten kopiert werden.

Vielleicht hilft dir dies.

Gruss Lidux

Lidux schrieb:

Es gibt auch eine 32-bit Bootloaderdatei (32-bit Rechner) für ein 64-bit Ubuntusystem. Die muss nur runtergeladen werden und in den entsprechenden Ordner mit Root Rechten kopiert werden.

Hm, und wo findet man die? Außerdem ich habe doch hier den umgekehrten Fall.

@ apt-ghetto:

Das grundlegende Problem, dass man nicht will, dass einem das Zweit-System die GRUB-Installation des Erst-Systems überschreibt, gibt es ja auch ohne die EFI/BIOS- und die 32-Bit/64-Bit-Problematik, weshalb ich die Frage anfangs allgemein gestellt hatte.

Hallo UlfZibis,

Lt. deiner Anleitung hast du das 32-bit Betriebssystem ohne Grub2 installiert. Wozu dann das nachträgliche herumdoktern an dieser. Du brauchst doch da nur per Synaptic kontrollieren ob da keine Pakete von Grub installiert sind. Wenn ja einfach sperren. Dann nur noch in dem anderen System ein update-grub machen damit der Eintrag im NVRAM geschrieben wird.

PS: Die 32-Bootloader Datei vorher noch in den richtigen Ordner kopieren lt. deiner Anleitung

Bei Firefox musst du die Sprachpakete natürlich auch sperren. Achtung: Ein Update per Terminal darf danach niemals gemacht werden.

Gruss Lidux

Lidux schrieb:

Lt. deiner Anleitung hast du das 32-bit Betriebssystem ohne Grub2 installiert. Wozu dann das nachträgliche herumdoktern an dieser.

Da ich ja über kurz oder lang auf 18.04 umsteigen möchte, hatte ich das Installieren von grub-efi-amd64-signed schon probiert, nur stieß ich dann auf den Fehler. Solange das nicht geht, werden ich das 16.04-System mindestens noch zum Booten brauchen. Nachdem ich grub-efi-amd64-signed wieder deinstalliert hatte, passierte dann die Unannehmlichkeit, dass die Aktualisierung nun immer penetrant grub-pc installiert. Ich werde aber mal kontrollieren, ob das Problem auch mit der nackten Installation ohne GRUB auftritt.

Du brauchst doch da nur per Synaptic kontrollieren ob da keine Pakete von Grub installiert sind. Wenn ja einfach sperren.

Damit müsste ja dann eigentlich meine Ursprungsfrage beantwortet sein. Kann man den Effekt nicht auch vom Terminal aus mit apt- oder dpkg-Werkzeugen erzielen, oder heißt das, dass die Sperre nur in Zusammenhang mit Synaptic wirksam ist. Dann würde sicher auch die automatische Aktualisierung das ignorieren, und ich hätte mein Problem immer noch.

PS: Die 32-Bootloader Datei vorher noch in den richtigen Ordner kopieren lt. deiner Anleitung

Welche Datei meinst Du damit eigentlich genau?

Bei Firefox musst du die Sprachpakete natürlich auch sperren.

Die Sprachpakete hatte ich natürlich auch auf Version 56 gepinnt, doch die Paketverwaltung hat das einfach ignoriert, und mir die Sprachpakete für Version 57 installiert und genau dadurch hatte ich dann ein Problem. Leider fand sich dann auch kein freundlicher Supporter, der mir helfen wollte, dieses merkwürdige Verhalten zu beheben, weil Version 56 ja mit 57 aus dem Support gefallen sei.

Achtung: Ein Update per Terminal darf danach niemals gemacht werden.

Du meinst per apt-get dist-upgrade? Aber die automatische Aktualisierung macht doch genau dasselbe oder? ... und die kann ich doch nicht einfach monatelang aussetzen.

So, jetzt bin ich gerade dabei, ein neues Ubuntu 18.04, allerdings auf einem BIOS-Rechner, als Zweitsystem zu installieren. Wie sich zeigt, sind Deine Annahmen leider falsch.

Lidux schrieb:

Lt. deiner Anleitung hast du das 32-bit Betriebssystem ohne Grub2 installiert. Wozu dann das nachträgliche herumdoktern an dieser. Du brauchst doch da nur per Synaptic kontrollieren ob da keine Pakete von Grub installiert sind.

Genau dabei zeigt sich, dass die GRUB-Pakete mit ubuquity -b dennoch installiert wurden, nur die Installation im MBR wurde unterlassen. Das dürfte aber dann spätestens bei der Nächsten Aktualisierung von GRUB oder eines Kernels dann doch automatisch passieren, und damit würde GRUB beim Booten sich auf die Konfiguration im Zweitsystem beziehen. Sowas muss sich doch irgendwie verhindern lassen.

Wenn ja einfach sperren.

Auch das habe ich dann gemacht. Allerdings steht da "Diese Version Sperren", woraus ich schieße, dass wenn eine neue Version verfügbar ist, die dann dennoch installiert wird. Dann habe ich in Synaptic "Aktualisierungen vormerken" angewählt. Und siehe da ... auch hier erscheinen in der langen Liste der zu installierenden Pakete wieder brav die GRUB-Pakete; ein neuer Kernel ist auch dabei. Nutzt also leider nichts die Methode.

Bei Firefox musst du die Sprachpakete natürlich auch sperren.

Oben hatte ich dazu schon was geschrieben, nun aber noch eine Frage: Bewirkt das Sperren im Hintergrund ein Apt-Pinning, oder wie geht das.