Description of problem: udevd:[123]: error: runtime directory '/run/udev/' not writable, for now falling back to '/dev.udev.' Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Clean install 2. remove splash=silent from /boot/grub/menu.lst 3. set system to boot runlevel 3 and reboot 4. verify no writable udevd message shows on screen 5. apply updates, reboot 6. verify no writable udevd message shows on screen 7. install Radeon fglrx package, reboot You should now see the udevd /run/udev/ not writable, message in the screen scroll by.
Hi, thanks for reporting this bug. You are using systemd ? As there is no maintainer for this package I added the committers in CC.
CC: (none) => anssi.hannula, boklm, dmorganec, eugeni, mageia, mageia, misc, pterjan, thierry.vignaud, tmbSummary: 2_a1: udevd: runtime directory '/run/udev/' not writable => udevd: runtime directory '/run/udev/' not writableSource RPM: fglrx => (none)
I'm sure this question was asked already.... but I cannot find the bug :s Maybe it was just on the mailing list. Can you do: "urpmi dracut" and then regenerate your initrd (dracut -f /boot/initrd-$(uname -r).img) and reboot and see if it helps? Keep a backup of your existing initrd etc. etc. to make sure all is well.
(In reply to comment #2) > I'm sure this question was asked already.... but I cannot find the bug :s Maybe > it was just on the mailing list. I was also surprised to found no bugs related to this one :) (but indeed I have forget the tread on the ml :/ )
(In reply to comment #1) > You are using systemd ? Yes. (In reply to comment #2) > Can you do: "urpmi dracut" and then regenerate your initrd (dracut -f > /boot/initrd-$(uname -r).img) and reboot and see if it helps? > > Keep a backup of your existing initrd etc. etc. to make sure all is well. Just to be clear. Problem only shows up when I install the proprietary Radeon driver. It in turn is supposed to install some dkms flgx whatever modules/drivers and modify Xorg config files to use new video driver. Since this started there have been two kernel release/updates. Are you asking me install the Radeon driver, which dinks up the system and then regenerate the initrd or am I supposed to regenerate initrd then install the driver. Personally, I do not believe recompiling initrd is not going to help the /run priv problem since /run is writable/working until the radeon rpm is installed.
Just regenerate the initrd from now. dracut works very differently to the traditional initrd and actually starts udev in the initrd. Not sure it will fix the problem but it's worth trying seeing as I cannot test myself and it should be nice an quick to rule it out.
(In reply to comment #6) > Just regenerate the initrd from now. > > dracut works very differently to the traditional initrd and actually starts > udev in the initrd. Yup, I'll say. :-( did the drakcut, rebooted, some complaints about /boot then screens of problems going by. Re-installing as I type. :(
Aww dude, no need to reinstall. It's trivial to fix it up again :( You just edit the grub prompt by pressing e at startup then change the initrd line to use the backup file you made of the current initrd. I'd really need to see those screens of problems so I can fix it up. Ideally, you should do it again (but keep in mind this is totally non-fatal!) and keep a careful log (photos is fine) of the errors you are getting.
(In reply to comment #8) > Aww dude, no need to reinstall. It's trivial to fix it up again :( You just > edit the grub prompt by pressing e at startup then change the initrd line to > use the backup file you made of the current initrd. Yes I hear you. But you have to understand I am I am in two modes. One is base install, Two is my custom changes. Currently I have 75+ tweaks to config files, disabling daemons,.... Once I run down a problem which I believe is a base Mageia problem I report it, and go back to debugging my automated new_install scripts. Pretty sure you would prefer a clean setup. :-D FYI: I just use rsync --delete which puts it back pretty quick. :) > I'd really need to see those screens of problems so I can fix it up. Ideally, > you should do it again (but keep in mind this is totally non-fatal!) and keep a > careful log (photos is fine) of the errors you are getting. Hey, send me a video recorder and I let you watch the movie. :-8 I need to set the terminal speed to 30 baud if you want me to write down the messages. This AMD Athlon(tm) 64 Processor 3800+ is not shy about pushing the display faster than I can read. I installed Mandriva 2011 on this machine to help researching what systemd looks like between Mageia and Mandriva. That changed grub to mdv and I have to chainload to mga. That should have no impact. But, when I went to mga and tried grub-install /dev/sda it will not reinstall mga's grub setup. :( # grub-install /dev/sda /dev/root does not have any corresponding BIOS drive I have see the error message about links in /boot or something flash by in the past, so I have no idea if that helps drakcut into the ditch. Since grub-install does not work, I really will have to reinstall instead of an rsync.
(In reply to comment #2) > > Can you do: "urpmi dracut" and then regenerate your initrd (dracut -f > /boot/initrd-$(uname -r).img) and reboot and see if it helps? Is it ok to do a dracut -v /boot/initrd-dracut-$(uname -r).img $(uname -r) and use the *dracut* generated stuff in another grub stanza. I have a feeling I'll be doing this more than once and have no desire to keep moving backup .img files around.
(In reply to comment #10) > (In reply to comment #2) > > > > Can you do: "urpmi dracut" and then regenerate your initrd (dracut -f > > /boot/initrd-$(uname -r).img) and reboot and see if it helps? > > Is it ok to do a > > dracut -v /boot/initrd-dracut-$(uname -r).img $(uname -r) > > and use the *dracut* generated stuff in another grub stanza. Absolutely. Any way to boot using that initrd is fine. Even if it's calling it something simple like /boot/initrd-dracut.img and then manually changing the grub command at boot, it's perfectly fine :)
(In reply to comment #11) > Absolutely. Any way to boot using that initrd is fine. Even if it's calling it > something simple like /boot/initrd-dracut.img and then manually changing the > grub command at boot, it's perfectly fine :) Or adding a stanza to grub. :-D title Mageia_2_0_64_Alpha1_dracut kernel (hd0,8)/boot/vmlinuz BOOT_IMAGE=Mageia_2_0_64_Alpha1_dracut root=LABEL=cauldron hpet=force irqpoll init=/bin/systemd 3 vga=788 initrd (hd0,8)/boot/initrd-dracut-3.1.4-desktop-2.mga2.img Did the test in VirtualBox, worked without problem. :-( Afraid you will not get much from the following. Guessing udev is trying a write sequence for a red Failed. Result is text jumping around and re-writing lines or scrolling making it damn hard to see messages. :-( console showing everything is normal until Started configure read-only root support In a few seconds cpu fan comes on full rpms :( sets there for a little while. Guessing that delay is because it wants to find my labeled / to append to log file. Nothing there by the way. Then for all partitions, I get Relabel all filesystems, if necessary abort because a dependency failed Setup links in /boot for running because a dependency failed. A little while later bunches of messages for every partition, tty.... timeout in /dev/.in-sysinit udev[427] udisks-probe-ata-smart /dev/sdb killing /lib/systemd/systemd-uaccess /dev/sr1 [988] Rafts of messages showing kill timed out threads or whatever then continues kill it messages.
I think this is somewhat related to: https://bugs.mageia.org/show_bug.cgi?id=3315 as you seem to be hitting some udev timeouts. Could you perhaps try with a longer timout hacked into dracut as per the patch on that bug? It's not necessarily the right fix but it would at least help to confirm the root issue is likely related. Thanks :)
(In reply to comment #13) > I think this is somewhat related to: > https://bugs.mageia.org/show_bug.cgi?id=3315 as you seem to be hitting some > udev timeouts. > Could you perhaps try with a longer timout hacked into dracut as > per the patch on that bug? It's not necessarily the right fix but it would at > least help to confirm the root issue is likely related. Thanks :) tried the 300 second patch in current install, no help, tried with the dracut image. Did not help. Did not bother to wait even longer before cpu fan to rev up. Just for fun, I removed init=/bin/systemd from the normal grub stanza. I received the same not writable message. I have also noticed that if I hit a situation where the Hit Control D or login pw, I can resolve the issue, continue booting but instead of runlevel3 I get the gui login. Both of those problems makes me think the system init fault logic/code is not as well tested. :) Can only guess radeon package is causing the same fault which can be re-created by removing init=/bin/systemd from boot stanza. Current clean install radeon video package does not load firmware. Log snippet follows: [drm] Loading RV710 Microcode r600_cp: Failed to load firmware "radeon/RV710_pfp.bin" [drm:rv770_startup] *ERROR* Failed to load firmware! radeon 0000:01:00.0: disabling GPU acceleration Those video driver firmware bin files need to be on install media. :) Hope you all get that problem out of committee fairly quickly. As an fyi, I have a clean Mandriva 2011.0 64 bit install on this system and it boots right up in about 46 seconds. It has been my experience when trying to solve a major bug, that it saved time in the long run by fixing any "Unrelated problems" in the code as I look for the major bug I was hunting in the first place. It would be ironic if bug https://bugs.mageia.org/show_bug.cgi?id=3727 is causing the Radeon fglrx package install grief.
I can reproduce/read this error on a fresh mageia alpha 2 (live cd kde) install under virtualbox if it can help for reproducer.
CC: (none) => balcaen.john
(In reply to comment #15) > I can reproduce/read this error on a fresh mageia alpha 2 (live cd kde) install > under virtualbox if it can help for reproducer. As a double check does the fresh install use systemd by default. There was a cross over between some drakx code change to remove the kernel command line and some meta-task changes to install systemd-sysvinit over sysvinit. And just for clarity are you referring to the "not writeable" message rather than some of the other issues that have cropped up in this bug?
(and just for my clarity, I'm pretty sure the "not writeable" problem stems from mkinitrd which is no longer used - dracut is now forced on everyone.
(In reply to comment #16) > (In reply to comment #15) > > I can reproduce/read this error on a fresh mageia alpha 2 (live cd kde) install > > under virtualbox if it can help for reproducer. > > As a double check does the fresh install use systemd by default. There was a > cross over between some drakx code change to remove the kernel command line and > some meta-task changes to install systemd-sysvinit over sysvinit. It does use systemd by default (there's also a init=/bin/systemd on the command line but removing it still allows the boot via systemd) > And just for clarity are you referring to the "not writeable" message rather > than some of the other issues that have cropped up in this bug? i'm referring to this message : « udevd:[104]: error: runtime directory '/run/udev/' not writable, for now falling back to '/dev.udev.'»
(In reply to comment #18) > i'm referring to this message : > « udevd:[104]: error: runtime directory '/run/udev/' not writable, for now > falling back to '/dev.udev.'» Cool, thanks. Like I say I'm pretty sure this is only a problem with a mkinitrd generated ramdisk. dracut should do everything OK. Now I've pushed dracut to always be used, it should work fine (of course this broke the installer, but I've patched stage2 now and just need to rebuild it).
Ok, I can now install the radeon proprietary video driver without getting the '/run/udev/' not writable' problem. Even though I had all updates/kernels, I still had the problem along with udev hotplug delays and whatnot. I did another clean install/updates/reboot. and installed the radeon driver. The 36s boot time is much nicer. than the 1 to 3 minute 25s I had before. No write error and the teapot video test went from the install value of 8 FPS to the new driver value of 130 Frames Per Second.
@ Bit Twister Thanks for the feedback. I understand the problem got fixed Closing this report. Anyone still experiencing this bug: feel free to reopen
Status: NEW => RESOLVEDCC: (none) => marja11Resolution: (none) => FIXED
CC: boklm => (none)