Długie Uruchamianie Z Gruba

[TrolleY]

Witam.

Postanowiłem zainstalować jednak fedore 18 jako linuxa (mam dwa systemy - fedora i windows 8).
Wszystko śmigało ładnie pięknie, ale chciałem jako domyślny system w grubie mieć windowsa. Zainstalowałem do tego celu grub-customizera i ustawiłem uruchamianie się domyślnie wpisu 3 (windows 8 loader). Windows uruchamia się z tego bez problemu, natomiast o dziwo problem ma fedora. Po wybraniu jej z menu uruchamia się, ale z opóźnieniem (dopiero po około 2 minutach). 

Dodatkowo po uruchomieniu zgłasza mi się alarm (nie wiem czy to ma jakiś związek):
źródło: kernel
problem: WARNING: at kernel/watchdog.c:242 watchdog_overflow_callback+0x9a/0xc0()

any help?

[Gość _PaT]

Wklejony wycinek sugeruje poważny problem. Przeczytaj sam na bugzilli. 

 

U mnie system długo się bootował, bo systemd czekał aż komunikaty pojawią się na konsoli (objawiało się powolnym przewijaniem tekstu). Po włączeniu rhgb znacznie się poprawiło.

[TrolleY]

Po wpisaniu magicznej komendy 'yum --nogpg update' i zainstalowaniu/zaktualizowaniu przeszło 500 pakietów (w tym nowego kernela) działa i nie wyskakuje już wyżej opisany błąd. Problem w tym, że teraz znowu domyślnie wybraną opcją jest opcja nr 1 czyli fedora. Jak teraz bezpiecznie zedytować gruba, żeby znowu się wszystko nie posypało (teraz windows 8 to opcja nr 4)?

[andrew]

Przeczytaj:

http://forum.fedora.pl/topic/25661-grub2-domyslne-bootowanie-systemu/#entry159780

 

[Gość _PaT]

'yum --nogpg update'

Pewnie chodzi o --nogpgcheck. 

 

Jako ciekawostkę tylko Ci napiszę, że u mnie system po takiej operacji musi zostać zreinstalowany. Krytyczny incydent z punktu widzenia bezpieczeństwa

[@WalDo]

Pewnie chodzi o --nogpgcheck.

Od którejś wersji zaczął działać "skrót". teraz wystarczy nogpg, chociaż oczywiście nogpgcheck też działa.

[TrolleY]

Ludzie... jestem już wykończony... to jest wojna... czy tak wygląda prawdziwa obsługa linuxów innych niż ubuntu?

Od tamtej pory znowu zdąrzył mi się zepsuć bootloader, po czym udało mi się go naprawić tym razem bez reinstalacji również linuxa. A najlepsze jest to, że naprawa go odbyła się poprzez uruchomienie płyty bootowalnej takiego środowiska naprawczego "hiners" i wybraniu tak testowo opcji... (uwaga uwaga) "Boot from hard drive". Nie musiałem nic innego kombinować z bootloaderem. To uruchomiło gruba który od tej pory sam się znowu uruchamia bez problemu. No może bez problemu to przesada - znowu fedora uruchamia się po ok. 2 minutach wcześniej wypisując komunikaty:

1. coś w stylu: API package has zero elements (krzaczki) //to zawsze mi się pokazywało i działało z tym
2. [iNFO] run_sched detected stalls on CPUs/tasks //to jest oznaką błędu, normalnie tego nie ma a samo to pojawia się dopiero po ok. minucie.

Boję się cokolwiek na razie ruszać, może z samego czekania się nie zepsuje... Myślicie, że po prostu reinstalacja grub'a przez yum naprawi wszystko?

 

Jeśli chodzi o tą opcję z yum'a - wydaje mi się, że faktycznie podałem --nogpgcheck. Jendakże jak się instaluje z --nogpgcheck to próbuje ściągać podaną paczkę przez internet. Jeżeli natomiast poda się yum --nogpg install moja_paczka.rpm to instaluje to tą paczkę + sprawdza zależności + też nie zwraca uwagi na ten key (nie wiem w zasadzie co to jest ale co drugą rzecz którą chciałem zainstalować na f18 się o to przywalało a na f16 nie sprawiało takich problemów). W ogóle odnoszę trochę wrażenie, że f18 jest momentami gorsza od windowsa jeśli chodzi o wyskakujące okienka - ciągle prosi o uwierzytelnienie czegoś (może tylko takie wrażenie, bo dziś miałem ciężki dzień jeśli chodzi o instalacje wszelkie).

[Gość _PaT]

TrolleY, dnia 11 Lut 2013 - 22:20, napisał:

1. coś w stylu: API package has zero elements (krzaczki) //to zawsze mi się pokazywało i działało z tym

Pewnie chodzi o ACPI, nie API. Obstawiam kłopot z tablicami DSDT, ale żeby to potwierdzić napisz nam, jaki masz sprzęt. W ogólności update BIOS-u silnie zalecany.

 

Dopisz noacpi do parametrów bootowania kernela. Powinno pomóc, przynajmniej z tym komunikatem. Jak sobie nie poradzisz to daj znać, ktoś Cię wesprze.

TrolleY, dnia 11 Lut 2013 - 22:20, napisał:

2. [iNFO] run_sched detected stalls on CPUs/tasks //to jest oznaką błędu, normalnie tego nie ma a samo to pojawia się dopiero po ok. minucie.

To jest już patologicznie źle i jest powodem długiego uruchamiania. Update BIOS-u, reset ustawień BIOS-u (bo mogłeś coś np. w przerwaniach namieszać), update kernela, reboot.

[TrolleY]

Faktycznie być może było tam ACPI. Spróbuję się tym zająć jutro, chociaż takie coś jak update BIOSu w samej nazwie mnie przeraża... Chyba, że w końcu powinienem jednak dopisać to "noacpi" do parametrów bootowania kernela (gdzie się to robi?).

Sprzęt: Asus N52Da, systemy: Windows 8 Pro 64bit + Fedora 18 64bit (oficjalne domyślne iso).

 

Zapomniałem dodać w jaki sposób zepsułem tego grub'a (podejrzewam, że mogłem zawsze w podobny sposób go psuć nie zdając sobie z tego sprawy). Otóż próbowałem uruchomić przez wine pewną grę, która nie zadziałała, a spowodowała że jedyną rzeczą widoczną była kursor myszy. Nic nie pomagało, jedynie wyłączenie na chama komputera (nie śmiejcie się ).

[Gość _PaT]

Chyba, że w końcu powinienem jednak dopisać to "noacpi" do parametrów bootowania kernela (gdzie się to robi?).

Od tego zacznij, bo są spore szanse powodzenia.

 

U mnie edytuje się plik /etc/grub2.cfg. W linii wyglądającej mniej więcej tak:

linux   /vmlinuz-3.7.5-201.fc18.x86_64 root=/dev/mapper/vg_ssd-root ro rd.lvm.lv=vg_ssd/root rd.md=0 rd.dm=0  rd.lvm.lv=vg_ssd/swap vconsole.keymap=pl2 rd.luks=0 rhgb quiet

Na końcu dopisz noacpi:

linux /vmlinuz-3.7.5-201.fc18.x86_64 root=/dev/mapper/vg_ssd-root ro rd.lvm.lv=vg_ssd/root rd.md=0 rd.dm=0 rd.lvm.lv=vg_ssd/swap vconsole.keymap=pl2 rd.luks=0 rhgb quiet noacpi

Po czym reboot. Jeśli dobrze dopisałeś, to zauważysz to po reboocie wykonując:

cat /proc/cmdline

[TrolleY]

Dzięki, spróbuję jutro i oczywiście podzielę się efektem

[TrolleY]

_PaT jesteś mistrzem!

Dziś próbując uruchomić fedorę (wczoraj jak pisałem ostatnie posty siedziałem trochę zniechęcony na windowsie) napotkałem takie mniej więcej wyjście:

(1:coś) ACPI: [Package] has zero elements (krzaczki, prawdopodobnie zapisane coś szesnastkowo)
(24:) BUG: soft lockup - CPU#1 stuck for 23s! [migration/1:14] //tego wcześniej nie było
(47:) BUG: soft lockup - CPU#1 stuck for 23s! [migration/1:14]
(61:) INFO: rcu_sched detected stalls on CPUs/tasks //być może coś jeszcze ale to ten sam komunikat co wtedy
(ileśtam:) BUG: soft lockup - CPU#1 stuck for 23s! [migration/1:14]
(144:) BUG: soft lockup - CPU#1 stuck for 23s! [migration/1:14]

Po zedytowaniu /etc/grub2.cfg wg przepisu
przed zmianą:
 

linux   /boot/vmlinuz-3.7.6-201.fc18.x86_64 root=UUID=55c7d2ee-68b1-484b-989f-0f83c46057fe ro rd.md=0 rd.lvm=0 rd.dm=0  rd.luks=0 vconsole.keymap=pl2 rhgb quiet LANG=pl_PL.UTF-8

Po zmianie:

linux   /boot/vmlinuz-3.7.6-201.fc18.x86_64 root=UUID=55c7d2ee-68b1-484b-989f-0f83c46057fe ro rd.md=0 rd.lvm=0 rd.dm=0  rd.luks=0 vconsole.keymap=pl2 rhgb quiet LANG=pl_PL.UTF-8 noacpi

jedyną wiadomością jaka się ukazała była:

(1:coś) ACPI: [Package] has zero elements (krzaczki)

a potem poszło bez zawieszania.

Pytanie czy już jest dobrze, czy to wystarczy, czy jeszcze coś można lepiej poprawić... Głupio by było gdyby prze byle zaniku prądu cały bootloader siadł (żeby uruchomić coś z płyty to musiałem w ogóle w biosie wyłączać bootowanie czegokolwiek z dysku, a i to nie zawsze działało). Na razie jeszcze przez tydzień jestem w domu i mogę się takimi rzeczami zająć, ale później wyjeżdżam i np nie będę miał dostępu do stałego neta więc chciałbym się jakoś zabezpieczyć na przyszłość. Anyway - na razie pytanie czy tak ma być?

[TrolleY]

Moja radość była przedwczesna. Po uruchomieniu windowsa i znowu fedory znów wróciło:

(1:) ACPI: [Package] has zero elements (krzaczki)
(61:) INFO: rcu_sched detected stalls on CPUs/tasks 

Może dodam, że również windows błędnie wykrywa partycję ext4 i swap jako dyski H: oraz I: oraz przy włączaniu próbuje je naprawić (szybko się orientuje, że nie umie tego zrobić i że jest tam nieznany mu filesystem). Postaram się również to naprawić od strony windowsa.

w /proc/cmdline po boocie widniało na końcu "noacpi"

[TrolleY]

Cóż... Doszedłem do pewnych wniosków po wielu testach. Podejrzewam, że długie uruchamianie się fedory to problem związany z uszkodzoną kością ramu, co wykryłem testem pamięci... Dlaczego dodatkowo tak sądzę? Fedora z płyty ostatnio też mi się uruchamiała długo z tymi samymi komunikatami, a ona przecież się chyba właśnie do ramu wczytuje...

Jeśli chodzi o ogólne problemy z bootloaderem to problem podejrzewam był w tym, że linux nie był zainstalowany na partycji rozruchowej. Rozwiązanie? Używam podwójnego bootowania, grub mi się uruchamia z bootloadera windowsowego po wybraniu opcji "Fedora".

Może komuś to w przyszłości w czymś pomoże...