Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12227 closed bug (fixed)

Installer and boot issues with new launch daemon

Reported by: vidrep Owned by: axeld
Priority: blocker Milestone: R1/beta1
Component: Servers/launch_daemon Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Attachments (6)

screenshot1.png (19.6 KB ) - added by vidrep 4 years ago.
previous_syslog (129.4 KB ) - added by vidrep 4 years ago.
syslog (287.4 KB ) - added by vidrep 4 years ago.
screenshot2.png (60.0 KB ) - added by vidrep 4 years ago.
previous_syslog.2 (128.4 KB ) - added by vidrep 4 years ago.
syslog.2 (286.0 KB ) - added by vidrep 4 years ago.

Download all attachments as: .zip

Change History (29)

by vidrep, 4 years ago

Attachment: screenshot1.png added

by vidrep, 4 years ago

Attachment: previous_syslog added

by vidrep, 4 years ago

Attachment: syslog added

comment:1 by vidrep, 4 years ago

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).

comment:2 by waddlesplash, 4 years ago

Component: System/Boot LoaderServers/launch_daemon
Milestone: UnscheduledR1/beta1
Priority: normalblocker

comment:3 by waddlesplash, 4 years ago

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 :(

comment:4 by vidrep, 4 years ago

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.

by vidrep, 4 years ago

Attachment: screenshot2.png added

by vidrep, 4 years ago

Attachment: previous_syslog.2 added

by vidrep, 4 years ago

Attachment: syslog.2 added

comment:5 by vidrep, 4 years ago

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

comment:6 by axeld, 4 years ago

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 :-)

comment:7 by axeld, 4 years ago

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.

comment:8 by pulkomandy, 4 years ago

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?

comment:9 by axeld, 4 years ago

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.

in reply to:  6 comment:10 by vidrep, 4 years ago

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

comment:11 by axeld, 4 years ago

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).

in reply to:  11 comment:12 by vidrep, 4 years ago

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.

comment:13 by waddlesplash, 4 years ago

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.

comment:14 by diver, 4 years ago

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

comment:15 by axeld, 4 years ago

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

comment:16 by axeld, 4 years ago

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

comment:17 by waddlesplash, 4 years ago

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".

comment:18 by axeld, 4 years ago

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.

comment:19 by axeld, 4 years ago

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.

comment:20 by Barrett, 4 years ago

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.

in reply to:  20 comment:21 by vidrep, 4 years ago

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).

comment:22 by axeld, 4 years ago

Resolution: fixed
Status: newclosed

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.

comment:23 by Barrett, 4 years ago

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.

Note: See TracTickets for help on using tickets.