Archlinux: Na update boot pc niet meer

[DeadLock]

Ik draai al sinds enkele maanden archlinux en ben er over het algemeen héél gelukkig mee. Deze distro is de distro geworden die ik wil en hoop te blijven gebruiken. Na rondzwervingen en distro's als kubuntu, gentoo, suse, ... uitgebropeerd te hebben ben ik toch bij arch blijven hangen.

Het probleem: gisterenmiddag ongeveer heb ik een upgrade gedraaid (pacman -Syu), het was al ongeveer een week à twee weken geleden dat ik nog geupgrade had. De update op zich ging goed, maar er stonden wel warnings dat hij iets gedaan had met udev (weet juiste warnings niet meer). Aangezien ik zover ik me meen te herinneren nooit zelf udev config files heb aangepast ofzo, dacht ik dat dit niet van belang was voor mij.

Tot ik deze ochtend men pc wilde opstarten, er in het eerste deel van het bootproces (het deel van udev) errors komen te staan en mijn pc dus niet verder wilt booten.

De errors: Failed to parse blockdevice name for sdc2 en root fs: cannot be detected.

Nu zit ik momenteel even op een live-cd om dit probleem op te kunnen lossen, maar ik heb er geen idee van wat het juiste probleem is en hoe ik het zou kunnen oplossen.
Als FS heb ik XFS.

Iemand die me kan helpen aan een oplossing ? De archfora heb ik bezocht, geen zelfe gevallen gevonden....

[wzzrd]

Doet arch ook iets met backups van gewijzigde bestanden in /etc?
Kijk eens in /etc/udev of daar backups staan.

[DeadLock]

Ik zie er geen backups staan:

code:

ubuntu@ubuntu:/mnt/usb/etc/udev/rules.d$ ls
60-cdrom_id.rules                           device-mapper.rules
60-pcmcia.rules                             gphoto.rules
75-cd-aliases-generator.rules.optional      sane.rules
75-persistent-net-generator.rules.optional  udev.rules
90-hal.rules

Ik heb ook geen idee waar en wat ik juist moet zoeken om dit te kunnen oplossen.

In de 'readme-udev' die er staat, heb ik misschien wel nog wat interessants gevonden:

code:

* How it works:
---------------
- Udev replaces the functionality of hotplug and hwdetect scripts.
- Udev does autoloading of modules and coldplugging.
- Udev loads the modules simultaneously, which is much faster,
  but can cause some troubles with multiple network/sound/etc devices
  (see below).
- To reload your rules please use /etc/start_udev.

Zou het helpen om te chrooten en dit scriptje eens te runnen ?

[ Voor 38% gewijzigd door DeadLock op 03-08-2007 13:21 ]

[Miki]

Ik liep vanochtend tegen hetzelfde probleem aan, ik heb echter alleen nog geen tijd gehad om dit verhelpen. Ik heb zo'n vermoeden dat udev de verwijzigingen naar de hardeschijven door elkaar haalt of dat de modules niet worden geladen.

Als het goed is moet je een melding krijgen met iets in de trant als root device /dev/xxx could not be found or created

Het gekke is bij mij wel, dat de fallback image het wel gewoon doet en dat terwijl mkinitcpio -p kernel26 ook de fallback image regenereerd. Ook heb ik al geprobeerd om dezelfde hooks te gebruiken van de fallback image maar dat wil ook niet baten. Wat ik als laatste heb geprobeerd was bij /boot/grub/mmenu.lst de filesystem"xfs" toevoeging te gebruiken maar ook dat hielp niet.

Vanmiddag ga ik het forum van Arch doorzoeken.

[DeadLock]

Het is 'goed' om te weten dat ik dus niet de enigste ben die tegen dit probleem aanloopt . Bij mij werkt zelfs de fallback image niet meer, dus ik kan niet arch booten en wat rondstooien tot het werkt. Zou je me in iedergeval op de hoogte kunnen houden van eventuele oplossingen via dit topic ?

Dat scriptje runnen in een chrooted omgeving heeft ook geen oplossing kunnen bieden, nu weet ik het verder echt niet meer. Wel best lastig .

[Borromini]

Ik heb dat ook al gehad .

Nu heb ik nog een rits andere f¨*ckups gehad met Arch onlangs (lang leve de pacman bugs), maar het is een probleem met de initrd voor zover ik weet . Probeer je fallback entry es te booten (je kan je GRUB-commandline ook on the fly wijzigen indien nodig) - hoogstwaarschijnlijk werkt dat wel.

Indien niet: chrooten van de install CD, en je initrd opnieuw genereren, dat zou het moeten fiksen. Of je HD-controller of je FS wordt niet herkend (wat waarschijnlijk komt omdat de drivers niet meer in de initrd zitten).

[Miki]

Chrooten is mij wel duidelijk, tenminste met dit in het achterhoofd:

code:

mount /dev/sdaX /mnt
mount -t proc   proc      /mnt/proc
mount -t sysfs  sys       /mnt/sys
mount -o bind   /dev      /mnt/dev
chroot /mnt /bin/bash

Maar hoe regenereer je precies je initrd Borromini? mkinitcpio heeft toch deze taak overgenomen of snap ik iets niet? Ik ben hier op mijn werk al aan het zoeken op het arch forum maar vindt nog niks wat ik al niet geprobeerd heb.

[_JGC_]

Hmm, Tobias vanavond maar even schoppen, misschien dat die weet wat er mis is.

De Fallback image zou het iig altijd moeten doen, de normale image is afgestemd op je hardware, blijkbaar is er iets misgegaan bij het detecteren van je hardware en zijn er modules niet meegenomen die wel meegenomen moeten worden. Zou je eens met "zcat /boot/kernel26.img | cpio -t" kunnen uitzoeken welke modules er meegenomen worden in de initcpio image en deze kunnen posten met de uitvoer van lspci?

[DeadLock]

Ok, ik heb het hier weer werkend gekregen na tig keer booten vanaf een live cd'tje.

Wat heb ik gedaan:

Chrooten naar mijn arch installatie.
Mijn grub config, dus menu.lst weer aangepast, daar root=/dev/sdc ipv sdB, dus deze had arch blijbkaar overschreven.
In fstab net hetzelfde probleem, er stond overal /dev/sdC , terwijl mijn disk écht wel /dev/sdB is.
Hierna kernel opnieuw installeren, zodat hij die initrd weer opnieuw genereerd.

Dit heeft bij mij het probleem verholpen, ben er enorm blij om dat mijn systeem weer werkt . Bedankt voor alle hulp hier. Wel jammer dat er zo'n slordige fout in de arch 'stable' tree is geslopen.

[Miki]

Hmm ik denk dat ik dan de kernel opnieuw moet installeren met pacman. Mijn fstab en grub verwijzingen naar mijn root partitie lijken niet te zijn gewijzigd. Immers de fallback image boot nog steeds. Vermoedelijk zijn de modules niet meegenomen tijdens mkinitcpio proces.

[GX]

evert_ schreef op vrijdag 03 augustus 2007 @ 14:49:

Dit heeft bij mij het probleem verholpen, ben er enorm blij om dat mijn systeem weer werkt . Bedankt voor alle hulp hier. Wel jammer dat er zo'n slordige fout in de arch 'stable' tree is geslopen.

Ik weet niet helemaal hoe arch werkt, maar dit lijkt wel te komen doordat udev of whatever je hdd anders gedetecteerd heeft. Misschien komt dit wel door iets wat je in het verleden gedaan hebt. Lijkt mij dat de blame niet in het geheel bij arch ligt in dit geval.

(overigens is het eerste waar je naar kijkt met die melding je harde schijven setup, of ligt dat aan mij?)

[Borromini]

Miki schreef op vrijdag 03 augustus 2007 @ 15:17:
Hmm ik denk dat ik dan de kernel opnieuw moet installeren met pacman. Mijn fstab en grub verwijzingen naar mijn root partitie lijken niet te zijn gewijzigd. Immers de fallback image boot nog steeds. Vermoedelijk zijn de modules niet meegenomen tijdens mkinitcpio proces.

Je kan ook manueel mkinitcpio runnen om bestaande initrd's te vervangen .

code:

mkinitcpio -h

geeft meer duidelijkheid.

GX schreef op vrijdag 03 augustus 2007 @ 15:30:
[...]

Ik weet niet helemaal hoe arch werkt, maar dit lijkt wel te komen doordat udev of whatever je hdd anders gedetecteerd heeft. Misschien komt dit wel door iets wat je in het verleden gedaan hebt. Lijkt mij dat de blame niet in het geheel bij arch ligt in dit geval.

Udev springt pas in nadat je root gemount is . Waar denk je dat udev op geïnstalleerd is? GRUB laadt de initrd en de kernel, de kernel geeft dan init (the mother of all processes ) de controle en die boot het systeem met behulp van de - jawel - init scripts .

Tot daar de les 'hoe boot Linux'

Ik vrees trouwens dat het wel bij Arch ligt, aangezien ik nog geen klachten gehoord heb van gebruikers van andere distro's...

[ Voor 44% gewijzigd door Borromini op 03-08-2007 16:14 ]

[GX]

Borromini schreef op vrijdag 03 augustus 2007 @ 16:11:
[...]
]

Ik vrees trouwens dat het wel bij Arch ligt, aangezien ik nog geen klachten gehoord heb van gebruikers van andere distro's...

Nou ja, klachten niet horen betekent niet dat ze niet bestaan; ik heb de udev upgrade en libata-driver update meegemaakt met Gentoo, en dat kostte me uiteindelijk ook meer tijd dan met andere kernels; met ongeveer dezelfde foutmeldingen..

He tkan overigens goed dat ik van alles door elkaar haal hoor, want ik had toen ineens problemen met ongeveer ieder stuk hardware die in m'n laptop zit

[ Voor 13% gewijzigd door GX op 03-08-2007 16:18 ]

[_JGC_]

Borromini schreef op vrijdag 03 augustus 2007 @ 16:11:
[...]


Je kan ook manueel mkinitcpio runnen om bestaande initrd's te vervangen .

code:

mkinitcpio -h

geeft meer duidelijkheid.


[...]


Udev springt pas in nadat je root gemount is . Waar denk je dat udev op geïnstalleerd is? GRUB laadt de initrd en de kernel, de kernel geeft dan init (the mother of all processes ) de controle en die boot het systeem met behulp van de - jawel - init scripts .

Tot daar de les 'hoe boot Linux'

Ik vrees trouwens dat het wel bij Arch ligt, aangezien ik nog geen klachten gehoord heb van gebruikers van andere distro's...

Er zit ook een udev in de initcpio image. Om even duidelijk te maken wat er gebeurt:

grub wordt geladen, deze laadt een kernel welke een initcpio image uitpakt.
In dit initcpio image zit een bak software en wat init scripts, deze zorgen dat de juiste modules geladen wordt. Dit gebeurt bij Archlinux gewoon met udev. Als alle modules geladen zijn en alle taken voltooid zijn, dan zorgen de scripts in de initcpio image ervoor dat er geboot wordt vanaf je rootfs. Op dat moment wordt er alsnog een keer udev gestart, dit keer eentje die werkt op je systeem ipv vanuit de initcpio image.

[Miki]

Beetje laat maar goed... door de kernel opnieuw te installeren was mijn probleem verholpen. Toch blijft Arch echt