Installer and boot issues with new launch daemon

[vidrep]

Installed hrev49431 x86_gcc2 anyboot image from a CD rom. Everything progressed normally until prompted to reboot. Instead of rebooting, the CD was ejected and the system shut down. After doing a cold boot, the desktop appears, but there is no network configuration nor generation of keys. It appears some other services are also not starting.

[vidrep]

After getting the network sorted out, I attached the syslogs from the install and first boot. The network status and process controller in the Deskbar are not being initialized (screenshot1).

[waddlesplash]

Apologies about all the issues. It's frustrating for all of us, but you appear to be hitting a lot more issues than we regularly do :(

[vidrep]

I did another re-install from CD to see if the same issues are replicated. They are. Screenshot2 shows the running processes on first boot. I have also attached the second set of syslogs from the second install and first boot.

[vidrep]

I hope this report helps when you're troubleshooting your new launch daemon ;)

[axeld]

1) Rene added the net_server back in hrev49429 1) I've fixed the Installer to reboot instead of shutdown in hrev49432

Still with us is the missing invocation of the post install script. I may be able to look into this later today. vidrep: thanks for testing out the bleeding edge versions of Haiku -- if you're already frustrated, though, then you should really just stick to a version that works :-)

[axeld]

BTW I noticed that the ProcessController was missing, but I tested the revision before my changes, and that didn't include it either, so I did not investigate before. Maybe I mixed something up, if that was really still the expected outcome.

[pulkomandy]

The script to add deskbar replicants is at ​http://cgit.haiku-os.org/haiku/tree/data/system/boot/post_install/default_deskbar_items.sh, and ​http://cgit.haiku-os.org/haiku/tree/data/system/boot/PostInstallScript should execute it. This is possibly something the Launch Daemon should take care of, now?

[axeld]

There was no PostInstallScript before the launch_daemon; it was done by the Bootscript before. So yes, I thought I implemented that for the launch_daemon. I'll look into it.

[vidrep]

Replying to axeld:

vidrep: thanks for testing out the bleeding edge versions of Haiku -- if you're already frustrated, though, then you should really just stick to a version that works :-)

That would be BeOS R5 :D

[axeld]

For real? I've been using Haiku relatively often the past 8 months, and I did not have a *single* crash, or anything broken. Of course, I usually let some time past before I update; I haven't yet updated to a netresolv revision yet, for example (just running from a few revisions before that).

[vidrep]

Replying to axeld:

For real? I've been using Haiku relatively often the past 8 months, and I did not have a *single* crash, or anything broken. Of course, I usually let some time past before I update; I haven't yet updated to a netresolv revision yet, for example (just running from a few revisions before that).

Yes, for real. OK, Alpha 4.1 isn't too bad. In fact, it's the only version of Haiku that has a permanent home on my hard drive. The nightly builds get updated every couple of days solely for bug testing purposes since something is always broken, and these are, after all, "test builds", not public releases, right? I'm frustrated, not angry. I'm not going to create a "Haikuos Sucks" blog, troll the IRC channel, nor post rants in the forum or anything like that. If you want to know exactly what my frustration with Haiku is about, I'll send you an email instead. Would you like it served up straight or with sarcasm? Thanks Axel.

[waddlesplash]

I'm frustrated, not angry. ... If you want to know exactly what my frustration with Haiku is about, I'll send you an email instead.

I probably can guess what half of the frustration is, but I'd like a copy (as well), please. My email is <username>@gmail.com.

[diver]

It seems that ​http://cgit.haiku-os.org/haiku/tree/data/launch/user is not included in the current images

[axeld]

It must be in ~/config/data/launch. Otherwise, your system couldn't boot, and you'd stare into a blue nothingness.

[axeld]

Ah, let'em coming vidrep, and I don't mind sarcasm at all ;-)

[waddlesplash]

It must be in ~/config/data/launch. Otherwise, your system couldn't boot, and you'd stare into a blue nothingness.

That's exactly what's happening to me and Diver -- we're staring into blue nothingness. The only way we've found to get out of that is to hit Ctrl+Alt+Del and click "Restart desktop".

[axeld]

Ah, I found the cause: since we do not have any user packages yet, I went the fast route, and put the built-in "user" configuration into non-packaged. And that only ends up on a freshly built image, not with an update. For now, please copy the file manually to ~/config/non-packaged/data/launch/. Sorry for the inconvenience; I completely forgot about the matter. I'll have to rethink how do that instead.

[axeld]

So, the blue nothingness is gone, you can update again. Please remove the "user" file from non-packaged/data/launch if you put it there.

[Barrett]

I realized that there's a regression after the launch daemon merge, when i restart the media_server using Media preferences for some reason the media_addon_server isn't properly shut down and results into two instances running. The strange thing is that after this operation i have also two instances of the launch_daemon started.

[vidrep]

Replying to Barrett:

I realized that there's a regression after the launch daemon merge, when i restart the media_server using Media preferences for some reason the media_addon_server isn't properly shut down and results into two instances running. The strange thing is that after this operation i have also two instances of the launch_daemon started.

I wonder if this is the cause of the shutdown sequence hanging (see ticket #12230).

[axeld]

The last part has been fixed in hrev49447.

@Barrett: On a fully booted system, you always have two instances of the launch_daemon running. One for the system, one for the logged in user. Furthermore, the media server is just a plain old "legacy" server, which means it's just being started in the same way as before. The only difference is that its pre-registration is omitted, but I doubt that this can have any such consequences.

If the launch_daemon would be responsible for media_server already, applications wouldn't even notice it being gone anymore, as its port stays valid without it.

[Barrett]

I'm pretty sure all worked well as i had the server notifications patches applied for months until some weeks ago. It seems kill_team is failing to kill the media_addon_server, but also i didn't change anything that can be related to this problem.