subhurds

Hello! Are subhurds meant to be bootable by ordinary mortals? Trying this currently looks like this: #v+ $ boot -D subhurd subhurd/boot/script.boot subhurd.ext2fs boot: /hurd/ext2fs.static: mach_port_insert_right: (os/kern) invalid value

[bug #17319] /hurd/crash --suspend doesn't work

URL: Summary: /hurd/crash --suspend doesn't work Project: The GNU Hurd Submitted by: tschwinge Submitted on: Friday 08/04/06 at 16:14 Category: Hurd Servers

Re: subhurds

At Fri, 4 Aug 2006 16:01:20 +0200, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > > [1 ] > [1.1 ] > Hello! > > Are subhurds meant to be bootable by ordinary mortals? Trying this > currently looks like this: As far as I remember there was some support for subhurds run by a non-privileged user, b

Re: subhurds

Yeah, what Marcus said. It should work. I vaguely recall there being some strange complexities in doing it, like proc not having the host-priv port. If you investigate the failure, we'll remember what the issues are. ___ Bug-hurd mailing list Bug-hurd

Re: [bug #17319] /hurd/crash --suspend doesn't work

Make sure it's not just a bug in the option parsing or something. Check with fsysopts /servers/crash. I note that its trivfs_append_args doesn't show the --orphan-action setting. You might fix that. Try fsysopts --orphan-action=suspend and see if that changes the behavior. If it does, then the

ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed

Hi, I've met this bug again (it was reported almost 7 years ago in debian bts as #46859 and periodically noticed again), and a quick look at the code upsets me: assert (! __spin_lock_locked (&ss->critical_section_lock)); __spin_lock (&ss->critical_section_lock); Why should one check that a s

Re: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed

Samuel Thibault, le Sat 05 Aug 2006 02:27:35 +0200, a écrit : > assert (! __spin_lock_locked (&ss->critical_section_lock)); > __spin_lock (&ss->critical_section_lock); > > Why should one check that a spinlock is free before taking it?? Here the > purpose is to cancel _another_ thread, so it _c

[bug #17319] /hurd/crash --suspend doesn't work

Follow-up Comment #1, bug #17319 (project hurd): Roland commented on bug-hurd: Make sure it's not just a bug in the option parsing or something. Check with fsysopts /servers/crash. I note that its trivfs_append_args doesn't show the --orphan-action setting. You might fix that. Try fsysopts -