Niezgadzające się numery partycji na dysku

Zaczęty przez TJM, 25 Marzec 2009, 17:14

TJM

Chyba już gdzieś o tym kiedyś wspominałem, ale rozwiązania jak do tej pory nie udało mi się znaleźć.
Otóż mam dość dziwny problem: jest sobie dysk systemowy w linuksie, na którym jest praktycznie tylko / oraz partycja swap, pozostałe wolne miejsce jest sobie gdzieś tam podmontowane w drzewie katalogów jako dysk sieciowy na śmieci dla windy.
Problem w tym, że nie zgadzają mi się za cholerę numery partycji w różnych programach. Stwarza to spore problemy, bo np. w fstabie z jakiegoś powodu pierwsza partycja to /dev/hda8 i z takim wpisem jest poprawnie montowana; podczas gdy jeśli chcę podpiąć drugą partycję, tą z danymi, poprzez zwykły mount muszę również podać /dev/hda8, a partycja z systemem zostaje 'zredukowana' do /dev/hda5.
W drugą stronę też to działa. Przy każdym upgrejdzie kernela lub gruba z automatu (apt-get distro upgrade np.) robią się w grubie wpisy twierdzące, że system jest na /dev/hda8, więc przy restarcie pierwsze co muszę zrobić, to wejście w tryb edycji i ręczna podmianka /dev/hda8 na /dev/hda5.
Taka rozbieżność powoduje mi czasami straszny chaos, ciężko zgadnąć które narzędzie jaką numerację sobie przyjmie i boję się, że w końcu stracę przez to jakieś dane.
Macie może jakieś pomysły skąd to się mogło wziąść ? Nigdy wcześniej się z takim czymś nie spotkałem, dotyczy tylko jednego komputera (pech chciał, że akurat serwera enigmy :D) i tylko jednego dysku.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

#1
Żeby uniknąc takich kuriozalnych sytuacji ze zmieniającymi się wpisami w fstab zainteresuj się blkidlabel, UUID. Uwolni cię to od takich dziwnych sytuacji. Czy to jak byś chciał montować z ineggo systemu który np. nie używa już modułu pata.
man blkid

cat /etc/blkid.tab

przy używaniu udeva
ls -l /dev/disk/by-uuid

fstab może wyglądać tak, każda partycja ma swój unikalny numer lub label
UUID=b5a78699-a4e7-4e1e-8caf-474c132f7d43 swap swap defaults 0 0
UUID=f6a9de10-4a22-41c9-b843-be5044ea540e / xfs defaults,noatime 0 1


Skąd się wzięły takie anomalie? Nie mam pojęcia. Może pokaż co wskazuje fdisk (print).

TJM

Fdisk pokazuje coś jeszcze lepszego

/dev/hda5             320         865     4385682   83  Linux
/dev/hda6             320         865     4385682   83  Linux
/dev/hda7             866         971      843381   82  Linux swap / Solaris
/dev/hda8             971        4499    28338867+  83  Linux
/dev/hda9            4629        9729    40973751   83  Linux

hda5 i hda6 to fizycznie ta sama partycja, czyli pewnie jakiś błąd w tablicy partycji się musiał kiedyś zrobić, ale z tego co pamiętam to właśnie z instalatora debiana partycje były robione.
Dziwne też jest to, że na dysku nie ma partycji primary oznaczonej jako bootowalna, a komp normalnie z niego startuje...

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

#3
Coś się tu pomieszało przy zakładaniu partycji logicznej. Dziwna ta dziura pomiędzy 1-319 cylindrem.
Flagę bootowalności nie problem dodać tylko nie ma takiej potrzeby. Ja bym na tym dysku nie przeprowadzał
jakichkolwiek zmian typu naprawa mbr, zmiana rozmiarów partycji, kasowanie partycji.
Zbyt to niebezpieczne bez wykonania backupu.
Jak działa i nic nie zamierzasz zmieniać, to nic się złego nie stanie.
Komp startuje ponieważ wykorzystujesz bootloader.
Jakby jego nie było musiała by być flaga 'boot'.

TJM

No działać działa tak już prawie 2 lata, nawet w międzyczasie kopiowałem obraz całego dysku na inny (przez dd), potem zmieniałem rozmiar ostatniej partycji, ale jak widać problem też się skopiował  XD
W sumie aż tak za bardzo to nie przeszkadza, bo dzięki temu problemowi zwiększa mi się czujność kiedy odpalam jakiekolwiek narzędzie dyskowe, jednak wkurzające jest to, że z fstaba nie mogę zamontować partycji /dev/hda8 - muszę w init.d przy starcie systemu, ponieważ na etapie startu pod /dev/hda8 widać /dev/hda5 (czy tam 6) a pod /hda9 jest normalnie chyba ta partycja co powinna  XD

W sumie nie pamiętam też dokładnie jak to wygląda w grubie, ale chyba jako partycję bootowalną muszę podawać hda5, a lokalizację pliku img kernela w boot na hda6, (inaczej nie wystartuje) podczas gdy według fdiska jest to ta sama partycja...

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

#5
Masz niezły bałagan na tym dysku. :o
Lilo i grub korzystają z UUID. Linuksa możesz umieścić bezpośrednio na dysku np /dev/hda
Bez żadnych partycji.
Ja wolę nie korzystać z parycji rozszerzonych. To często zawodzi.
Może czas zainteresować się lvm. Robisz raid a na tym lvm. Świetna sprawa, jak się ma UPS-a.

EDIT:
W sprawie tych zmieniających się numeracji partycji:
1) Użyj UUID
2) Ewentualnie wygeneruj nowy initrd (wydaję się, że to on tu miesza)
    W dystrybucjach, których używam zrobienie initrd jest banalnie proste.
    Ty używasz Debiana? Pewnie również posiada dobre narzędzie do wykonania takiej operacji.

TJM

#6
Chyba jednak po prostu któregoś dnia wyłączę serwer na parę godzin, zrobię kopię tego dysku (na wszelki wypadek obraz całości + obrazy poszczególnych partycji + zwykła kopia danych) i po prostu spróbuję doprowadzić to do porządku, powinno dać się na luzie odtworzyć obrazy partycji na nowych partycjach o tej samej wielkości (po wcześniejszym zdjęciu journali).
Bardziej zastanawia mnie, od czego to się mogło zrobić - zawsze partycje pod linuksa robiłem tak samo, zwykłym linuksowym fdiskiem. Ten dysk nie był wyjątkiem a taki zonk mam od samego początku  ;D


Hehe a patrz jeszcze na to:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda8              4316800   2217872   1879644  55% /
tmpfs                  1038376         0   1038376   0% /lib/init/rw
udev                     10240        68     10172   1% /dev
tmpfs                  1038376         0   1038376   0% /dev/shm
/dev/sda1            307663800  98976832 193058536  34% /server/mysql
/dev/hda8             27893448   3511652  22964856  14% /server/samba

/dev/hda8 zamontowane 2 razy... pierwszy raz z fstaba, drugi raz mountem ze skryptu. Oczywiście to różne partycje, ale wyświetla je dwa razy...


W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

TJM

Odświeżę sobie ten temat, bo ostatnio natrafiłem na ten sam/podobny problem i już mi siwe włosy przez to wyskakują.
Otóż sytuacja wygląda tak, że instaluję Ubuntu 9 albo Debiana 5 na świeżutkim kompie, który docelowo będzie serwerem plików z 16-toma dyskami. Płyta ma 4 złącza ATA, dodatkowe 12 pochodzi z kontrolerów na PCI/PCI-E.
Instaluję system na podpiętym pod podstawowy kontroler dysku. Wszelkie inne dyski odpięte (zresztą na razie mam tylko 3). Wszystko ładnie pięknie, do momentu kiedy podłączam jakikolwiek dysk do któregoś z dodatkowych kontrolerów.
W BIOSie ani w tabelce przed bootowaniem systemu kolejność dysków się nie zmienia. GRUB startuje normalnie, ale system już nie, ponieważ od razu na samym starcie w jakiś magiczny sposób /dev/sda awansuje na /dev/sde a na /dev/sda wchodzi dysk podpięty do kontrolera.
Pomyślałem sobie 'no ok, przechytrzę dziada' i zainstalowałem system na dysku podpiętym do kontrolera. Niestety, podczas instalacji widziało go jako /dev/sda, podczas gdy po instalacji GRUB w ogóle nie odpala, bo nie ma /dev/sda - jest tylko /dev/sde. Kiedy magicznie cośtam popisałem w awaryjnej konsoli i GRUB zabootował do końca, dysk magicznie zjawił się znów jako /dev/sda i system ruszył.
W obu przypadkach więc możlwie jest zabootowanie systemu, ale po ręcznej interwencji w konsoli.
Tymczasem ten serwer ma być idiotoodporny, obsługiwany będzie przyciskiem on-off. Na dodatek musi być odporny na wyjęcie któregokolwiek z dysków (awarie/upgrade itp), tak więc takie cyrki z nagłymi zmianami kolejności dysków nie mogą mieć miejsca. Jest jakiś sposób, żeby wyżej przytoczoną technologię zastosować już na etapie ładowania GRUBa ?


W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

buninek

Praktyczna rada - czas zacząć korzystać z UUID.

Mam raptem w kompie 4 dyski (2xATA i 2xSATA), a bez uuid bardzo szybko bym się pogubił. W zależności od konfiguracji kerneli. Raz dana partycja jest identyfikowana jako /dev/hda2, w innym jako /dev/sdc2, itp.

Jednym słowem pierdzielnik.

blkid
Cytat/dev/sda1: UUID="9b229c1a-524a-4e07-9b55-e87c2d02133b" TYPE="xfs"
/dev/sda2: UUID="91b27ac9-662e-4ef9-931c-f6a5295acb0b" TYPE="xfs" LABEL="xfs"
/dev/sda5: UUID="b28999e4-ca5a-4e10-aee3-c2d39279cb52" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda6: UUID="2fb7cf2b-80d6-4503-ae72-5aca5bb78fcd" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdb1: UUID="082acbde-caab-41d6-be83-9ba4b2dae2e4" TYPE="reiser4"
/dev/sdb2: UUID="a761d653-7ad9-4bc5-b9eb-be69412f1438" SEC_TYPE="ext2" TYPE="ext3"
/dev/hda1: UUID="7b1c6d0b-193f-4618-909d-2a381b58d75f" SEC_TYPE="ext2" TYPE="ext3"
/dev/hda2: LABEL="DOS" UUID="44DE-727D" TYPE="vfat"
/dev/hda4: UUID="8d015416-1bb8-4391-8eb1-4942818c2aca" SEC_TYPE="ext2" TYPE="ext3"
/dev/hda5: UUID="b5a78699-a4e7-4e1e-8caf-474c132f7d43" TYPE="swap"
/dev/hda6: UUID="32c61b64-f2f2-1029-a5d5-3d53f412272d" TYPE="reiserfs"
/dev/hdd1: UUID="2359b626-b1f0-4a3d-9d5c-c2131875443f" TYPE="xfs"
/dev/hdd2: UUID="0984cd45-3c66-4af1-95cf-e136a67d8986" TYPE="xfs"
/dev/sda7: UUID="70ab1dc3-139c-4670-8fa5-068678eb44c3" TYPE="btrfs" UUID_SUB="278ecd50-8bda-4191-b1ee-ee6fb705e8e5"

Cytat: TJM w 07 Listopad 2009, 23:49
Pomyślałem sobie 'no ok, przechytrzę dziada' i zainstalowałem system na dysku podpiętym do kontrolera. Niestety, podczas instalacji widziało go jako /dev/sda, podczas gdy po instalacji GRUB w ogóle nie odpala, bo nie ma /dev/sda - jest tylko /dev/sde. Kiedy magicznie cośtam popisałem w awaryjnej konsoli i GRUB zabootował do końca, dysk magicznie zjawił się znów jako /dev/sda i system ruszył.
W obu przypadkach więc możlwie jest zabootowanie systemu, ale po ręcznej interwencji w konsoli.


Prawdopdobnie grub zbyt szybko chce podmontować root filesystem, a on nie jest jeszcze gotowy. Może kernelowi chwilkę zajmuje identyfikacja tego kontrolera?
Spóbuj dodać dodatkowy parametr przy bootowaniu rootdelay=sekundy

kernel /boot/vmlinuz-2.6.31 root=UUID=fccafcc7-d7cc-4594-9459-a8f0db7b9f7f ro rootdelay=3

Troll81

a jakie to kontrolery?? konfigurowalne czy nie? czy da się określić kolejność startowania kontrolerów na sztywno czy mają tylko tryb auto?

TJM

Rodzaj kontrolerów i jak są ustawione nie ma tu nic do rzeczy, po prostu za każdym razem kiedy zmieniam coś w konfiguracji dysków zmienia się kolejność. Czyli w praktyce nigdy system się sam nie odpala, czasami nawet w konfiguracji w jakiej był zainstalowany nie działa.
Czas opóźnienia to może być ciekawa opcja, chociaż testowałem też z CMD649 a to kontroler IDE rozpoznawalny automatycznie chyba przez większość kerneli natychmiastowo bez żadnych modułów/kombinowania.
Z tego co widzę, pewnym rozwiązaniem jest nie korzystanie z wbudowanego kontrolera IDE/SATA - wtedy pierwszy dysk pierwszego kontrolera jest zazwyczaj pod /dev/sda. Co nie zmienia faktu, że czasami inny dysk podłączony do innego kanału SATA przejmuje to miejsce. Podejrzewam, że niektóre kontrolery SATA numerują dyski w kolejności w jakiej się zgłaszają (decyduje pewnie czas rozpędzania i reakcji dysku po włączeniu zasilania), a nie w kolejności w jakiej siedzą w gniazdach. To samo mam w kompie z windą, czasami podłączam dyski które wtryniają się pod device/0 mimo że są na 6 albo 8 kanale. Na szczęście winda jest na tyle sprytna sama z siebie, że żadnych komplikacji to nie powoduje.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.

TJM

No i problem udało się rozwiązać, korzystanie z blkid/uuid rozwiązuje sprawę.
Po drodze czai się trochę pułapek:
- trzeba pamiętać, żeby zrobić jednakowe wpisy w fstab i menu.lst gruba, przy braku części wpisów system odpali w trybie awaryjnym krzycząc, że coś nie tak z partycjami;
- po zakończeniu edycji lepiej nie używać update-grub, a najlepiej zrobić kopię menu.lst, bo update systemu również potrafi wywołać update-grub i nadpisać ten plik jeśłi ściągnie nowy image kernela.
- lepiej nie zostawiać w konfiguracji gruba/fstab żadnych 'klasycznych' wpisów partycji - tzn jak przejść na blkid, to całkowicie. Przekonałem się co do tego przy testach, po prostu przy połowicznej konfiguracji działy się cuda.

W razie jakiejś pilniejszej sprawy - jestem często dostępny na kanale IRC B@P, na forum czasami zapominam zajrzeć lub nie mam czasu.