Puncte:0

De ce această gazdă Linux bazată pe EFI continuă să pornească pe a doua unitate?

drapel ls

Am mai multe servere cu aceeași configurare de bază: unitate primară cu VFAT /boot/efi, XFS /boot și XFS / pe LVM; și unitatea secundară cu exact același lucru, fiecare partiție rsincronizată noaptea.

Am, de asemenea, un script care se asigură (teoretic) că grub și EFI și așa mai departe sunt configurate astfel încât atunci când serverul este repornit, pornește de pe unitatea principală. În mod normal, acest lucru funcționează, dar pe acest server, se pare că preferă întotdeauna unitatea secundară, chiar și atunci când schimb unitățile. Adică: se pare că pornește în mod constant unitatea în al doilea slot (deși merită remarcat faptul că, din moment ce am conectat singur unitățile, este absolut posibil ca al doilea slot să enumere de fapt primul pe placa de bază, dar nu văd de ce ar face asta. chiar și materie).

Iată situația LVM:

rlpowell@stodi> sudo pvs
  PV VG Fmt Attr PSize PFree
  /dev/sda3 stodi_orange_2021_10 lvm2 a-- 930,55 g 0
  /dev/sdb3 stodi_pink_2020_10 lvm2 a-- 930,55 g 0
rlpowell@stodi> sudo lvs
  LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
  root stodi_orange_2021_10 -wi-ao---- 930,55 g
  root stodi_pink_2020_10 -wi-ao---- 930,55 g

(Pe această gazdă, portocaliul este în prezent principal, iar roz este în prezent secundar.)

Când este în funcțiune, avem:

/dev/mapper/stodi_orange_2021_10-root 931G 686G 245G 74% /
/dev/sda2 483M 256M 228M 53% /boot
/dev/sda1 488M 6,4M 482M 2% /boot/efi

rlpowell@stodi> cat /proc/partitions
nume major minor #blocuri

   8 0 976762584 sda
   8 1 499712 sda1
   8 2 499712 sda2
   8 3 975762119 sda3
  11 0 1048575 sr0
 253 0 975757312 dm-0
   8 16 976762584 sdb
   8 17 499712 sdb1
   8 18 499712 sdb2
   8 19 975762119 sdb3
 253 1 975757312 dm-1

Iată situația EFI:

rlpowell@stodi> sudo efibootmgr -v
Boot Current: 0013
Timeout: 30 de secunde
Comanda de pornire: 0001,0015,000C,0000,0013,0002,0003,0004,0005,0006,0007,0008,0009,000A,000B,000C,000D,000E,000,010,000,000,100,000 0016
Boot0000 Meniu de pornire FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)....ISPH
Boot00000013* Samsung SSD 870 EVO 1TB PciRoot(0x0)/Pci(0x11,0x4)/Sata(0,0,0)N.....YM....R,Y.....ISPH
Boot0001* stodi_orange_2021_10 HD(1,GPT,cb8227c2-dc52-fc4f-bd8f-b46f71104428,0x800,0xf4000)/File(\EFI\fedora\shimx64.efi)
Boot0002 Bios Setup FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0003 Gestionare ROM opțiune terță parte FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0004 System Diagnostics FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0005 System Diagnostics FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0006 System Diagnostics FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0007 System Diagnostics FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0008 Boot Menu FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0009 USB: BBS(65535,,0x0)/PciRoot(0x0)/Pci(0x1d,0x0)......ISPH
Boot000A Network Boot FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot000B* Samsung SSD 870 EVO 1TB BBS(HD,Harddisk1,0x400)/PciRoot(0x0)/Pci(0x11,0x4)......ISPH
Boot000C* IBA GE Slot 00C8 v1550 BBS(Network, Network1,0x0)/PciRoot(0x0)/Pci(0x19,0x0)......ISPH
Boot000D* IBA GE Slot 0500 v1550 BBS(Network, Network1,0x0)/PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)......ISPH
Boot000E* IBA GE Slot 0500 v1550 BBS(Network, Network1,0x0)/PciRoot(0x0)/Pci(0x1c,0x0)/Pci(0x0,0x0)......ISPH
Boot000F USB: PciRoot(0x0)/Pci(0x1d,0x0)N.....YM....R,Y.....ISPH
Boot0010* hp DVDRW DU8A6SH PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,0,0)N.....YM....R,Y.....ISPH
Boot0011* hp DVDRW DU8A6SH BBS(CDROM,CDROM1,0x400)/PciRoot(0x0)/Pci(0x1f,0x2)......ISPH
Boot0012 Informații de sistem FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0013* Fedora HD(1,GPT,cb8227c2-dc52-fc4f-bd8f-b46f71104428,0x800,0xf4000)/File(\EFI\fedora\shimx64.efi)....ISPH
Boot0014 HP Recovery FvVol(cdbb7b35-6833-4ed6-9ab2-57d2acddf6f0)/FvFile(9d8243e8-8381-453d-aceb-c350ee7757ca)......ISPH
Boot0015* stodi_pink_2020_10 HD(1,GPT,3dc251c1-c845-1f4b-9a0b-ebc15792efd6,0x800,0xf4000)/File(\EFI\fedora\shimx64.efi)
Boot0016* Samsung SSD 860 EVO 1TB PciRoot(0x0)/Pci(0x11,0x4)/Sata(1,0,0)N.....YM....R,Y.....ISPH

Și iată grub:

rlpowell@stodi> lista sudo grub2-editenv /boot/grub2/grubenv
save_entry=a7afe39309446d92f17c60bc5467f619-5.14.9-200.fc34.x86_64
kernelopts=root=/dev/stodi_orange_2021_10/root ro rd.auto enforcing=0 crashkernel=auto video=DP-1:1280x1024-32@60e
boot_success=1
boot_indeterminate=0

rlpowell@stodi> sudo cat /boot/loader/entries/a7afe39309446d92f17c60bc5467f619-5.14.9-200.fc34.x86_64.conf
titlu Fedora (5.14.9-200.fc34.x86_64) 34 (Thirty Four)
versiunea 5.14.9-200.fc34.x86_64
linux /vmlinuz-5.14.9-200.fc34.x86_64
initrd /initramfs-5.14.9-200.fc34.x86_64.img
opțiuni root=/dev/mapper/stodi_orange_2021_10-root ro rd.auto enforcing=0 crashkernel=auto video=DP-1:1280x1024-32@60e
grub_users $grub_users
grub_arg --nerestricted
nucleul grub_class

Dar dacă repornesc, așa cum am spus, va ajunge în mod fiabil să ruleze pe LV roz (adică.pe unitatea secundară). Acest lucru este adevărat chiar și atunci când am pornit anterior din portocaliu cu unitatea roz eliminată.

Nu văd ce parte din asta face posibil acest lucru.

Poate se întâmplă ceva în BIOS pe care efibootmgr nu îl poate afecta?

EDITARE: informații UUID:

rlpowell@stodi> sudo blkid
/dev/sda1: SEC_TYPE="msdos" UUID="E6B6-7A41" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="/boot/efi - EFI System Partition" PARTUUID="cb8227c2-dc52-fc4f-bd8f- b46f71104428"
/dev/sda2: UUID="544b6c29-f436-4b2f-ab73-f2cf643638b7" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="/boot Partition" PARTUUID="fe677923-076f-2cd-076f-2cd479-076f-2cd479-076f
/dev/sda3: UUID="ur5eed-EJqk-y2op-F1dY-RpUC-SQGW-MCUk48" TYPE="LVM2_member" PARTLABEL="LVM: rădăcină pe stodi_orange_2021_10" PARTUUID="b4754fd9-2021-f637-fd9-f619-2021"
/dev/mapper/stodi_orange_2021_10-root: UUID="011f7198-26d2-4c34-bc39-85fc45c55422" BLOCK_SIZE="512" TYPE="xfs"
/dev/sdb1: SEC_TYPE="msdos" UUID="6CBC-8CFB" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="/boot/efi - EFI System Partition" PARTUUID="3dc251c1-c845-1f4b-9a0b- ebc15792efd6"
/dev/sdb2: UUID="0719024b-8442-4b64-a279-842a6533b511" BLOCK_SIZE="512" TYPE="xfs" PARTLABEL="/boot Partition" PARTUUID="8b0e313c-23-bc-23-bc-23-bc-23-bc-23-bc-237-bc-23-bc-23-bc
/dev/sdb3: UUID="82fp7k-I0Th-92EP-gJ0O-MD5A-efK0-YxZ0bP" TYPE="LVM2_member" PARTLABEL="/ Partition" PARTUUID="b64d042d-443e-6445-afb8-0b673-afb8"
/dev/mapper/stodi_pink_2020_10-root: UUID="ac593057-5586-416c-b141-c8173cdb4d61" BLOCK_SIZE="512" TYPE="xfs"
drapel in
acest lucru merge mai ales pe ghiduri, EFI boot mgr identifică intrările sale pe ghiduri GPT, dacă este posibil. Poate adăugați blkid / lsblk și sfdisk -d și pentru ambele discuri. verificați dacă vreun ghid este același între unități. Poate comparați acest lucru cu celelalte mașini ale dvs. unde se comportă diferit. Pentru a restrânge acest lucru și mai mult, încercați să vă dați seama exact ce unitate este utilizată în ce etapă a procesului de pornire, în teorie, firmware-ul ar putea încărca grub de pe o unitate, grub config încărcat de pe cealaltă unitate etc.
drapel ls
S-au adăugat informații blkid; pare să se potrivească corect. Aveți sugestii despre cum să vă dați seama ce unitate este utilizată în ce etapă?
drapel in
Puteți porni mașina cu o singură unitate și funcționează cu ambele unități (una câte una)?
drapel ls
Da, va porni de pe oricare unitate dacă sunt singura unitate din cutie (de fapt, așa mă ocup de problema; porniți cu unitatea secundară ieșită, introduceți-o după pornirea timpurie).

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.