lg51
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Hallo Folgendes Problem: Heute morgen mache ich meinen Rechner an und muss mit schrecken feststellen, dass er nicht mehr booted. Konkret: Kubuntu 14.04 booted nicht mehr. Sobald es durchs GRUB-Menü gestartet werden soll, werden Bildschirm, Tastatur-Hintergrundbeleuchtung sowie Festplatten-LED sofort schwarz und bleiben so. D.h. Rechner läuft weiter aber tut nichts. (Selbiges wenn man versucht in recovery mode oder auf früheren Kernel Versionen zu booten.) Die anderen beiden auf dem Rechner installierten Betriebssysteme (Kubuntu 18.04 sowie Windows) booten normal. Da 14.04 aber mein "Produktivsystem" ist welches ich täglich zum Arbeiten brauche, ist das Funktionieren der anderen beiden Systeme höchstens diagnostisch interessant. Ich gehe davon aus, dass das Problem allenfalls bereits bei GRUB liegt und mein 14.04 gar nicht mehr "angesteuert" wird, denn im kern.log und syslog des 14.04er Systems (welche ich vom 18.04er System aus auslesen kann) existiert kein einziger Eintrag mit heutigem Datum. D.h. offensichtlich läuft das System gar nicht erst an (oder zumindest nicht so weit, dass ein erster Log-Eintrag generiert wird). Ich muss dazu sagen, dass ich gestern Abend, nachdem ich mein (dann noch funktionierendes) 14.04 heruntergefahren habe kurz in 18.04 gebooted habe. Dort gab es wohl auch einige Updates. Soweit ich dies nun anhand des dpkg.log nachvollziehen kann, offenbar auch solche für GRUB. (grub-pc, grub-efi, grub-common) Gut möglich also, dass die gestrigen GRUB Updates auf dem 18.04 System den Bootloader so mainpuliert haben, dass er nun mein 14.04 System nicht mehr startet. Die Frage ist nun, wie diagnostiziere und behebe ich das genaue Problem. sudo update-grub hat leider nichts gebracht. Und die OS-Erkennung ist für mein ungeschultes Auge auch nicht offensichtlich falsch:
Ubuntu 14.04.5 LTS (14.04) auf /dev/sda2 gefunden
menuentry 'Ubuntu 14.04.5 LTS (14.04) (auf /dev/sda2)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-1e326cc6-2f62-4570-9cf3-5208f5871255' {
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 1e326cc6-2f62-4570-9cf3-5208f5871255
else
search --no-floppy --fs-uuid --set=root 1e326cc6-2f62-4570-9cf3-5208f5871255
fi
linux /boot/vmlinuz-3.13.0-61-generic root=UUID=1e326cc6-2f62-4570-9cf3-5208f5871255 ro quiet splash $vt_handoff
initrd /boot/initrd.img-3.13.0-61-generic
}
submenu ' (Nicht offensichtlich falsch bedeutet, dass sich 14.04 tatsächlich auf /dev/sda2 befindet. Alles andere kann ich nicht beurteilen.) Jegliche Hilfe sehr geschätzt, 14.04 ist wie gesagt mein Prdouktivsystem an dem ich eigentlich gerade am Arbeiten sein sollte.
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Nachtrag: Inzwischen konnte ich noch einige seltsame und vermutlich durchaus relevante "Zusatzphänomene" und "Entwicklungen" beobachten: 1. Ich KANN in 14.04 booten, wenn ich zuvor in eines der anderen beiden OS gebooted habe und den Rechner dann neu starte. D.h. wenn der Rechner AUS ist und ich ihn dann starte, dann startet anschliessend 14.04 NICHT. (Ebenso startet 14.04 nicht, wenn ich den Rechner via Reset-Button neu starte.) Wenn der Recher hingegen AN war UND in ein anderes OS gebooted und ich ihn anschliessend NEU STARTE, dann booted nach diesem Neustart auch 14.04. Aber eben nur unmittelbar nach dem Neustart aus dem anderen OS. Sobald ein Shutdown dazwischen lag, geht nichts. 2. Die Problematik die ursprünglich nur 14.04 betroffen hat, scheint jetzt auch 18.04 zu betreffen. Also selbes Spiel: Aus NEUSTART heraus kann ich die beiden Kubuntus starten, aus Reset oder "Kaltstart" nicht. Aktuell startet also nur noch Windows "direkt". D.h. ich kann die anderen Systeme jetzt aktuell nur noch booten indem ich Windows boote, dort auf "Neu starten" gehe und anschliessend eines der anderen beiden Systeme in GRUB anwähle.
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Noch ein Nachtrag: Es wird immer seltsamer... meine neusten "Testreihen" haben neue skurrile Resultate gebracht: 1. Der "Timer" in GRUB steht nun plötzlich auf 30 Sekunden. Das war heute Morgen noch nicht so. Ich hatte ihn seit jeher auf zwei Sekunden eingestellt. Die /etc/default/grub beider Systeme (14.04 sowie 18.04) beinhalten diese zwei Sekunden. Ausserdem habe ich die grub.cfg jetzt auch nicht geupdated zwischen den Fällen wo es noch korrekt auf 2 Sekunden stand und jetzt, wo es plötzlich auf 30 Sekunden steht.
Offenbar hat GRUB jetzt selbstständig irgendwelche Settings umgestellt, ohne klaren Anlass und dabei zu berücksichtigen, was in /etc/default/grub steht... ich probier jetzt dann mal noch ein sudo update-grub aus dem 14.0er System um zu sehen, wie es sich danach verhält. 2. Aktuell sieht es so aus, als ob es noch einen "neuen" Weg gäbe, um direkt in 14.04 (18.04 habe ich jetzt nicht mehr getestet) zu booten: Wenn ich den Rechner komplett vom Strom trenne (Kippschalter am Netzteil) und anschliessend einschalte, so bootet er ohne zu Mucken in 14.04. Wenn ich ihn hingegen (z.B. aus 14.04) herunterfahre und dann wieder einschalte, dann bootet er nicht in 14.04 sondern das Bild wird nach GRUB sofort schwarz, ebenso die Tastaturbeleuchtung & die HDD LED. (Also wie im ursprünglich beschriebenen Problem.) Unnötig zu erwähnen, dass es zunehmend schwer fällt, hier noch viel Sinn dahinter zu erkennen. Nachtrag die Dritte: Ich habe jetzt "spasseshalber" nochmal versucht in 18.04 zu booten. Geht jetzt nicht mehr. Kernel panic. Screenshot im Anhang. Ursache für diesen neusten Quatsch? Keine Ahnung. Vielleicht weil ich es gewagt habe, update-grub aus dem 14.04er System aufzurufen? (Hat übrigens den countdown nicht von 30 auf 2 zurück gesetzt...) Jegliche Ideen eurerseits nach wie vor sehr willkommen! EDIT: Screenshot doch nicht im Anhang, da er nicht angezeigt wird, obwohl er hochgeladen ist oO Screenshot sattdessen hier: https://ibb.co/mmv1AU EDIT2: Ja toll. Kaum verlinke ich den Screenshot extern, bequemnt sich das Forum, den vor fünf Minuten hochgeladenen Anhang doch noch anzuzeigen. Offenbar hat sich heute selbst die Foren-Technik gegen mich verschworen 🙄 Noch ein Nachtrag: Habe jetzt festgestellt, dass ich in 18.04 noch booten kann, wenn ich auf eine ältere Kernel-Version gehe (keine Ahnung was der Irrsinn soll... vor ein paar Stunden gings noch mit der aktuellen Kernel Version...) dort stellte ich fest, dass mir der Paket-Update-Manager zwar fünf neue Pakete andrehen will, diese jedoch dann nicht aktualisieren kann. (Bricht ohne irgend eine Fehlermeldung ab.) Also habe ich es in der Konsole mit sudo apt-get upgrade versucht und wurde prompt mit der Meldung Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »sudo dpkg --configure -a« ausführen, um das Problem zu beheben. begrüsst. Dies habe ich nun getan, worauf ein längerer Prozess an mir "vorbeigezogen" ist, u.a. wohl auch irgend ein GRUB und/oder EFI-Update. Jetzt steht ein Reboot an. Wünscht mir Glück, dass danach noch irgendwas funktioniert... Update: Noch den Aktionen aus obigem Nachtrag scheint 18.04 jetzt wieder normal zu booten. Auch der Countdown steht jetzt wieder auf 2 Sekunden. (Ich frage gar nicht...) Noch bemerkenswerter ist, dass nun offenbar auch 14.04 wieder normal zu booten scheint. Allerdings habe ich noch nicht genügend Tests gemacht, um zu sehen, ob dieser Zustand dauerhaft ist.
- Bilder
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10957
|
Hej lg51, lg51 schrieb: ...
Gut möglich also, dass die gestrigen GRUB Updates auf dem 18.04 System den Bootloader so mainpuliert haben, dass er nun mein 14.04 System nicht mehr startet.
bei BIOS/MBR Systemen kommt es zu Konflikten, wenn bei der jeweiligen Installation als Ort für grub die selbe Platte/MBR angegeben wird. Du hast aber anscheinend ein EFI System. Liefere mal Infos dazu (von einem LiveSystem aus): [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS und efibootmgr -v Nützliche Angaben könnte auch das boot info script liefern. Gruß black tencate
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
@black_tentacle Danke für deine Antwort. Ja, es ist eimn UEFI-System. Sorry, falls das anhand meiner bisherigen Angaben nicht klar war. [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS gibt folglich UEFI aus. efibootmgr -v gibt gar nichts aus, aber mit einem sudo davor erhalte ich: BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,000A,0007,0004,0005,0009
Boot0000* Windows Boot Manager HD(1,800,85000,ddd68bfd-7d73-4178-9b7d-99dca5f9775f)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.}...d................
Boot0001* ubuntu HD(1,800,85000,ddd68bfd-7d73-4178-9b7d-99dca5f9775f)File(\EFI\ubuntu\shimx64.efi)
Boot0004* Samsung SSD 840 PRO Series BIOS(2,0,00)AMBO
Boot0005* Crucial_CT256M550SSD1 BIOS(2,0,00)AMBO
Boot0007* TSSTcorp CDDVDW SH-224FB BIOS(3,0,00)AMBO
Boot0009* Samsung SSD 860 EVO 500GB BIOS(2,0,00)AMBO
Boot000A* ubuntu HD(1,800,85000,ddd68bfd-7d73-4178-9b7d-99dca5f9775f)File(\EFI\Ubuntu\grubx64.efi) Diese Ausgabe entspricht auch dem, was in meinem UEFI-BIOS gewählt ist. Der GRUB-Bootloader wird ja entsprechend auch geladen. Die Probleme (sofern sie noch bestehen) fangen erst danach an. Ich muss vielleicht noch folgendes sagen: Das System hat drei Festplatten, wobei auf sda die Bootpartition (sda1), 14.04 (sda2) sowie Windows (sda4) liegen. sdb ist eine reine Datenplatte. Auf sdc liegt 18.04. Der Bootloader bzw. das EFI/SecureBoot Pendant dazu (shimx64.efi) liegt also auf sda1. (Dem entspricht auch die Partitions-ID die für den EFI-Eintrag 0001 angegeben ist, über welchen ja gebooted wird.) Ich gehe davon aus, dass sowohl 14.04 wie auch 18.04 die selbe Partition (eben sda1) jeweils als /boot/efi mounten. Was mir übrigens vorhin noch aufgefallen ist: Es gab auf 18.04 auch ein Update für shim, nicht nur für grub. (Offenbar war da im Update-Prozess ja irgend etwas auf seltsame Weise nicht ganz sauber, siehe die letzten Abschnitte meines vorherigen Beitrages.) Ich muss vielleicht ausserdem noch einmal betonen, dass dies bis heute Morgen alles problemlos funktioniert hat. Der DualBoot zwischen 14.04 und Windows bestand so seit 2014. 18.04 kam als drittes System vor ein, zwei Monaten dazu und hatte sich zunächst auch problemlos ins Ganze integriert. Ich denke also der "Hauptverdacht" liegt schon auf diesen grub/shim Updates die gestern Abend auf 18.04 gekommen sind und möglicherweise irgendwie fehlgeschlagen sind. Aber vielleicht hab ichs ja inzwischen wieder hingekriegt. Muss noch weitere Tests machen, da es sich ja in den letzten Stunden nie "konsistent" verhalten hat.
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10957
|
Hej lg51, lg51 schrieb: ...
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,000A,0007,0004,0005,0009
[...]
Boot0001* ubuntu HD(1,800,85000,ddd68bfd-7d73-4178-9b7d-99dca5f9775f)File(\EFI\ubuntu\shimx64.efi)
[...]
Boot000A* ubuntu HD(1,800,85000,ddd68bfd-7d73-4178-9b7d-99dca5f9775f)File(\EFI\Ubuntu\grubx64.efi) Diese Ausgabe entspricht auch dem, was in meinem UEFI-BIOS gewählt ist. Der GRUB-Bootloader wird ja entsprechend auch geladen. Die Probleme (sofern sie noch bestehen) fangen erst danach an.
bei welchem, Du hast ja 2x "ubuntu" im EFI-Menü, und dabei müssen auch 2 unterschiedliche grub.cfgs erscheinen (so etwa Ubuntu auf sdx und ...auf sdy). Was passiert, wenn Du den anderen wählst? Möglich, daß sich Boot001 beim update 'vorgedrängelt' hat, und Du vorher immer den Boot000A hattest? Zeig einfach doch mal das Ergebnis vom boot info script Gruß black tencate
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Hallo black_tencate Nunja, die Partitions-ID ist ja in beiden Fällen die selbe. D.h. die beiden Einträge "lesen" ihren Bootloader von der selben Partition aus dem selben Ordner. In besagtem Ordner (→ auf sda1 gem. Partitions-ID) liegt eine grub.cfg, die folglich eingelesen werden müsste, unabhängig davon, ob über 0001 oder 000A gebooted wurde. Diese grub.cfg auf sda1 enthält übrigens nur drei Zeilen, wleche wiederum auf die grub.cfg an einer anderen Stelle verweisen. Diese andere Stelle (identfiziert wiederum via Partitions-ID) ist /boot/grub auf /dev/sdc2, d.h. diejenige grub.cfg welche auf der Systempartition meiner 18.04er-Installation liegt. Das macht soweit auch Sinn, denn das neue System hat natürlich seine CFG etabliert bei der Installation. Worauf ich hinauswill: Es dürfte immer die grub.cfg von der 18.04er-Installation gelesen werden. Der Unterschied zwischen 0001 und 000A ist, dass der eine Eintrag die shimx64.efi aufruft, der andere die grubx64.efi. Ich kenne da die Details nicht, aber ich bin heute tagsüber bei meiner Fehlersuche kurz darüber gestolpert. Offenbar ist es wohl so, dass die shimx64 zum Zug kommt, wenn SecureBoot aktiviert ist. (Dann muss shim wohl grub irgendwie "vorgeschaltet" werden, da grub alleine nicht mit SecureBoot klarkommt.) Jetzt müsste ich natürlich noch wissen, ob ich SecureBoot überhaupt aktiviert habe. Pustekuchen. Ich glaube ja, sicher bin ich aber nicht. Wie dem auch sei, im Anhang das Resultat des BootInfoScript. Aber bitte nicht von der Komplexität verwirren lassen. Darin sind beispielsweise zwei boot.cfgs aufgeführt (eine der 14.04er-Installation und eine der 18.04er-Installation), zum Zuge kommen kann aber vermutlich nur noch letztere.
- RESULTS1.txt (95.6 KiB)
- Download RESULTS1.txt
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10957
|
Hej lg51, nur mal kurz vorab (wobei ich aber noch nicht weiß, wie ich bei Deinem Dual-EFI-Linux-Boot durchblicke!): Du hast in Deinem 14.4 noch NIE Systempflege betrieben, dort liegen 19 (in Worten Neunzehn!) kernel so vor sich hin! Nunja, die Partitions-ID ist ja in beiden Fällen die selbe. D.h. die beiden Einträge "lesen" ihren Bootloader von der selben Partition aus dem selben Ordner.
genau das ist ja die Krux; müßte nicht eigentlich jedes System sein eigenens Verzeichnis im EFI-Verzeichnis bekommen?! Oh, wie liebe ich meinen stand-alone grub, da weiß ich wenigstens, was passiert. (Schaust Du im Anhang) Ich würde mal Schritt für Schritt versuchen, von einer grub-Konsole aus ( im grub-Mneü die Taste
C drücken), und dann mit ls die Partitionen abfragen,und dann die Symlinks starten, etwa so
set root=(hdx,gpty)
linux /vmlinuz root=/dev/sdxy
initrd /initrd.img Gruß black tencate
- Multiboot_Win_3x_Ubuntu.txt (4.9 KiB)
- Download Multiboot_Win_3x_Ubuntu.txt
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Hallo black_tencate genau das ist ja die Krux; müßte nicht eigentlich jedes System sein eigenens Verzeichnis im EFI-Verzeichnis bekommen?!
Ich weiss nicht, aber meine Vermutung ist nein. Ein Bootloader (der verschiedene Systeme booten kann) reicht ja. Ich denke aber das Hauptproblem hat sich nun insoweit erledig, dass ich nun 10 mal in Folge mein 14.04 wieder ohne Probleme booten konnte. (Die anderen beiden Systeme hab eich noch nicht getestet.) Ausschlaggebend dürfte wohl die untere Hälfte meines Beitrages vom 13. September 2018 13:42 gewesen sein. Auch wenn mir noch nicht alle "Seltsamkeiten" erklärbar sind, gehe ich daher von folgendem aus: - Es kamen vorgestern Abend neue Updates für grub und shim auf 18.04, bei deren Installation irgend etwas nicht sauber lief. Dadurch wurden die Probleme verursacht. - Indem ich per Zufall darauf gestossen bin (der Updater in 18.04 verhielt sich seltsam), konnte ich via »sudo dpkg --configure -a« die Installation dieser Updates wieder geradebiegen, wodurch das Problem gelöst wurde EDIT: Yay. Auf meinem 14.04 trudeln soeben auch die Grub-Updates ein (siehe Anhang). Ob die wohl den Rechner wieder lahmlegen würden? Auch interessant, dass es offenbar Beta-Versionen sind, die da verteilt werden? Und auch den Hinweis "Breaks shim" finde ich erklärungsbedürftig 😀
- Bilder
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10957
|
Hej lg51, lg51 schrieb: ... genau das ist ja die Krux; müßte nicht eigentlich jedes System sein eigenens Verzeichnis im EFI-Verzeichnis bekommen?!
Ich weiss nicht, aber meine Vermutung ist nein. Ein Bootloader (der verschiedene Systeme booten kann) reicht ja.
Jein! ▶ EFI Grundlagen (Abschnitt „EFI-Bootverzeichnis“) und ▶ specs/esp_registry. Und, wie ich das bisher verstanden habe, sollte ja mit EFI gerade die gegenseitige Beeinflussung vermieden werden. Aber, wenn Dein System jetzt läuft... Btw.: Du könntest ja den 'unterschiedlichen' Gebrauch von "Boot0001* ubuntu" und "Boot000A* ubuntu " dadurch überprüfen, daß Du wahlweise mit und ohne Secureboot
schaust, ob sich im efibootmgr -v entsprechend etwas ändert. Gruß black tencate
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
Ich denke das was du sagst könnte man schon so machen, aber ich denke es ist nicht, wie es in der "Realität" üblicherweise gemacht wird. Zumal es der "Installer" der (K)ubuntu Linux Systeme ja eben so macht, wie es jetzt bei mir aussieht. Das habe ich mir jetzt nicht spezifisch so ausgesucht. Wenn man es nach der "nicht Beeinflussungs Theroie" umsetzen würde, dann würde es wohl so aussehen: - Alle drei Betriebssysteme haben ihren eigenen Bootloader, der jeweils nur dieses eine System starten kann - Welches System gestartet wird hängt folglich davon ab, welcher der drei Bootloader im EFI ausgewäglt wurde (ergo: wenn man nicht das Default-System starten möchte, müsste man gleich bein einschalten des Rechners die entsprechende Taste drücken um ins EFI-Bootmenü zu gelangen) Die Variante die bei mir vorhanden ist (weil es der Linux-Installer ohne grosses Zuitun meinerseits so einrichtet) ist die folgende: - Es gibt technisch gesehen zwei Bootloader, nämlich GRUB und denjenigen von Windows - GRUB kann die beiden Linux-Systeme direkt starten und enthält zudem einen Eintrag, mit dem der Bootloader von Windows geladen werden kann, welcher seinerseits Windows starten kann (fun-fact am Rande: Der Bootloader von Windows enthält wiederum auch einen Eintrag "Linux", mit welchem wieder GRUB geladen werden könnte. So tolerant sind die Microsofties inzwischen schon 😉) - Da in EFI GRUB als Standard gewählt ist, startet mien System immer in GRUB, wo ich dann zwischen den drei Systemen wählen kann Ich denke der "ist Zustand" (also so wie es bei mir ist) ist im Endeffekt komfortabler in der täglichen Anwendung. Aber er ist natürlich ein bisschen komplizierter nachzuvollziehen. Und ja: Das mit 0001 und 000A könnte ich testen. Mache ich jetzt aber nicht, weil ich vermeiden will, dass am Ende dadurch wieder irgend etwas zu spinnen anfängt. So lange es läuft bin ich immer froh und halte mich mit "Experimenten" etwas zurück. ☺
|
black_tencate
Anmeldungsdatum: 27. März 2007
Beiträge: 10957
|
Hej lg51, lg51 schrieb: [...] wie es in der "Realität" üblicherweise gemacht wird. Zumal es der "Installer" der (K)ubuntu Linux Systeme ja eben so macht, wie es jetzt bei mir aussieht.
ja, dann schau doch nur mal, was man anstellen muß, um wenigstens unterschiedliche Namen für "Ubuntu" bekommt... wenn man nicht das Default-System starten möchte, müsste man gleich bein einschalten des Rechners die entsprechende Taste drücken um ins EFI-Bootmenü zu gelangen)
nö, muß man nicht. Hast wohl meinen Anhang nicht gesehen: Einfaches, übersichtliches grub-Menü bei 3x Linux 1x Windows plus 1x Linux auf einer nicht GPT Platte. - Da in EFI GRUB als Standard gewählt ist, startet mien System immer in GRUB, wo ich dann zwischen den drei Systemen wählen kann
nee, nee, da ist "ubuntu" als Erstes in "Bootorder..." gewählt, und die Skripte rund um grub sorgen für ein Mneü, welches dann die anderen auf der/den Plate/n O/S starten kann. (Neu für mich, daß Windows von sich aus Linux booten kann? Mit EasyBCD geht das ja schon lange - in eingeschränkter Weise, kann z.B. 'EFI-Linuxe' nicht direkt booten. Ich denke der "ist Zustand" (also so wie es bei mir ist) ist im Endeffekt komfortabler in der täglichen Anwendung. Aber er ist natürlich ein bisschen komplizierter nachzuvollziehen.
komfortabel? Und ja: Das mit 0001 und 000A könnte ich testen. Mache ich jetzt aber nicht, weil ich vermeiden will, dass am Ende dadurch wieder irgend etwas zu spinnen anfängt. So lange es läuft bin ich immer froh und halte mich mit "Experimenten" etwas zurück. ☺
wohl kein großes Vertrauen? Brauchst doch nur vorübergehend ein sudo efibootmgr -n 000A für einen Versuch 😈 Btw.: Systempflege Gruß black tencate
|
lg51
(Themenstarter)
Anmeldungsdatum: 24. Dezember 2007
Beiträge: 462
|
@ black_tencate Sagen wir mal so: Mein Vertrauen in ein System, welches eines morgens einfach nicht mehr booted weil wohl am Vorabend wieder irgend ein Update hängengeblieben ist ist zumindest nicht gross genug, als dass ich ohne Not irgend etwas daran ändere, jetzt wo es wieder läuft 😀 Hat ja gestern immerhin ein paar bange Stunden gekostet, bis es wieder vernünftig lief. Wäre arbeitstechnisch diese Woche nicht glücklicherweise gerade Spätsommerflaute gewesen, hätte das für mich wesentlich unangenehmer sein können. Neu für mich, daß Windows von sich aus Linux booten kann?
Wenn ich mich recht entsinne ist das bei mir seit 2014 so, also seitdem ich damals Kubuntu 14.04 und Windows 8.1 nebeneinander installiert hatte. Kann aber rückblickend natürlich auch nicht 100%ig ausschliessen, dass ich da vor 4 Jahren nicht noch etwas besonderes angestellt habe, damit das so gekommen ist. Tatsache ist jedenfalls, dass der Windows-Bootloader einen "Linux"-Eintrag enthält. (Nicht dass ich den brauchen würde... denn wenn ich vom GRUB aus erstmal den Windows-Bootloader lade, dann will ich ja Windows starten und nicht doch noch Linux.) komfortabel?
Naja, ich erhalte ohne weiteres zutun ein Bootmenü indem ich aus drei Systemen wählen kann und das nach einer von mir definierten Anzahl Sekunden das von mir definierte Default-System booted wenn ich nichts wähle. Wie es noch komfortabler gehen sollte, kann ich mir jetzt nicht unmittelbar vorstellen. (Gut, zugegeben: Per Tastendruck innert einer halben Sekunde zwischen den drei Systemen switchen zu können wäre noch komfortabler. Aber das dürfte leider nicht möglich sein, so lange ich mir nicht drei parallel laufende Rechner unter den Tisch stellen will ☺) Mein aller erstes Linux (SuSE 7.1, wenn ich mich recht entsinne) wurde noch gebooted, indem ich eine 3,5" Floppydisk mit "LiLo" eingeschoben habe 😀 (Gut, jetzt fragst du dich wahrscheinlich: Wie kann einer, der vor ca. 17 Jahren bereits Erstkontakt mit Linux hatte noch immer so wenig Ahnung von dem System haben. Die traurige Wahrheit ist, dass ich beruflich fast tagtäglich mit der Lösung von Windows-Problemen beschäftigt bin und mir daher zu Hause und im eigenen Büro zur "Entspannung" ein Linux-System halte, bei dem ich mich möglichst NICHT ständig mit den technischen Hintergründen auseinandersetzen will 😉)
|