Thanks! That was exactly what was wrong for me too. :-)
Comment by Dave — December 12, 2006 @ 6:22 pm
See https://launchpad.net/ubuntu/+source/gdm/+bug/81670. In fact, all you need is (1) disable automagic login (it logs you in as soon as possible, which is a bad idea on this bug, and a bad idea on security), and (2) give it a minute or so before logging in.
It is a race condition, and you lose if you log in before a certain piece of the system starts (udev). This only happens after a boot.
Comment by hggdh — February 12, 2007 @ 10:04 pm
I think i know the exact cause of this. I was trying to make a Fat32 share in root. I had to enable Root to login with GDM. when i enabled it, the next reboot I got the error. I disabled it and the error was gone. I think this has to do more with Root being allowed to login coupled with Auto login.
Just letting ya know. Im a Linux noob but noticed this happened.
Comment by Geilt — February 13, 2007 @ 11:17 am
It’s nothing to do with root, it’s a simple race condition as hggdh said.
Comment by Dave — February 13, 2007 @ 2:01 pm
Oh! allright, no idea what a race condition is either =) Told ya im new!
Switching from windows has been fun!
Comment by Geilt — February 13, 2007 @ 6:27 pm
:-)
It just means it depends on which process manages to load first. By delaying the login a bit longer (use timed login instead of automatic login) you help udev to finish first.
Comment by Dave — February 13, 2007 @ 6:31 pm
Ah! That makes sense. Although I wonder why there is no priority to what loads up first? Are multiple things loaded at once instead of one by one to increase boot time?
For Example: In windows, when it starts loading its DLL’s it loads em one by one and it will pause on a busted one almost every time.
But if the way this works is true then either something is not in a proper order, or one is loading quicker than the other but loading at the same time.
Just asking for knowledge sake =). Will probably come in handy for more advanced and future linux use.
Comment by Geilt — February 13, 2007 @ 8:09 pm
Dave on February 13, 2007 at 8:17 pm said:
Although I wonder why there is no priority to what loads up first?
See the bug report in comment 2.
Comment by Dave — February 13, 2007 @ 8:17 pm
There is an order imposed on Linux (in fact, all brands of UNIX) system startup. The full explanation is rather long, soI will summarise it here:
under /etc/init.d you will find a series of shell scripts. These are the systems startup/shutdown scripts for each Linux component (that warrants such approach).
Now, under /etc/rc[0-6].d you will find a series of soft links into the /etc/init.d. These soft links are named S, where varies between 00 and 99, and usually refers to the linked file under /etc/init.d. The meaning of the rc.d are as follows:
/etc/rc0.d — scripts to be used to shutdown the box
/etc/rc1.d — scripts to be used to bring the box into single user mode (usually for system recovery)
/etc/rc[2-5].d — scripts used to bring the box into the desired multi-user level. The default for a normal startup is rc2.d
/etc/rc6.d — scripts to be used to reboot the box.
Additionally, /etc/rc.local will always be executed after all rc[2-5] startup scripts are executed.
For each of these directories (except rc.local, which is a file, not a directory), the names *must* start with a S (uppercase letter ‘S’) — to start — or a K (uppercase letter ‘K’) — to stop –. After the initial letter the two-digit number defines the relative priority, startying at 00 as the highest and going down to 99 as the lowest.
This is why we see this issue: gdm — the gnome display manager — is stated before dbus, and your gnome session depends on dbus.
Comment by hggdh — February 13, 2007 @ 10:03 pm
this bug ‘failed to initialize hal’ is now getting into my blood system, logging me off 20 times isnt nice.i dont have autologin and i always give dbus time to load, i cant understand why is this bug stil sticking around. most of the time it happen when i open firefox(v2.0.0.1) or gaim(v2.0.0beta3.1). here is the log: $tail -f /var/log/messages
Feb 21 23:26:06 unknown007 gconfd (root-4994): starting (version 2.16.0), pid 4994 user ‘root’
Feb 21 23:26:06 unknown007 gconfd (root-4994): Resolved address “xml:readonly:/etc/gconf/gconf.xml.mandatory” to a read-only configuration source at position 0
Feb 21 23:26:06 unknown007 gconfd (root-4994): Resolved address “xml:readwrite:/root/.gconf” to a writable configuration source at position 1
Feb 21 23:26:06 unknown007 gconfd (root-4994): Resolved address “xml:readonly:/etc/gconf/gconf.xml.defaults” to a read-only configuration source at position 2
Feb 21 23:26:06 unknown007 gconfd (root-4994): Resolved address “xml:readonly:/var/lib/gconf/debian.defaults” to a read-only configuration source at position 3
Feb 21 23:26:06 unknown007 gconfd (root-4994): Resolved address “xml:readonly:/var/lib/gconf/defaults” to a read-only configuration source at position 4
Feb 21 23:27:36 unknown007 gconfd (root-4994): GConf server is not in use, shutting down.
Feb 21 23:27:36 unknown007 gconfd (root-4994): Exiting
Feb 21 23:28:29 unknown007 gnome-power-manager: (oli) Critical error: This program cannot start until you start the dbus system service. It is strongly recommended you reboot your computer after starting this service.
Feb 21 23:28:29 unknown007 gnome-power-manager: (oli) Critical error: This program cannot start until you start the dbus system service. It is strongly recommended you reboot your computer after starting this service.
========
Feb 22 23:50:42 unknown007 gconfd (oli-4706): Exiting
Feb 22 23:50:48 unknown007 gconfd (oli-6598): starting (version 2.16.0), pid 6598 user ‘oli’
Feb 22 23:50:48 unknown007 gconfd (oli-6598): Resolved address “xml:readonly:/etc/gconf/gconf.xml.mandatory” to a read-only configuration source at position 0
Feb 22 23:50:48 unknown007 gconfd (oli-6598): Resolved address “xml:readwrite:/home/oli/.gconf” to a writable configuration source at position 1
Feb 22 23:50:48 unknown007 gconfd (oli-6598): Resolved address “xml:readonly:/etc/gconf/gconf.xml.defaults” to a read-only configuration source at position 2
Feb 22 23:50:48 unknown007 gconfd (oli-6598): Resolved address “xml:readonly:/var/lib/gconf/debian.defaults” to a read-only configuration source at position 3
Feb 22 23:50:48 unknown007 gconfd (oli-6598): Resolved address “xml:readonly:/var/lib/gconf/defaults” to a read-only configuration source at position 4
Feb 22 23:50:50 unknown007 gconfd (oli-6598): Resolved address “xml:readwrite:/home/oli/.gconf” to a writable configuration source at position 0
Feb 22 23:50:51 unknown007 dhcdbd: Shut down.
Feb 22 23:58:34 unknown007 gnome-power-manager: (oli) Critical error: This program cannot start until you start the dbus system service. It is strongly recommended you reboot your computer after starting this service.
Comment by oliver — February 23, 2007 @ 5:44 am
How do you make the Autologin have a 5 second Delay before automatically logging in?
Comment by tenka — April 19, 2007 @ 6:37 am
You do not. There is no such option, unless you go and hack in.
The best option is to change the startup priority of dbus, so that it will start before gdm/kdm/whateverdm. On Feisty this has been done, but I do not know if it (will be|has been) backported to Edgy. This is a rather simple change.
Comment by hggdh — April 19, 2007 @ 5:47 pm
>> “How do you make the Autologin have a 5 second Delay before automatically logging in?”
> “You do not. There is no such option, unless you go and hack in.”
Sure there is! System > Administration > Login (or sudo gdmsetup) > Security > Timed Login. I use a 15 second delay.
(Or perhaps instead hggdh could actually explain which files need changing to change the startup priority as they suggest? Because I would only be guessing.)
Comment by Dave — April 19, 2007 @ 6:10 pm
I stand corrected :-)
On my defence, I have never used autologins because of the huge security risk (since I float around different customers, having my laptop autologin is an invitation to be had; YMMV).
Anyway, delaying autologin is not a solution, but a bypass.
For full resolution, change /etc/rc[2345].d/S20dbus to /etc/rc[2345].d/S12dbus (this is how it is on Feisty; I do not use Edgy):
sudo mv /etc/rc2.d/S20dbus /etc/rc2.d/S12dbus
sudo mv /etc/rc3.d/S20dbus /etc/rc3.d/S12dbus
sudo mv /etc/rc4.d/S20dbus /etc/rc4.d/S12dbus
sudo mv /etc/rc5.d/S20dbus /etc/rc5.d/S12dbus
What will happen: it will take slightly longer for the autologin to complete, but you will not have this issue anymore.
In fact, the time needed to initialise dbus will vary depending on your hardware. It can be as low as some few seconds, and as high as some tens of seconds. In my case, due to another issue (apparently resolved by HAL 0.5.9) it takes about 30 seconds for my LVM partitions to be available.
Comment by hggdh — April 19, 2007 @ 6:36 pm
Another fix at blog.ubrio.us:
udev address already in use
Comment by tabrez — July 26, 2007 @ 1:11 pm
If you want to debug:
sudo hald –daemon=no –verbose=yes
My HAL wouldn’t start after upgrading to 6.10 because a file was in the wrong place:
cd /var/cache/hald
sudo mv fdi-cache~ fdi-cache
Comment by Matthew Painter — October 26, 2007 @ 6:34 pm
thanks for the info. Needed to boot windows xp first on a dual boot machine with a very inexperienced user that couldn’t handle the boot screen. Made a change from default 0 to default 8, xp being the 8th line on the list, using sudo gedit /boot/grub/menu.lst This moved the highlighted selection bar to xp to boot first. Then upon rebooting and selecting ubuntu the hal problem appeared. Using your time delay suggestion worked thank you
Comment by gene kemp — April 8, 2008 @ 6:00 am
[...] megoldás innen származik. Köszönet érte. Ha tetszett, oszd meg ezt a bejegyzést [...]
Pingback by HAL | Garrotter blogja — November 15, 2008 @ 5:45 pm
