Dlaczego numer napędu / partycji jest nadal używany?

Wiele razy, zwłaszcza podczas bałaganu z programami ładującymi, widzę numeryczny numer napędu i numer partycji. Na przykład, w moim /boot/grub/grub.cfgwidzę set root='hd0,gpt2', moje wpisy rozruchu UEFI często numerów odniesienia dysk / partycję i wydaje się pojawiają się w niemal każdej sytuacji, w której programy ładujące są zainteresowane.

Teraz, gdy mamy UUID i PARTUUID, adresowanie partycji w ten sposób wydaje się niezwykle niestabilne (afaik, nie gwarantuje się, że dyski będą zawsze montowane w tej samej kolejności, użytkownik może zmienić kolejność dysków podłączanych do mobo itp.)

Moje pytania są zatem dwojakie:

1. Czy ten schemat adresowania jest tak niestabilny, jak wskazałem powyżej? Czy brakuje mi czegoś w standardzie, co oznacza, że ​​ten schemat jest o wiele bardziej niezawodny niż się spodziewam, czy też ten schemat adresowania naprawdę uniemożliwi uruchomienie systemu (dopóki przynajmniej nie naprawisz pozycji rozruchowych) w wyniku zwykłego rozpoznania dysków w inna kolejność lub podłączanie ich do różnych gniazd na płycie głównej?

2. Jeśli odpowiedź na powyższe pytanie brzmi „tak”, to dlaczego nadal stosuje się ten schemat adresowania? Czy używanie UUID lub PARTUUID do wszystkiego nie byłoby o wiele bardziej stabilne i spójne?

Prosty schemat numerowania nie jest w rzeczywistości stosowany w najnowszych systemach (przy czym „niedawnym” jest Ubuntu 9 i nowsze wersje, inne wersje również mogły się dostosować w tamtych czasach).
Masz rację, obserwując, że partycja główna jest ustawiona za pomocą zwykłego schematu numeracji. Ale jest to tylko ustawienie domyślne lub rezerwowe, które jest zwykle zastępowane przez następne polecenie, takie jak:

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

Spowoduje to wybranie partycji głównej na podstawie identyfikatora UUID systemu plików.

W praktyce schemat zwykłej numeracji jest zwykle stabilny (o ile nie ma zmian sprzętowych). Jedyną obserwowaną przeze mnie nieprzewidywalną numeracją był system z wieloma dyskami USB, które zostały wyliczone na podstawie wzorca „kto pierwszy, ten lepszy”, a następnie emulowane jako dyski IDE. Żaden z tych procesów nie jest z natury chaotyczny, więc zakładam problem z implementacją systemu BIOS w poszczególnych systemach.

Uwaga: „partycja główna” w tym kontekście oznacza partycję, z której należy uruchomić system, może różnić się od partycji zawierającej „system plików root. / System plików”.

Ściśle mówiąc, UUID w ogóle się nie adresuje .

Adresowanie jest bardzo, bardzo proste: odczytaj dysk X sektor Y - albo inaczej. Odczytaj adres pamięci Z - lub inaczej. Adresowanie jest proste, szybkie, nie pozostawia wiele miejsca na interpretację i jest wszędzie.

UUID nie adresuje. Zamiast tego szuka, znajduje, czasem czeka na pojawienie się urządzeń, a także rozumie systemy plików (★). W zależności od liczby urządzeń może to zająć bardzo dużo czasu. I kiedy już go znajdziesz, wróć do zwykłego adresowania.

W GRUB-ie jest to nazywane search(★★) i jest dostępne tylko wtedy, gdy GRUB ma już rozwinięte skrzydła (wyszukiwanie jest modułem, podobnie jak każdy obsługiwany przez niego system plików, a więc dostępny tylko po załadowaniu rdzenia). W Linuksie, to (na przykład) o nazwie findfs, findfs wyszuka urządzeń blokowych w systemie szuka plików lub partycji .

Przechodzi przez wszystkie urządzenia blokowe, budzi je z trybu gotowości, odczytuje dane, a wynik może nawet być losowy, jeśli UUID nie jest unikalny tak, jak powinien (po ddwypadku itp.), Lub nie otrzymasz żadnego wyniku, jeśli UUID zmienił się - Identyfikatory UUID są również podatne na błędy konfiguracji.

Ogólnie, UUID są świetne i oczywiście powinieneś ich używać wszędzie, jeśli są dostępne, szczególnie gdy tradycyjne adresowanie nie powiedzie się, ponieważ kolejność dysków jest losowa w Linuksie; ale zrozum, że złożoność wykracza poza to, co powinno zrobić proste adresowanie. A szczególnie na bardzo wczesnych etapach programów ładujących, po prostu może nie być jeszcze opcją. Adresowanie jest na pierwszym miejscu, później rosnące skrzydła.

W przypadku programu ładującego może nie być konieczne podjęcie wysiłku (nie każdy program ładujący obsługuje szeroki zakres systemów plików, takich jak GRUB). Gdybyhd0 ze względu na okoliczność jest gwarantowany „dysk, z którego dokonaliśmy rozruchu” (BIOS zapewnia), a więc jeśli możesz wykluczyć problemy z losową kolejnością dysków, może nie być potrzeby przeglądania potencjalnie ogromnej listy innych partycji w wyszukaj UUID.

Jeśli jesteś wystarczająco pewny swojej konfiguracji, aby powiedzieć, że tego hd0,gpt2właśnie chcesz, i tak musi być, i nie może być inaczej, to nie ma nic złego w używaniu go w ten sposób. Czasami proste i proste adresowanie działa dobrze.

(★) Wcześniej wyjaśniłem to dla ETYKIET tutaj ...

Nie ma ogólnego standardu dla etykiet, wszystko jest ręcznie robione, patrz na przykład ta implementacja formatów superbloków w util-linux . Jeśli jutro wymyślisz nowy system plików, nawet jeśli ma etykietę, nie pojawi się, dopóki nie zostanie dodana obsługa.

... i podobnie jest z UUID.

(★★) W rzeczywistości GRUB searchma --hintopcję i ... teraz nie sprawdziłem kodu źródłowego i nie jest nawet udokumentowany w ich instrukcji, ale taka opcja miałaby sens, aby dać ci to, co najlepsze z obu światów: wskazówka powinna powiedzieć searchaby sprawdzić, czy partycja pierwszy , a jeśli UUID mecze zgodnie z oczekiwaniami, to zidentyfikować urządzenie z minimalnym wysiłku , a jeśli to nie pasuje, to będzie nadal spadać z powrotem do pełnego wyszukiwania dmuchanego zachować rzeczy jakoś robocze .

Ponadto wcześniej znalezione identyfikatory UUID mają tendencję do buforowania, więc nie muszą przechodzić przez wszystkie urządzenia od nowa i od nowa - i to też działa świetnie, pod warunkiem, że szukany UUID faktycznie istnieje gdzieś w pierwszej kolejności dostań się do pamięci podręcznej.

Nie zapomnij także o etykietach. Nie są one tak unikalne jak UUID, ale o wiele bardziej pouczające i sprawiają, że fstab jest czytelny dla ludzi. Jeśli jest to komputer stacjonarny lub mała firma - innymi słowy, zarządzasz kilkoma lub kilkadziesiąt dyskami, możesz preferować etykiety niż identyfikatory UUID.

Zastanawiając się nad doskonałą odpowiedzią @ frostschutz na twoje pytanie, jednym ze scenariuszy, w którym prawdopodobnie wolisz klasyczne adresowanie linków do urządzeń, jest konfiguracja VM, szczególnie w chmurach VM do wynajęcia (w skrócie, myląco „IaaS”). Załóżmy, że chcesz dostosować obraz Ubunzima 04.18 . Tworzysz (wysuwaną) maszynę wirtualną z 2 dyskami: jeden będzie dyskiem systemowym (wysuwanym), a drugi tym, który zamontujesz i dostosujesz. Prawdopodobnie montujesz także partycję rozruchową UEFI, jeśli chcesz wykarczować nowszego gruba na nowym dysku. Zakładając, że wybrałeś punkty montowania dla docelowych partycji poniżej /mnt, wygląda jak pożądana tabela montowania

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

Tworzysz 2 identyczne dyski z istniejącego, dostarczonego przez dostawcę, gotowego do chmury obrazu, podłącz je do nowej maszyny wirtualnej i uruchom ją. Naturalnie,

• Wszystkie współczesne dystrybucje systemów operacyjnych, nasze wyobrażone Ubunzima 04.18 nie będące wyjątkiem, polegają na montowaniu o nazwie UUID.
• Wszystkie dyski twarde wdrożone z tego samego obrazu mają ten sam UUID. UUID są unikalne, więc co może pójść nie tak?

Już wiesz, dokąd to wszystko zmierza.

Po pierwszym uruchomieniu tego frankencontraption wybrał sda9on partycję rozruchową EFI, ale Linux postanowił ponownie zainstalować sdb1jako root FS:

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

A ponieważ mój skrypt do wdrażania był na to dość nieprzygotowany, w końcu mam obraz niemożliwego do uruchomienia, bez jednego narzędzia narzekającego w dzienniku podczas budowy frankenbuild!

Oczywiście wydrukowałem tabelę montażu w dziennikach. I oczywiście bałagan jest bardzo trudny do wykrycia, ponieważ mount (8) drukuje montowania w połowie drogi między losowym a tym, w którym zamontowano urządzenia, więc nie było zaskoczeniem, że nie zauważyłem go od razu. Wyobraź sobie, że ten sam skrypt (ale z dyskami z różnych obrazów) działał wcześniej tak gładko jak 15-letni Glenfiddich. Zgadnij, ile godzin spędziłem, ciągnąc włosy¹ za kłodę, próbując rozwiązać problem?

Nie ma sztywnych i szybkich reguł, które byłyby odpowiednie w każdej sytuacji, od komputera stacjonarnego do systemu Linux osadzonego w routerze, telefonu z Androidem i centrum danych w chmurze. Odpowiedź SO powinna być obiektywna, a moje doświadczenia lub preferencje oczywiście nie są. Wolę więc pokazywać przykłady logicznego rozumowania przy wyborze spośród różnych metod identyfikowania partycji:

• Zostaw to w spokoju, jeśli nie masz powodu, aby tego nie robić. Identyfikatory UUID są domyślne dla większości nowoczesnych dystrybucji. Jeśli chodzi o dodanie drugiego dysku, spróbuj i zdecyduj. Są szanse, że nigdy nie będziesz musiał wiedzieć. Jeśli twój system nadal się uruchamia i możesz zobaczyć i podzielić nowe urządzenie na partycje, sformatuj je i dodaj do fstab (według UUID, LABEL lub /devlinku, obowiązują te same uwagi). Tylko wtedy, gdy system odmawia rozruchu po podłączeniu dodatkowego napędu, masz problem (a może zmiana kolejności rozruchu w systemie UEFI BIOS jest najszybszym wyjściem).

  Pragmatycznie, oznaczenie, które złącze SATA idzie do którego dysku na twoim pulpicie może być najszybszym i najłatwiejszym rozwiązaniem, a zmiana sposobu uruchamiania systemu i odzyskiwania po dość prawdopodobnej awarii rozruchu jest, być może, najgorszym czasobijaczem. Ale jeśli poradzisz sobie z tym 50 programistom, którzy uważają, że wrzucenie dodatkowego dysku nie jest problemem godnym przeszkadzania, przynajmniej nie sprawdzaj granic szczęścia i upewnij się, że ich początkowe dyski rozruchowe są widziane przez gruba jako hd0i system jako sda.

• Etykiety do zarządzania własnymi dyskami i partycjami na pulpicie lub trzech komputerach lub w małym środowisku (salon domu wypełnionego inżynierami oprogramowania, którzy nazywają to miejsce „biurem startowym”). Jeśli wyciągniesz dysk fizyczny z czyjejś maszyny, wiesz, skąd się on wziął, jeśli konsekwentnie używasz etykiet.

  Jeśli lsblk (8) mówi LABEL=bubba-boot, wiesz, że został pobrany z maszyny o nazwie bubba ; poza tym bubba-boot przewraca się na moim języku o wiele łatwiej niż 6864c4ea-f9b9-46db-b875-4d7fc2981007 , co, według mojego zepsutego smaku, jest wręcz łamaczem szczęk. Zapewnienie, że etykiety są unikalne, przenosi się teraz na ciebie, ale to, co dostajesz w zamian, to znaczenie etykiety.

• /dev-liniowe nazewnictwo przy dowodzeniu batalionem maszyn wirtualnych o stosunkowo krótkim czasie życia, które nie wymagają konserwacji, które są spawnowaniem tego samego obrazu, i nie stawiałbyś stawki tygodniowej, aby wszystkie ich UUID dotrzymały obietnicy UU. Każda rozsądna usługa VM, czy to Vyper-H na własnym fizycznym serwerze, czy Kugel Cloud, czy coś takiego, nigdy nie wywoła twojego dysku rozruchowego sde, a drugi i jedyny sdc². Z drugiej strony w maszynie fizycznej można łatwo uzyskać ten sam układ, kreatywnie łącząc kable SATA.

  Robię teraz dygresję, ale w tym scenariuszu wybieram tę samą trasę z tak zwanym „spójnym” nazewnictwem interfejsu Ethernet: wyłącz go na maszynach wirtualnych. Nie zrozumcie mnie źle, nazewnictwo jest naprawdę spójne, o ile karta sieciowa umieszczona w gnieździe PCI 4 nie skoczy nagle do gniazda 5 z własnej woli, gdy nie patrzysz (a może nawet gdy jesteś; karty sieciowe nie wstydzę się). Niestety w środowisku „batalionu maszyn wirtualnych” oni tak robią. W tym przypadku, wbrew intuicji, eth0jest bardziej spójny niżenp0s4f6. Dostawca maszyny wirtualnej nie obiecał, że zawsze umieści wirtualną kartę sieciową nr 1 w gnieździe 4 na szynie PCI 0 (i żaden z 3 wymienionych podmiotów nie jest fizycznie rzeczywisty), i że zawsze będzie to funkcja 6. Ale możesz ładnie wiele polega na pierwszym interfejsie przed drugim, biorąc pod uwagę, że zwykle mają ten sam moduł sterownika, zwykle z rodziny virtio (i jeśli pierwsza karta sieciowa nie zawsze jest eth0taka sama, nadal obowiązuje ta sama uwaga²).

  ---

¹ Oczywiście w przenośni. Byłem, jeśli ten biznes był zbyt długo, aby mógł zostać.
² Jeśli tak, poważnie zastanowiłbym się, czy nie uciec od krzyków zmieniających dostawcę lub oprogramowanie hypervisor VM.

Oba schematy mogą być mieszane i dopasowywane do większości dystrybucji Linuksa.

Konsekwencje mogą być pożądane lub niepożądane w zależności od przypadku użycia - na przykład można preferować starszy schemat (a nawet wyłączyć hacki utrwalające w stylu udev), jeśli wymiana dysków (sprzęt wirtualny lub rzeczywisty) bez konieczności modyfikowania plików konfiguracyjnych jest możliwa chciał.

Odpowiedź na twoje drugie pytanie („dlaczego ten schemat adresowania jest nadal używany?”) Jest, jak sądzę, bezwładnością. Tak, używanie dysków UUID na dyskach partycjonowanych GPT jest całkowicie możliwe. Możesz używać UUID zamiast /dev/xxxnazw w /etc/fstab. A teraz, gdy mamy Specyfikację wykrywalnych partycji , w wielu przypadkach nie musisz nawet określać UUID-ów, po prostu podziel dysk na partycję z typem partycji, a partycje zostaną automatycznie pobrane. Na moim komputerze root=brakuje całkowicie wpisu w wierszu poleceń jądra.

Mówiąc o programach ładujących: GRUB jest w większości przypadków zbędny na nowoczesnych komputerach UEFI, w tym sensie, że ma bardzo niewiele wspólnego z ładowaniem komputera. Obecnie GRUB działa jedynie jako program do wyboru jądra, dla którego zadania dostępne są prostsze i lepsze alternatywy, takie jak systemd-boot.