Cannot stat /etc/rc0.d//K00fuse on shutdown

[pauld]

Hi, I am new to TinyMe, or at least I don't remember having tried it before. I tested 2010 Acorn rc1b (from memory).

Each time I shutdown, I get:
---
Kernel 2.6.31.12-unity2.ghc on an i686 /tty1
localhost login: Starting HAL daemon: ... [FAILED]
Cannot stat /etc/rc0.d//K00fuse
---
Strangely, it is written Starting, but I am shutting down.
After that, I have to shutdown by holding power button.

I have tested the CD with the menu 'Test this medium' or something like that, and it passed.

This is after a fresh install.

[KDulcimer]

What you're seeing is what is stored in the screen buffer from when the system started up.

This HAL error message can be safely ignored.

[pauld]

(04-09-2010 05:46 PM)KDulcimer Wrote:  What you're seeing is what is stored in the screen buffer from when the system started up.

This HAL error message can be safely ignored.

Yes, for the HAL part, but what about the:
"Cannot stat /etc/rc0.d//K00fuse" part?

It looks like to me init is hanging on the first program to switch from normal runlevel to go to shutdown runlevel, probably because of the // part of the path.

I find this abnormal, because rather then stopping all programs, it seems to hang there. And so, I have to badly stop the computer by holding power down button.

[KDulcimer]

I don't think the double slash is the issue-- I'm pretty sure Linux will ignore a double slash and treat it like a single slash.

Having to hold in the power button could be due to many issues. I suspect it's an artifact of running it from RAM. It could also be that TinyMe has a slight issue with your BIOS.

[pauld]

Hi, I am on the computer with the problem right now.
I found that the symbolic link is broken, that is there is a symbolic link named:
/etc/rc.d/rc0.d/K00fuse but it points to etc/rc.d/init.d/fuse but this file does not exist.
Other symbolic links in /etc/rc.d/rc0.d are fine.

This is fuse 2.8.2-1@586

[gettinther]

This mean at one stage fuse was installed and then removed from the system. Also the current trend with daemons is to remove them from the rc.d process and process them outside. This might be the problem with it (I've seen it happen with a few packages already).

In any case if the link is dead, then it's safe to remove it.

Finally if your system fails to halt, try starting with various cheatcodes (like noapic, nolapic, noacpi). Generally this is sufficient to fix the shut down issue and points to an incompatibility with some module of the kernel.

[pauld]

(04-09-2010 10:05 PM)gettinther Wrote:  This mean at one stage fuse was installed and then removed from the system. Also the current trend with daemons is to remove them from the rc.d process and process them outside. This might be the problem with it (I've seen it happen with a few packages already).

In any case if the link is dead, then it's safe to remove it.

Finally if your system fails to halt, try starting with various cheatcodes (like noapic, nolapic, noacpi). Generally this is sufficient to fix the shut down issue and points to an incompatibility with some module of the kernel.

What you say seems to suggest that fuse would have been removed when the symlink was broken, but it was not the case, it was installed and I did give the version in a previous comment. Anyway, I finally removed it, only ntfs3g was using it, all others (many many packages) seems to depend on libfuse2 directly.

Also, I check the LiveCD versus installed system, with Unity RC 2010 and TinyMe RC 1, and with both, the LiveCD shutdown very well, showing all process stopping and asking to remove CD before shutting down, but once installed, both hang pretty at the beginning of the process of shutting down. For TinyMe this is just after telling that it is Sending TERM signal to all process.

Also, although #halt breaks while sending TERM signal, #halt -f -p does shutdown well ( f = force -p=powerdown).

Edit: It´s funny because if I make a LiveCD from a system that does not shutdown correctly, the LiveCD is shutting down fine.