Linux - Problem z GRUB

[grandx86]

Witam ponownie. Mam dwa problemy z konfiguracją GRUB w systemie BackTrack 5 R1, który jest zainstalowany na dysku twardym.

 

1. Chciałbym uruchamiać system za pomocą pendrive, tzn. aby stage1 był na pendrive, a stage2 na dysku twardym. Czyli bez podłączonego pendrive podczas bootowania systemu "wywalał błąd", a gdy pendrive jest podłączony wyświetłał menu GRUB-a, z systemami do wyboru.

Próbowałem różnych sposobów, niestety bez powodzenia.

 

2. Jak dodać obraz konsoli odzyskiwania Visty (Windows Recovery Environment) do menu GRUB-a. W konsolą WindowsXP poradziłem sobie bez problemu, natomiast konsola jest w formacie ISO i tu pojawia się problem.

 

Oto szczegóły konfiguracji:

 

Konfiguracja dysków i partycji

Plik grub.cfg

 

Pozdrawiam.

[maggreg]

Jaki konkretnie loader znajduje się na penie, w konfigu widzę chainload do grub4dos a sam konfig pochodzi z grub2, o tyle ważne, że loadery te mają inną składnię.

Czy dysk ma coś domyślnie uruchamiać, innymi słowy czy partycja z loderem ma być aktywna, teoretycznie jeżeli loader miałby znaleźć się na zewnętrznym nośniku to loader na dysku staje się zbędny.

Iso w grubach dodajemy poprzez mapowanie, najlepiej ze względu na ciągłość mapować poprzez pamięć czyli map --mem, w grub2 nie mamy funkcji map ale można poeksperymentować z loopback, jednak praktycznie w przypadku konsoli (a tak naprawdę winpe) najlepiej podłączyć je bezpośrednio a nie z iso.

Grub (a grub4dos na pewno) powinien poradzić sobie z chainloadem winpe z pliku wim, pytanie tylko czy winpe ma się znaleźć na dysku czy na penie, widzę odnośnik do win2008 więc winpe można podpiąć pod jego menu można też oczywiście odseparować.

W przypadku windowsów grub2 ma zresztą wbudowaną procedurę (troszkę inną niż to co masz w konfigu), mamy coś takiego:

menuentry "Windows 7 BIOS/MBR" {
 insmod part_msdos
 insmod ntldr
 insmod ntfs
 ntldr (hd0,msdos1)/bootmgr
}

menuentry "Windows XP BIOS/MBR" {
 insmod part_msdos
 insmod ntldr
 insmod ntfs
 ntldr (hd0,msdos1)/ntldr
}

 

Również w przypadku efi i gpt dokumentacja wskazuje bezpośrednio na loader choć z użyciem chain-a:

menuentry "Windows 7 UEFI/GPT" {
insmod part_gpt
insmod search_fs_uuid
insmod chain
search --fs-uuid --no-floppy --set=root 28cf-35de
chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi
}

 

pzdr

antyface! - Usunięto elementów: 0

[grandx86]

Dzięki za odpowiedź. Pendrive jest "czysty", tzn. format FAT32 i zawiera konterer TrueCrypt (jako plik). Wpisy:

 

menuentry "Windows 7 BIOS/MBR" {

insmod part_msdos

insmod ntldr

insmod ntfs

ntldr (hd0,msdos1)/bootmgr

}

 

menuentry "Windows XP BIOS/MBR" {

insmod part_msdos

insmod ntldr

insmod ntfs

ntldr (hd0,msdos1)/ntldr

}

 

wywalają błąd o "nie odnalezieniu pliku" i " błędnym poleceniu bootmbr/ntldr", w związku z tym zostanę przy moim działającym grub4dos Jeśli chodzi o wpis:

 

menuentry "Windows 7 UEFI/GPT" {

insmod part_gpt

insmod search_fs_uuid

insmod chain

search --fs-uuid --no-floppy --set=root 24DC8DA3DC8D6FBA

chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi

}

 

to wywala błąd o "nie odnalezieniu pliku". Z tą konsolą Visty (Win2008) to chyba sobie odpuszczę bo nie jest ona zawarta na dysku jak w przypadku XP (cmdcons) i nie można jej uruchomić poprzez F8, tylko trzeba uruchamiać z płyty/obrazu ISO, a z tego co wiem GRUB2 ma problemy z bootowaniem obrazów ISO, nie będącego linuxem. Jeśli chodzi o tego pendrive, a gdyby tak przenieść MBR i GRUB-a z dysku twardego na pendrive? Wtedy bootował bym bezpośrednio z USB-HDD. Obawiam się, że potrzebne będzie sformatowanie pendrive do ext2/3, ale można chyba go podzienić na 2 partycję, np ok. ~10MB na MBR i GRUB a reszte na inne pliki (FAT32), żeby był użyteczny w systemie Windows.

 

Pozdro.

[maggreg]

A czy Grub2 radzi sobie z truecrypt-em, z tego co mi pamięć podpowida to nie radzi sobie w ogóle.

Wpisy nie odnajdują pliku bo powinny dostać info o konkretnej partycji, w twoim konfigu masz:

find --set-root /ntldr

czyli szukaj ntldr, jak znajdziesz to ustaw fokus i uruchom, zawsze przy statycznej konfiguracji lepiej (bez znaczenia czy w grub czy grub2) ustawić fokus na konkretną partycję.

np. coś takiego:

root (hd0,0)
chainloader (hd0,0)/ntldr

czy odpowiedni w lini:

--config-file="root (hd0,0);chainloader (hd0,0)/ntldr"

tak samo należy skonfigurować ustawienia w grub2, albo podając partycję bezpośrednio albo numer partycji zgodnej z msdos np. msdos2 itp.

 

To ostatnie dotyczy konfiguracji uruchamianej z EFI, co prawda twój układ partycji sugeruje, że nie zachodzi taka sytuacja ale mimo to --fs-uuid nie jest jednoznaczne.

Zresztą ustawienie fokusa przez "search --no-floppy --fs-uuid --set xxxx" dla xp też powinno zadziałać.

 

I na koniec - może nie wyraziłem się jednoznacznie ale chciałem już wcześniej zaznaczyć, że odpalanie konsoli (to właściwie nie jest konsola) odzyskiwania dla visty/siódemki z pliku iso jest rozwiązaniem skrajnie niepotrzebnym, niewygodnym i na dodatek niejednoznacznym, bo teraz się zastanawiam, czy ty próbujesz odpalić iso całego DVD czy z samym recovery?

Pomijając fakt, że jest to rozwiązanie znacznie bardziej przydatne niż konsola XP (w ogóle odpalanie winpe >= 2.0 bo wiele przydatnych narzędzi jest dystrybuowanych w ten sposó to jest też dużo prostsze.

Recovery pod postacią pliku winRE.wim znajduje się w katalogu /windows/system32/Recovery i wystarczy go podpiąć pod menu gotowe lub (jeżeli już używamy loaderów) zbudować mu oddzielne BCD, niektóre typy instalacji powodują, że winre zostaje usunięte z dysku ale zawsze można je znaleźć we wszystkich obrazach obecnych w install.wim systemów 7 i 2008 pod podaną wcześniej ścieżką.

Jeżeli natomiast winre znajduje się na swoim miejscu i na dodatek chcemy je dodać do domyślnego kontenera BCD to możemy się posłużyć obecną w systemie komendą reagentc.exe

np. taka komenda:

reagentc /setreimage /path C:\Recovery\WindowsRE\ /target C:\Windows /bootkey 4100

przemieści nam winre do ścieżki C:\Recovery\WindowsRE\, ustawi jako domyślnie poddawany naprawie system ten dostępny w ścieżce C:\Windows i na dokładkę spowoduje, że będziemy mogli recovry odpalić przytrzymując przy starcie systemu klawisz F7 zamiast F8 i ręczne wybranie odpowiedniej opcji.

Oczywiście z wielu względów lepiej jeżeli recovery (jak i sama konfiguracja botująca) znajdują się na innej partycji niż sam system, przede wszystkim awaria powodująca brak dostępu do partycji z systemem nie odcina nas od systemu recovery i czy ogólnie winpe w którym możemy odpalać troszkę więcej narzędzi diagnostyczno/naprawczych niż te zawarty w samym RE.

 

Jeżeli nie używasz konfiguracji z EFI to nie powinno być problemu z grub4dos (i fs pena nie powinien mieć w tym przypadku żadnego znaczenia), mogą być potrzebne tylko odpowiednie mapowania, pamiętaj że botując z pena to on de facto staje się na ten czas dyskiem hd0 i systemów należy szukać na hd1 albo dokonać swapu (może to być dla niektórych systemów niezbędne).

swap w grub4dos jest dość prosty:

map (hd0) (hd1)
map (hd1) (hd0)
map --hook

albo ze sprawdzeniem, ćzy mamy do czynienia z twardym dyskiem i dopiero wtedy map:

checkrange 0x80 read 0x8280 && map (hd0) (hd1)
checkrange 0x80 read 0x8280 && map (hd1) (hd0)
map --hook

 

I jeszcze mały przykład, jeżeli chcemy odpalić kilka BCD z tej samej partycji ale jednocześnie nie mamy zamiaru edytować pliku bootmgr mały przykład pomysłowego użycia grub4dos do tego celu:

find --set-root /bootmgr
map --mem /bootmgr (rd)
cat --hex --locate=\x74\x3\xE9\x8\x0\x39\x56 --replace=\xEB\x8\xE9\x8\x0\x39\x56 (rd)+1
cat --hex --skip=0x54733 --locate=C\x00D --length=3 (rd)+1 && set offset=0x54733
write --offset=%offset% (rd)+1 C\x001
chainloader (rd)+1
root ()

w locie edytuje bootmgr i wskazuje mu jako kontener z konfiguracją botowania bc1 (bcd <> bc1), w samym BC1 musimy tylko ustawić ignorowanie sumy kontrolnej (bcdedit /set loadoptions DISABLE_INTEGRITY_CHECKS).

 

pzdr

 

ps

grub oczywiście nie może się znajdować na partycji trucrypt może natomiast (dzięki dodatkowym pośrednikom) odpalić system z takiej partycji.

[grandx86]

Udało mi się jakimś cudem przenieść GRUB-a na pendrive, jest jedno "ale". Oto polecenia, których użyłem:

mount -t vfat /dev/sdb1 /mnt/usbhd/
grub-install --no-floppy --root-directory=/mnt/usbhd/ hd1

później w powłoce GRUB-a:

root (hd0,0)
setup (hd1,0)

po tych poleceniach pendrive stał się bootowalny, lecz uruchamiał się w powłoce GRUB-a, więc stworzyłem menu.lst (update-grub). Trochę się zdziwiłem, bo przecież menu.lst był w GRUB a nie w GRUB2, lecz co się później okazało... Pendrive bootował i wyświetał listę systemów: Ubuntu, Ubuntu-recovery, Chainload to GRUB2 , Memtest. Wniosek tego jest taki, że na pendrive mam GRUB, który chainloaduje GRUB2 na dysku twardym, gdzie wreszcie mam moje menu z wyborami systemu. Aktualnie mam ustawione "default 2" + "timeout 0" czyli od razu po starcie systemu widzę bootsplash GRUB2, lecz czy nie da się "wymusić" GRUB2 zamiast GRUB, ponieważ według mnie zbędne jest przekierowanie do GRUB2. I w związku z tym jak bezpiecznie usunąć MBR na dysku twardym tak, aby wyświetał popularne:

No bootable device -- insert boot disc and press any key

 

Pendrive nie jest szyfrowany, tylko zawiera 1 plik zaszyfrowany plik przez TC.

Jeśli chodzi o ten WinRE, to jeśli zainstaluje go na tym samym pendrive (lub ewentualnie jakieść nowej partycji) to czy będę mógł zbootować poprzez "coś takiego":

menuentry "Konsola server 2008" --class
windows --class os {
insmod part_msdos
insmod fat32
set root='(hd1,msdos1)'
search --no-floppy --fs-uuid --set=root xxxxxxxxxxxxxxxxxxxx
drivemap -s (hd1) ${root}
chainloader +1
}

 

Pozdro.

[maggreg]

Hm, aż tak linuxowego gruba nie znam żeby rozstrzygnąć autorytatywnie więc tylko zgaduję, że być może instalator gruba rozpoznał pena i utworzył na nim coś na kształt dysku recovery.

Inna sprawa, że Grub może po prostu ignorować napęd FAT i szukać w pierwszej kolejności czegoś bardziej linuxowego, to menu które widzisz może być wbudowane bezpośrednio w loader.

Generalnie lepiej do zabaw narzędziowych nadają się loadery do tego celu stworzone jak grub4dos czy syslinux i proponowałbym skorzystanie właśnie z nich.

Pamiętaj też o tym co wspominałem wcześniej, pen z którego botujemy z automatu staje się dyskiem nr. 0 przesuwając dysk wewnętrzny w hierarchii i tutaj zachowanie w zależności od loadera też może być różne.

 

WinRE oczywiście może się znaleźć na penie i proponowana konstrukcja powinna być prawidłowa, dla G4D mamy zresztą prościej:

title BOOTMGR 
root (hd0,0)
chainloader (hd0,0)/bootmgr

tak jak i dla syslinux:

label BCD (DART & WinPE2.1)
 kernel /Syslinux/chain.c32
 APPEND fs ntldr=/BOOTMGR

 

Oczywiście trzeba jeszcze zbudować konfig BCD w katalogu "boot", potrzebny też będzie init dla ram dysku najlepiej w tym samym katalogu (czyli plik "BOOT.SDI").

konfig buduje się z poziomu windowsa skryptem w stylu:

bcdedit -createstore BCD
 set BCDEDIT=bcdedit -store BCD
 %BCDEDIT% -create {ramdiskoptions} -d "Ramdisk options"
 %BCDEDIT% -set {ramdiskoptions} ramdisksdidevice boot
 %BCDEDIT% -set {ramdiskoptions} ramdisksdipath \Boot\boot.sdi
 %BCDEDIT%  -deletevalue {ramdiskoptions} description
 for /f "tokens=3" %a in ('%BCDEDIT% -create -d "Windows PE" -application osloader') do set GUID=%a
 %BCDEDIT% -set %GUID% systemroot \Windows
 %BCDEDIT% -set %GUID% detecthal Yes
 %BCDEDIT% -set %GUID% winpe Yes
 %BCDEDIT% -set %GUID% osdevice ramdisk=[boot]\Boot\winpe.wim,{ramdiskoptions}
 %BCDEDIT% -set %GUID% device ramdisk=[boot]\Boot\winpe.wim,{ramdiskoptions}
 %BCDEDIT% -create {bootmgr} -d "Windows Boot Manager"
 %BCDEDIT% -set {bootmgr} timeout 0
 %BCDEDIT% -set {bootmgr} displayorder %GUID%

Przy czym "tokens=3" może wymagać zmiany w zależności od języka systemu w którym wykonujemy skrypt, dla spolszczonego bcdedit powinno być "tokens=2".

W "[boot]\Boot\winpe.wim" oczywiście podajemy faktyczną ścieżkę do pliku wim i odpowiednią nazwę czyli przykładowo "[boot]\recovery\winre.wim"

 

Wyzerowanie rozruchu z poziomu linuxa jest banalne, wystarczy zwykły dd:

dd if=/dev/zero of=/dev/hdX bs=512 count=1

Można też analogicznie zrzucić sobie taki mbr celem późniejszego użycia w chainloadingu:

dd if=/dev/hdX of=/tmp/boot.bs bs=512 count=1

większość loaderów potrafi załadować coś takiego bezpośrednio, nawet te windowsowe, można wtedy linuxa odpalać z BCD.

 

pzdr

[grandx86]

Po długich "męczarniach" zrezygnowałem jednak z WinPE, jeśli chodzi o MBR to wszystko działa jak należy. Dzięki wielkie za pomoc, temat uważam za zamknięty