Bug #1706

sysutils/hal doesnt work on master/i386

Added by elekktretterr about 3 years ago. Updated about 3 years ago.

Status:Closed Start date:
Priority:Normal Due date:
Assignee:- % Done:

0%
Category:-
Target version:-

Description

Hi all,

I've started devd and dbus and the daemons are running. Then I moved to
enable hal. It compiles fine but everytime I try to start hald. I see the
following events before the hald daemon exits _without_ an error in
stderr.

im executing hald --verbose=yes and the last message on the console is
"becoming a daemon" but when I check ps, hal is definately not running.

Then I check dmesg and I see the following text:

md7: Malloc disk
dscheck(acd0): b_bcount 3072 is not on sector boundary (ssize 2048)

Couple of things to note: 1) everytime hald is run, the system creates a
new md device (md0, md1, md2, md3 etc etc)

2) The dscheck message appears many times and the b_bcount number is
different every time, but sometimes it repeats.

Whats the next procedure I should do to get this thing working?

Thanks,
Petr

Related todos

History

#1
Updated by ahuete.devel about 3 years ago

Hi Petr,

That's kinda a hack on the md(4) code. The latest md device will spawn
a new one on every open(2) call. Thus, an open() on md0 will spawn
md1, open() on md1 will spawn md2 etc...

I guess hald is issuing an open on every device, including the latest
md. So you could just disable it from the kernel config file and
recompile as a workaround.

Cheers,
Antonio Huete

#2
Updated by elekktretterr about 3 years ago

> Hi Petr,
>
> That's kinda a hack on the md(4) code. The latest md device will spawn
> a new one on every open(2) call. Thus, an open() on md0 will spawn
> md1, open() on md1 will spawn md2 etc...
>
> I guess hald is issuing an open on every device, including the latest
> md. So you could just disable it from the kernel config file and
> recompile as a workaround.

Hi Antonio and all,

Ive managed to get more debug info:

hald_dbus.c5845: dbus_bus_request_name(); Connection ":1.11" is not
allowed to owne the service "org.freedesktop.Hal" due to security policies
in the configuration file.

Any idead which configuration file that is and what has to be changed?

Petr

#3
Updated by elekktretterr about 3 years ago

Something a little bizzare happened. I restarted dbus and then hal
connected normally. Im positive dbus has always been running.

Petr

#4
Updated by alexh about 3 years ago

Please search the issue database first:
http://bugs.dragonflybsd.org/issue1477

Cheers,
Alex Hornung

#5
Updated by alexh about 3 years ago

as previously indicated, issue1477 already covers this.

Also available in: Atom PDF