Puncte:0

De ce os-prober al lui grub adaugă intrări cu `linux` în loc de `linuxefi`

drapel cn

Pe sistemul meu, am două copii ale CentOS 7 instalate și o copie a Windows 10 Pro. Fiecare sistem este bootabil și funcționează corect și este complet actualizat (kernel-uri, pachete, lucrări).

Când alerg grub2-mkconfig în oricare dintre copiile CentOS (o gazdă numită pingu, celălalt pinga, din motive), este creată o nouă configurație grub. O parte din acesta este generată prin șablonul os-prober.

Intrările generate de grub2-mkconfig pentru copia de CentOS am pornit și am început grub2-mkconfig de la sunt corecte. Adică, au intrări de meniu cu linii ca acestea:

linuxefi /vmlinuz-5.4.147-1.el7.elrepo.x86_64 root=/dev/mapper/pinga-root ro crashkernel=auto spectre_v2=retpoline
initrdefi /initramfs-5.4.147-1.el7.elrepo.x86_64.img

Cu toate acestea, intrările generate pentru cealaltă copie a CentOS 7 vor arăta astfel:

linux /vmlinuz-5.4.147-1.el7.elrepo.x86_64 root=/dev/mapper/pingu-root ro crashkernel=auto spectre_v2=retpoline
initrd /initramfs-5.4.147-1.el7.elrepo.x86_64.img

(rețineți că linux și initrd în loc de linuxefi și initrdefi)

Cred că acest lucru se datorează celor patru rânduri din /etc/grub.d/30_os-prober ca linux ${LKERNEL} ${LPARAMS} (etc.) - dar de ce ar fi acesta cazul? De ce os-prober presupune că celelalte copii ale Linux ar trebui să fie întotdeauna începute linux în loc de linuxefi?

Îmi lipsește o setare sau o modificare care ar remedia acest lucru?

Deocamdată, pur și simplu am schimbat aceste rânduri 30_os-prober a avea linuxefi și initrdefi, dar asta pare mai mult decât un pic de hack.

Michael Hampton avatar
drapel cz
Această întrebare pare să fie în afara subiectului: nu acceptăm întrebări generale pe computer. Este posibil să puteți obține ajutor pe site-urile noastre surori [su] sau [unix.se].
telcoM avatar
drapel pk
Ghicire sălbatică: Poate că os-prober ar putea porni alte distribuții Linux bootabile cu UEFI prin încărcarea în lanț în GRUB-ul distribuției respective, cu de ex. `Chainloader /EFI//grubx64.efi`, dar din moment ce aveți *două copii ale aceleiași versiuni majore ale aceleiași distribuții*, nu reușește să găsească/identifică „celălalt GRUB” ca „aceasta este o instanță separată a sistemului de operare” și vede doar nucleul și fișierele initramfs fără încărcător de încărcare UEFI evident care să le însoțească. Apoi iese din cazul special UEFI și încearcă să-l gestioneze cu un cod generic non-UEFI... ceea ce face greșit.
Grismar avatar
drapel cn
@MichaelHampton - Am vrut să nu supăr. Ai spus asta pentru că aceasta este prea mult partea de utilizator a lucrurilor? Stația de lucru despre care vorbesc face de fapt parte dintr-un cluster de noduri HPC pe care le reconfiguram, așa că am venit aici pentru că era mai degrabă un cadru de afaceri. Este de fapt conținutul întrebării în afara subiectului?
Grismar avatar
drapel cn
@telcoM boot-ul, swap, root și home pentru ambele instalări sunt organizate în două grupuri de volume separate, aș fi putut face altceva în configurare pentru a evita ceea ce sugerați? Sau credeți că această situație este mai mult sau mai puțin inevitabilă cu două copii ale aceleiași versiuni majore ale aceleiași distribuții, indiferent?

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.