FS#9640 - udev-118-2 missing /etc/udev_start

Attached to Project: Arch Linux
Opened by Zeqadious (Zeqadious) - Thursday, 21 February 2008, 15:20 GMT
Last edited by Roman Kyrylych (Romashka) - Sunday, 16 March 2008, 20:09 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To No-one
Architecture i686
Severity Critical
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
The new udev-118-2 in testing is missing /etc/udev_start causing the system to be unable to find and mount the / or any other fs at boot. I copied the udev_start from udev-116-3 and it works perfect again.

Additional info:
* package version(s)
118-2
* config and/or log files etc.
/etc/udev_start

Steps to reproduce:
pacman -Syu (this morning 2/27/08 10:00:00 EST (-5GMT)
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Sunday, 16 March 2008, 20:09 GMT
Reason for closing:  Fixed
Comment by Dan McGee (toofishes) - Thursday, 21 February 2008, 18:15 GMT
You need the new initscripts package too. We might release a udev version with this old crusty script as a workaround, but who knows.
Comment by Oblong Cheese (Oblong_Cheese) - Friday, 22 February 2008, 13:43 GMT
Could somebody please post steps to apply the above-mentioned fix for those who are not familiar with the use of LiveCD / rescue disks?
Comment by Roman Kyrylych (Romashka) - Friday, 22 February 2008, 15:30 GMT
In this case all you have to do is:
1) when a large info message popups (with "or press Ctrl-D to continue" at the end)
enter root password
2) remount the root filesystem with the command mentioned in that info message above
3) pacman.static -U /var/cache/pacman/pkg/udev-116-3-i686.pkg.tar.gz
or pacman.static -Sy initscripts to get the latest initscripts version which works with udev-118
Comment by Aaron Griffin (phrakture) - Friday, 22 February 2008, 18:00 GMT
Could you please explain why you upgraded udev individually - I really don't understand why someone would do this.
Comment by Zeqadious (Zeqadious) - Friday, 22 February 2008, 18:20 GMT
Sure.

I did pacman -Syu and it installed udev. It did not install testing/initscripts so I didn't know their was a new one. I had splashy installed at the time of pacman -Syu so it may* have kept initscripts from being pulled and installed, I'm not sure, because pacman -Qi udev shows that udev is not dependent on udev. Splashy has initscripts-splashy which conflicted with testing/initscripts so I removed that to get the new testing/initscripts installed.

When the new testing/initscripts is installed everything works good again I can confirm.
Comment by Aaron Griffin (phrakture) - Friday, 22 February 2008, 20:13 GMT
Ah, so you had alternative initscripts installed...
Comment by Oblong Cheese (Oblong_Cheese) - Friday, 22 February 2008, 22:47 GMT
I didn't have alternative initscripts installed, I did do a pacman -Syu a few days ago though.

Roman Kyrylych, my system never gets to that point. "Loading udev uevents" fails (naturally), causing a failure of everything else: filesystems aren't mounted, and services don't start. When it starts to load HAL, it sits there for ages not doing anything.
Comment by Oblong Cheese (Oblong_Cheese) - Friday, 22 February 2008, 23:19 GMT
Sorry for double post,

I have updated my initscripts and udev from testing but this hasn't fixed my problem.

When I boot now, during the process of loading modules and starting services, my screen resolution changes (which I guess is part of the new initscript), and is helpful beacuse it allows me to see more of the problem I'm having...

Anyway, after "Loading udev uevents", I get a message printed saying something about "Bad superblock on /dev/sda3, last edit time in the future. FIXED.", but immediately thereafter, none of my filesystems are mounted properly, and the system hangs on "Starting Hardware Abstraction Layer"

Any ideas?

I have already booted into the Arch installation environment and run an fsck on all my filesystems, they checkout OK.
Comment by Aaron Griffin (phrakture) - Friday, 22 February 2008, 23:37 GMT
Hrm, the initscripts should not affect your resolution at all... unless maybe it's loading framebuffer devices...

How long does "Loading UDev events" take. If it actually does something, then udev is working properly and you do NOT have the bug reported in this bug report. In that case, you have a different bug.
Comment by Oblong Cheese (Oblong_Cheese) - Saturday, 23 February 2008, 02:12 GMT
Apologies guys, I do not have this bug.

I changed my fstab last night and forgot I had done so this morning. If you could please delete all my errant postings in this bug report, it'd be appreciated. :-)
Comment by wrisky (risky) - Monday, 25 February 2008, 09:47 GMT
I had this issue as well
Comment by tigrmesh (tigrmesh) - Tuesday, 26 February 2008, 16:16 GMT
The problem is that running /etc/start_udev is given in the instructions "- To reload your rules please use /etc/start_udev." (/etc/udev/readme-udev-arch.txt, line 60). It is also mentioned on lines 127 and 145. It's the only alternative to bootup given for persistent CD/DVD and network names. Please fix. I know this will only affect people who RTFI, but we deserve love too.

Otherwise, I thought the instructions were clear. I followed them easily and was able to set my persistent network device names. The only problems I had were because I was running splashy. Removing splashy and using the new initscripts fixed everything. Will initscripts-splash also be updated at the same time that initscripts moves to core?

My bootup is faster now; it doesn't pause at Running Hook [udev] any more, and it hardly pauses at waiting for devices to settle. UDev uevents took 15388 ms at last boot.

Thanks for a great job!
Comment by Bob Fanger (NebyGemini) - Thursday, 28 February 2008, 19:24 GMT
15sec is quite slow. It seems the IMPORT{program} rule in /etc/udev/rules.d/00-load-blacklist.rules is executed for every module.
commenting this rule. commenting(#) results in a faster boot (3.5sec) but disables module blacklisting (again)
Comment by Aaron Griffin (phrakture) - Friday, 29 February 2008, 22:56 GMT
We went over this on the developer ML. Please can we stick to one problem per bug report - this is NOT a forum.

Loading...