Hal into a chroot.

Raúl Sánchez Siles rasasi78 at gmail.com
Sun Oct 12 12:40:08 PDT 2008


  Hello All:

> Raúl Sánchez Siles wrote:
> 
>>   Hello All:
>> 
>>   I'm running a chroot (Debian sid/experimental) inside a Debian sid
>>   system.
>> The main purpose in having this chroot is being able to test KDE4. This
>> is working mostly well. But there's one thing I've been unable to get
>> working so far and this is having hal running into the chroot.
>> 
>>   The Debian hal init script aborts its start alleging that won't run
>>   into a
>> chroot. I suppose there is a good reason for not running the service in
>> that situation, but I haven't been able to get an answer yet.
>> 
>>   My aim is having hal running into the chroot, so I'll need some advice.
>> I'd appreciate if someone could hint me why hal does not/cannot/will not
>> run into a chroot.
>> 
>>   If it is possible having it run into the chroot at all, I'd also
>> appreciate some points as to get it working like that.
>> 

  To sort of close this thread I have a solution now. As I said, Debian hal
init script wisely doesn't start the daemon into a chroot, if you try to
force this operation this is what will happen:

hald --daemon=no --verbose=yes
11:43:06.231 [I] hald.c:669: hal 0.5.11
11:43:06.231 [I] hald.c:734: Will not daemonize
11:43:06.232 [I] hald_dbus.c:5381: local server is listening at
unix:abstract=/var/run/hald/dbus-F7K2wmG4is,guid=0ad2ca243f9c7f9284ce91e748f0752a
11:43:06.313 [I] hald_runner.c:301: Runner has pid 6939
Runner started - allowed paths
are '/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin'
11:43:06.316 [I] hald_runner.c:182: runner connection is 0x19a3380
11:43:06.316 [W] osspec.c:373: Unable to open /proc/mdstat: No such file or
directory
11:43:06.680 [I] mmap_cache.c:265: Cache needs update
11:43:06.680 [I] mmap_cache.c:126: Regenerating fdi cache..
Run started hald-generate-fdi-cache (60000) (0)
!  full path is '/usr/lib/hal/hald-generate-fdi-cache', program_dir
is '/usr/lib/hal'
pid 6940: rc=0 signaled=0: /usr/lib/hal/hald-generate-fdi-cache
11:43:08.161 [I] mmap_cache.c:104: In regen_cache_cb exit_type=0,
return_code=0
11:43:08.162 [I] mmap_cache.c:156: fdi cache generation done
11:43:08.162 [I] mmap_cache.c:274: cache mtime is 1223591753
Error binding udev_event socket: Address already in use

  I suppose the socket is already used by the real system (the first)
daemon. I don't know if there's a way to workaround or solve this, but I
doubt the collaboration with KDE4 would work in that case seamlessly.

  In any case, I doubt it is easy handling running hal daemon twice on the
same system.

  I ended up bind mounting into the chroot the /var/run/dbus dir, and then
the chroot system could connect to real system dbus daemon which in turn
has access to real system hal.

  HTH, regards,

-- 
     Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098



More information about the hal mailing list