[gentoo-user] Another Jacked up mess on update - hal daemon

[gentoo-user] Another Jacked up mess on update - hal daemon

[Harry Putnam]

Once again I find myself with a big mess following an update world.
This time I was probably out of date by more than 1 mnth, probably
less than 2.

On first reboot the bootup proceeds well into level 3, right up to
starting hal daemon.

There is sets.... forever.

Since its past the point where sshd is started I can ssh into the
machine. 

I thought to maybe stop hald then attempt a restart.  It appears
halting hald did allow the boot to continue, but it will not start.

Consequently I have no mouse or keyboard at the login prompt.

But I can ssh into the box.  

What should I supply here to allow someone to help diagnose the
problem?

Recent info on hal from `qlop --list|grep hal'

Sun Feb 15 10:52:16 2009 >>> app-misc/hal-info-20090202
Sun Feb 15 10:54:45 2009 >>> sys-apps/hal-0.5.11-r8
Fri Apr  3 09:23:58 2009 >>> sys-apps/hal-0.5.12_rc1
Fri Apr  3 09:24:12 2009 >>> app-misc/hal-info-20090330

Running  2.6.28-r1 kernel for currently.

I wasn't sure what to look for in in dmesg but saw nothing that
appeared related.

There was trouble during the update with glibc.

When I added --skip-first --keep-going to the command line:

  emerge -vuD --skip-first --keep-going world

Then the update completed.

I actually didn't really intend to reboot when I did, I was working on
a different machine and forgot I'd just completed an update so
shutdown by ssh from a remote when I quit for the day.  I do know the
update had finished since I did look in on it from time to time.

On next boot, the problem with hal daemon reported above started.

Re: [gentoo-user] Another Jacked up mess on update - hal daemon

[Dale]

Harry Putnam wrote:
> Once again I find myself with a big mess following an update world.
> This time I was probably out of date by more than 1 mnth, probably
> less than 2.
>
> On first reboot the bootup proceeds well into level 3, right up to
> starting hal daemon.
>
> There is sets.... forever.
>
> Since its past the point where sshd is started I can ssh into the
> machine. 
>
> I thought to maybe stop hald then attempt a restart.  It appears
> halting hald did allow the boot to continue, but it will not start.
>
>
>   

Since you can ssh into the system, could you remove hald from the
default runlevel and reboot?  I'm not sure about the keyboard and mouse
after that tho.  At least maybe you can get to a console.

Did you run etc-update, or whatever config update tool you prefer, after
the updates?  You may also want to emerge the old version of hal and try
that.  Since you can get in, that may help.  Of course, if it was me,
I'd mask that version and skip that one in the future.  O_O  Maybe the
next version will work better.

Hope that helps, a little anyway.

Dale

:-)  :-) 

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Harry Putnam]

Dale <rdalek1967@gmail.com> writes:

> Since you can ssh into the system, could you remove hald from the
> default runlevel and reboot?  I'm not sure about the keyboard and mouse
> after that tho.  At least maybe you can get to a console.

As reported in OP, I sshed in and stopped the start of hald.. that
allowed boot to continue to login prompt but no mouse and keyboard.

So a login shell won't be useful for now.

> Did you run etc-update, or whatever config update tool you prefer, after
> the updates?  You may also want to emerge the old version of hal and try
> that.  Since you can get in, that may help.  Of course, if it was me,
> I'd mask that version and skip that one in the future.  O_O  Maybe the
> next version will work better.


No I didn't do the update... As reported in OP, I actually wasn't done
with the follup chores to an update, and shutdown from a remote due to
absentminded pea brainedness.

I'm doing that now via ssh.  Maybe things will improve...

Re: [gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Dale]

Harry Putnam wrote:
> No I didn't do the update... As reported in OP, I actually wasn't done
> with the follup chores to an update, and shutdown from a remote due to
> absentminded pea brainedness.
>
> I'm doing that now via ssh.  Maybe things will improve...
>
>
>   

Well, if you will cross your fingers that I can get my car fixed, I'll
cross mine for your puter.  Deal?

Let's hope we both have some good luck.

Dale

:-)  :-) 

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Harry Putnam]

Dale <rdalek1967@gmail.com> writes:

> Harry Putnam wrote:
>> No I didn't do the update... As reported in OP, I actually wasn't done
>> with the follup chores to an update, and shutdown from a remote due to
>> absentminded pea brainedness.
>>
>> I'm doing that now via ssh.  Maybe things will improve...
>>
>>
>>   
>
> Well, if you will cross your fingers that I can get my car fixed, I'll
> cross mine for your puter.  Deal?
>
> Let's hope we both have some good luck.

Too late... hehe... already flaked out some other baloney (glibc) not
installing..

Re: [gentoo-user] Another Jacked up mess on update - hal daemon

[Volker Armin Hemmann]

On Sunday 05 April 2009, Harry Putnam wrote:
> Once again I find myself with a big mess following an update world.
> This time I was probably out of date by more than 1 mnth, probably
> less than 2.
>
> On first reboot the bootup proceeds well into level 3, right up to
> starting hal daemon.
>
> There is sets.... forever.
>
> Since its past the point where sshd is started I can ssh into the
> machine.
>
> I thought to maybe stop hald then attempt a restart.  It appears
> halting hald did allow the boot to continue, but it will not start.
>
> Consequently I have no mouse or keyboard at the login prompt.
>
> But I can ssh into the box.
>
> What should I supply here to allow someone to help diagnose the
> problem?
>
> Recent info on hal from `qlop --list|grep hal'
>
> Sun Feb 15 10:52:16 2009 >>> app-misc/hal-info-20090202
> Sun Feb 15 10:54:45 2009 >>> sys-apps/hal-0.5.11-r8
> Fri Apr  3 09:23:58 2009 >>> sys-apps/hal-0.5.12_rc1
> Fri Apr  3 09:24:12 2009 >>> app-misc/hal-info-20090330
>
> Running  2.6.28-r1 kernel for currently.
>
> I wasn't sure what to look for in in dmesg but saw nothing that
> appeared related.
>
> There was trouble during the update with glibc.
>
> When I added --skip-first --keep-going to the command line:
>
>   emerge -vuD --skip-first --keep-going world
>
> Then the update completed.
>
> I actually didn't really intend to reboot when I did, I was working on
> a different machine and forgot I'd just completed an update so
> shutdown by ssh from a remote when I quit for the day.  I do know the
> update had finished since I did look in on it from time to time.
>
> On next boot, the problem with hal daemon reported above started.

and you did etc-update/cfg-update after the update? Have you read the messages 
with elogv? Same hal versions here - no problems at all.

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Harry Putnam]

Volker Armin Hemmann <volkerarmin@googlemail.com> writes:

>>
>> On next boot, the problem with hal daemon reported above started.
>
> and you did etc-update/cfg-update after the update? Have you read the messages 
> with elogv? Same hal versions here - no problems at all.

I've completed the cfg-update -u and there was only one file really
changed.  sshd_config which I left alone.


However I did remember to make sure the package I had trouble with
`glibc' did get installed.  It did not and will not.

Ending with this stuff below... I'm not at all sure what to make of
it.
Is it related to hal daemon problem?
emerge -vuD glibc
 [...]
   usr/lib/libc_nonshared.a
>>> Completed installing glibc-2.9_p20081201-r2 into /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image/

--------------------------- ACCESS VIOLATION SUMMARY ---------------------------
LOG FILE "/var/log/sandbox/sandbox-15179.log"

VERSION 1.0
FORMAT: F - Function called
FORMAT: S - Access Status
FORMAT: P - Path as passed to function
FORMAT: A - Absolute Path (not canonical)
FORMAT: R - Canonical Path
FORMAT: C - Command Line

F: open_wr
S: deny
P: /etc/ld.so.cache~
A: /etc/ld.so.cache~
R: /etc/ld.so.cache~
C: /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/work/build-default-i686-pc-linux-gnu-nptl/elf/ldconfig -r /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image  /lib /usr/lib 
--------------------------------------------------------------------------------

>>> Failed to emerge sys-libs/glibc-2.9_p20081201-r2, Log file:

>>>  '/var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/temp/build.log'

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Harry Putnam wrote:
> Volker Armin Hemmann <volkerarmin@googlemail.com> writes:
> 
>>> On next boot, the problem with hal daemon reported above started.
>> and you did etc-update/cfg-update after the update? Have you read the messages 
>> with elogv? Same hal versions here - no problems at all.
> 
> I've completed the cfg-update -u and there was only one file really
> changed.  sshd_config which I left alone.
> 
> 
> However I did remember to make sure the package I had trouble with
> `glibc' did get installed.  It did not and will not.
> 
> Ending with this stuff below... I'm not at all sure what to make of
> it.
> Is it related to hal daemon problem?
> emerge -vuD glibc
>  [...]
>    usr/lib/libc_nonshared.a
>>>> Completed installing glibc-2.9_p20081201-r2 into /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image/
> 
[snip sandbox error]

That actually is completely separate, and is due to a bad version of
sandbox (if I'm not mistaken) - you probably need to either upgrade or
downgrade sys-apps/sandbox to 1.6-r2 (1.7 appears to be broken in this
regard). If I'm right, then this probably is bug 264399.

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknYNroACgkQOypDUo0oQOo2uQCgmpl2YRJbKnDr7TghvcFt5Gu5
WNUAoMUctbHHxr/3LDggyqQhi4D1URJZ
=IZpq
-----END PGP SIGNATURE-----

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Harry Putnam]

ABCD <en.ABCD@gmail.com> writes:

>> Is it related to hal daemon problem?
>> emerge -vuD glibc
>>  [...]
>>    usr/lib/libc_nonshared.a
>>>>> Completed installing glibc-2.9_p20081201-r2 into /var/tmp/portage/sys-libs/glibc-2.9_p20081201-r2/image/
>> 
> [snip sandbox error]
>
> That actually is completely separate, and is due to a bad version of
> sandbox (if I'm not mistaken) - you probably need to either upgrade or
> downgrade sys-apps/sandbox to 1.6-r2 (1.7 appears to be broken in this
> regard). If I'm right, then this probably is bug 264399.

Thanks for the tip.. I'm  now running a downgrade of both sandbox and hal
from latest to immediately prior versions:

  sandbox-7.1    => sandbox-1.6-r1
  hal-0.5.12_rc1 => hal-0.5.11-r8

Then I'll see if glibc will compile AND hal troubles go away.
=====     *     =====     *     =====     *     =====
 
.. Soon as the downgrading finished, I restarted hald and YIPPEE hal
started up and my console login has a keyboard now.

There was a suggestion that I remove the `input' section of xorg.conf
and migrate it to some kind of file under:
   /etc/hal/fdi/

From emerge of hal
[...] 
 * X Input Hotplugging (if you build xorg-server with the HAL useflag)
 * reads user specific configuration from /etc/hal/fdi/policy/.

 * You should remove the Input sections from your xorg.conf once you have
 * migrated the rules to a HAL fdi file.


Anyone here that has done that, who can offer some guidance?

What filenames .. what format, for example.

I guess I'll be chicken of ~86 on hal and sandbox for now.

.... Haa... glibc installed without a hitch.

  off and running.... thanks

[gentoo-user] Re: Another Jacked up mess on update - hal daemon

[Harry Putnam]

Harry Putnam <reader@newsguy.com> writes:

> But I can ssh into the box.  
>
> What should I supply here to allow someone to help diagnose the
> problem?
>
> Recent info on hal from `qlop --list|grep hal'
>
> Sun Feb 15 10:52:16 2009 >>> app-misc/hal-info-20090202
> Sun Feb 15 10:54:45 2009 >>> sys-apps/hal-0.5.11-r8
> Fri Apr  3 09:23:58 2009 >>> sys-apps/hal-0.5.12_rc1
> Fri Apr  3 09:24:12 2009 >>> app-misc/hal-info-20090330

I found this in the syslog:
Apr  4 18:26:22 reader /etc/init.d/hald[1448]: status: starting
Apr  4 18:26:30 reader /etc/init.d/hald[1332]: WARNING: hald not 
      under our control, aborting

Not very helpful but its all I found about hal.