feisty boot probléma (2.6.20-16)

Ubuntu Linux

sziasztok!

tegnap jöttem haza szabiról, bebootoltam, szólt az új kernelről, hogy kéne neki, ha akarom frissítsem. mondom jó, nem volt eddig nagy gond. hát most lett, mert az új kernel, bár minden létező paraméterében azonos a korábbival (mármint a grub-ban levő opciókra gondolok), nem bootol. a spash screenen levő bitkolbász az első pixelnél megakad. a karakteres képernyőre váltva megáll azon a ponton, amikor a kernelt kiválasztja és bootolni akarja. se hibaüzenet, se semmi egyéb. csak áll.

eddig egyszer volt hasonló egy kernelcserénél. akkor a grubban a betűzést cserélték fel (ami korábban hd(0,0)-volt, az hd(1,0) lett. de ott legalább kiírta a grub, hogy neki valami nem stimmel, nincs meg a bootra megjelölt eszköz. itt viszont most semmi, csak megáll.

járt valaki így?

  • 1241 megtekintés

( _neo v | 2007. 05. 29., k – 11:49 )

Én is így jártam, de nekem más a gond. A hálózat iszonyat lassan éled és a notim akkumulátorát se látja. Eddig ennyi tunt fel, lehet mas is van, de nekem nem áll meg boot kozben.
Egyszeruen megoldottam a problémát: bootolom a régi kernelt, semmi gond:)

( kupcsik v | 2007. 05. 29., k – 12:00 )

a grub boot menuben torold ki a quiet splash opciokat, ugy lehet, hogy tobbet megtudsz. vagy nem. de lehet, hogy megis. Addig meg persze lehet bootolni a regi kernelt, megvan az is.

( KOXX | 2007. 05. 29., k – 12:01 )

Haveromnak frissítés után kernel panic, ma mehetek át hozzá meglesni. Még én sem tudom pontosan mi okozza, de hamarosan kiderül. :/

( Xterm v | 2007. 05. 29., k – 12:47 )

hm... meglehetősen sok eset. nem túl bíztató, hogy másnak is csak az a "megoldás" működik, hogy a régi kernelt visszabootolni... :(

( keko | 2007. 05. 29., k – 14:51 )

Nem egészen ide tartozik, de eleve nem értem miért nem lehetne úgy megcsinálni, hogy ne kelljen minden kernel frissítés után újraírni az egész grubot. Marha idegesítő. Legalább ismerné fel magától az összes telepített operációs rendszert.
Egyébként nekem megy rendesen, nincs vele semmi baj.

( Xterm v | 2007. 05. 29., k – 15:08 )

update:

a jelenség könnyen lehet, hogy nem lesz egyedi, mert eddig a gugli is elég sok találatot ad ki (a kérdések bálaszám vannak, válasz sajna nem nagyon).

a megoldáshoz valószínüleg az vezet, hogy a _pontos_ driver "betűzést" kitalálni, amit az új kernel használ. hiszen a quiet mód kikapcsolásakor írkálja, hogy milyen vinyóim vannak és azok nem elérhetőek és itt jön a slusszpoén: megint hde és hdg néven hivatkozik rájuk, mint anno... ezt egyszer eljátszották már, meglehet, hogy megint.

tudtok módszer arra, hogy miképp tudom meg a pontos mindenkori sorrendet? jelenleg egy ide és két sata vinyó van a gépben. elvileg az egyik sata kéne legyen a boot disk. az ide-n winxp van (jó ég, azt sem tudom mikor bootoltam be :D), a másik sata-n meg adat.

a grub konfigjában a root=UUID kapcsolókkal hivatkozik a diskekre, mint eddig is tette a feisty telepítése óta. ez nem lenne baj, ha működne...

van ötletetek?

Nekem is jelentkezett hasonló probléma, bár az én feisty-m boot-olt, de az nvidia kernel-modullal volt (van) valami gondja. Egyelőre nem volt időm mélyebben belenézni, visszaírtam az xorg-ban az nvidia bejegyzést nv-re és most megy (úgy-ahogy).

Viszont a disk-kezelésben nálam is volt változás az új kernellel. Valahol az edgy -> feisty upgrade során történhetett egy hiba, ami miatt a primary master winchester hda maradt, de a primary slave-ből hdb helyett sdb lett... a dolog ugyan zavaró volt, de mivel nem jutott idő a probléma hátterének felderítésére és így is működött, ezért nem piszkáltam. Ezzel a kernellel viszont a helyzet ismét változott, a primary master ismét hdb-ként jelenik meg...

hát látod ettől én már egyszer falnak mentem. az egy dolog, hogy változik egy modul, mert teszem azt van jobb, kevésbé rossz, stb, ami miatt leváltják. de a névcserélgetések amiképp egy eszközre hivatkoznak... hát az eléggé gáz, mert az tényleg azt eredményezi, hogy az ember folyamatosan editálgatja a grubot. pedig ezt javítani kéne, mert ezek szerint cseppet sem egyedi jelenség úgy meg az ubuntu hírének nem biztos, hogy használ. ha tartósan nem találok megoldást, magyarázatot, stb, akkor fontolóra veszem a bugreportot, mert én a rendszert kedvelem, de ez hosszú távon használhatatlanná teszi a frissítéseket. (értsd "automatikus" frissítések)

lehetséges hogy nem tudja betölteni valamiért az atá-s modulokat
nekem gondom volt az ata modulokkal (vagy csak haldoklik a vinyóm) ezért ezt írtam a /etc/initramfs-tools/modules-ba:

piix
ide_generic
ide_cd
ide_disk

# blacklist bad driver
blacklist ata_piix

# prevent unnecessary modules from being loaded (you don't need to do this)
blacklist ata_generic
blacklist libata
blacklist scsi_mod

azóta nem sda ként, hanem hda-ként látja a vinyóimat

bocs, nem pont neked szolt amit írtam, csak hátha valakinek segitek lokalizálni a problémát

---
otom sprau kana ticuana sanduo pagnoseresmee

( zoly | 2007. 05. 29., k – 16:01 )

Érdekes: nekem eddig az eredeti kernel + "gyári" nVidia meghajtóval 5-10 percenként leállt minden, csak az egérmutatót tudtam mozgatni (filmnézésnél elég bosszantó volt a sűrű "reklámszünet" :-))
Ezzel az újabb kernellel pedig eddig nem tapasztaltam hasonló pillanatnyi "lefagyásokat", remélem eltűnt az a számomra roppant bosszantó tünet!

( zZsOlTi v | 2007. 05. 29., k – 16:10 )

Nálam minden OK. Lejött a kernel meg hozzá a restricted modulok, reboot és minden működik (fstabban UUID-k vannak, grubnak nincs baja, nvidia megy, raid1 megy, mintha a boot kicsit gyorsabb lenne).

( biboka v | 2007. 05. 29., k – 18:34 )

hd(0,0)-t és hd(1,0)-t nekem kb mióta megvan keveri. Ezzel a frissítéssel csak a GDM halt meg, fel kellett tenni KDM-et hogy működjön. Configolni ilyenkor persze nem lehet grafikusan, mondván, hogy nem fut a gdm... Igazából csak lusta vok 1 csomó configot átnézni (gdm.conf jó, másik gépről szedtem át).

( utpKabel | 2007. 05. 29., k – 21:29 )

De jó, hogy én még nem upgradeeltem a feistyre hanem még mindig etchet használok.

( Xterm v | 2007. 05. 29., k – 21:36 )

hm... úgy látom tekinthetjük ezt egy x-aktának? csak mert a fórumokon, ezt is beleértve, tanácstalanság van a dologgal kapcsolatban. mindehol volt változás, csak sajna nem mindenhol jó. meglehet, hogy valameilyen hardverrel van a gond, csak az a baj, hogy azt debugolni nem egyszerű sima userként, mert nincs módomban csereberélni a vasat (pl. nincs kedvem leforrasztani az sata verzérlőt az alaplapról :) )

nem fogok belehalni, ha a mostani kernellel kell tovább menjek, de nagyon nagyon remélem, hogy a következő hamar kijön és ráadásul meg is javítja. addig meg parázom, hogy mi lesz, ha valamelyik update nem megy majd azért, mert azt a kernelt használom, amit ők már kukázni akartak... :(

( mako | 2007. 05. 29., k – 21:44 )

Nálunk a cégél 6 gépből 4! nem volt hajlandó boot-olni.
Szerencsére nekem a melóhelyi PC-m és az itthoni lapostop is gond nélkül megy.

De a nálunk is abból adódott a probléma, hogy a sdx vinyókat megint hdx-ként keresi.

( dying_sun | 2007. 05. 29., k – 22:37 )

két gépen fut feisty desktop, nem volt boot-gondom a frissítés után, gondolom azért, mert UUID alapján vannak a winyók az fstab-ban. ellenben a nautilus talált két új cd meghajtót, amivel nem tudott mit kezdeni. az fstab-ban az scd-ket átírtam hdc/hdd-re és ez is megoldódott. nem néztem utána, de ez alapján úgy látszik, hogy a telepítő cd-n lévő feisty kernel nem kezeli hdX-es meghajtókat, az új kernel meg az sdX/scd meghajtókat nem.

tudja valaki esetleg az ideológiai okát, hogy mi értelme volt egy ilyen vakvágányt beletenni a current stable-ba? flame nem érdekel, csak az, hogy milyen előnye lett volna/lehetett volna az sdX-es megoldásnak a hdX-essel szemben..

-------------------------
Hiánypótló ismertető kezdőknek: A Linux filozófiája és az áttérés Windowsról

Azt nem tudom, de a fórumokon az okosok (== kernel maintainer-ek, hozzáértők) szerint a váltás behozoztt 1-2 race condition-t a boot folyamatba, ami miatt a régi meg az új driver összeakad, és boot közben véletlenszerű, hogy éppen melyik melyik hardver-t kapja meg (esetleg mindkettő ráuszul ugyanarra és megduplázódnak eszközök), ráadásul egyes alaplapoknál még valami vezérlők driverével is gubanc van (valami JMicro controller asszem), szóval nem értem, mért kellett ezt a húzást egy stable rendszerben kernelfrissítés címszóval beficcenteni...

ez érdekes adalék! az más tészta, hogy ezt nem csak most csinálták meg. én spec meglepődtem, hogy a frissen telepített feisty pl. az ata és a sata disket is azonosan látja megint, de most épp sdX-ként. majd ugyan ezt vissza (alig 1-2 hét telt csak el, és ez a nem mind1...).

sajnálom, hogy ez így megy. én spec lehet inkább megvárom a köv kernelt, míg belenyúlok a rendszerbe annyira, hogy kockáztassam a köv frissítéskori totál bootképtelenséget (értsd szétdíbolni a grubot meg az fstabot, scripteket, stb). biztos lustaságnak látszhat pár ember szemében, de inkább óvatosság.

nem tudom megmondani neked az időt, de ez nem volt mindig így. volt az ubuntus gyári kernelben (sőt, talán még a debian kernelben is) egy olyan állapot, amikor egy "rövid időre cseréltek, majd vissza". az egész azért gáz, mert most minden update után kurkásszuk végig a különböző indító és egyéb scripteket, hogy jó legyen minden? a feisty már nem fejlesztői kernel csak, hanem stabil. nem lenne jó, ha azért kéne olvasgatni a devel listákat, fórumokat, hogy az ilyenekre fel tudjunk készülni :S legalábbis sztem...

nekem tetszett a feitsy eddig. van ami nem, nyilván, de azt kerülöm. de azért a kernel bootképességét elég nehéz kerülni. szóval marad a várakozás kicsit, aztán egy új próba. hátha. ha nem, akkor jön majd nyáron az, hogy forgatok egy saját kernelt és szétszedem apró darabokra, hogy kiderüljön mi a bibi. csak sajna kinek van ennyi ideje (meg kellő hozzáértése ugye...)

( kupcsik v | 2007. 06. 01., p – 08:30 )

A boottal nekem nem volt gondom, sőt azt hittem, semmivel. De upgrade óta párszor előfordult, hogy a dvd-olvasóm lehalt, és magával húzta a rendszert, 100% procihasználat, satöbbi. Mivel a kernel upgrade-ben volt ilyen jellegű "fejlesztés", ezért arra gyanakszom.

A következő a javaslatom:
- reboot az eggyel régebbi kernellel
- sudo vim /etc/apt/preferences, ebbe bele:
Package: linux-image-*
Pin: version 2.6.20-16*
Pin-Priority: -1
- sudo apt-get remove linux-image-2.6.20-16-generic
- sudo /usr/sbin/update-grub