[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Weekly report (4th week) - Debian GNU/Hurd Debianish initialization



On 07/13/2013 08:14 AM, Charlie Derr wrote:
On 07/13/2013 02:57 AM, Justus Winter wrote:
Quoting Charlie Derr (2013-07-12 16:50:51)
On 07/12/2013 10:40 AM, Justus Winter wrote:
Hi :)

Quoting Charlie Derr (2013-07-12 16:08:16)
Thanks so much for all your efforts.  I immediately attempted to upgrade to your packages on my working install of
debian/GNU hurd.  It's running on an old IBM Netvista.

I seem to be locked up though before getting a console (I did make the requested addition to my /etc/inittab as you
specified).

I'll type in the bottom half of the screen output manually (as the network didn't appear to come up, which didn't
actually surprise me -- I thought I'd be able to fix that after loggin in, but I didn't get a chance):

2 multiboot modules


          task loaded: ext2fs --readonly --multiboot-command-line=root=device:hd0s1 --host-priv-port=1
    --device-master-port=2 --exec-server-task=3 -T typed device:hd0s1
task loaded: exec /hurd/exec

start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec init proc auth



So is there any hope for recovering this system or do I need to reinstall?

I'm also seeing this issue, but it occures only rarely. I think it
also happens with the old runsystem.gnu file. I've no idea what causes
it though. Try rebooting the machine a couple of times. Anyone got an
idea what might be wrong?

Justus


I'm back into the machine, but every time I've tried to boot "normally" it seems to lock up at that same place.

When I choose "Advanced" from the first boot menu, and then "recovery" from the 2nd, the system (and network) comes up
fine.  If there is specific troubleshooting I should do beyond this, please let me know what to try (in order to fix the
"normal" boot process).

Okay, so you're saying that

1. if you use the default entry, the system hangs and "INIT: version
    2.88 booting" is *not* displayed.

I just rebooted and watched carefully. Correct, I never saw that message. As I reported before, the hang takes with the cursor (underscore) blinking just to the right of auth at the end of the bottom line on the screen:

start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1] exec init proc auth



2. if you use the recovery entry, the system boots, "INIT: ver..."
    *is* displayed and you get dropped to a shell?

I seem to get two separate grub-like prompts. The first is a mostly blue screen with GNU GRUB version 2.00-15 at the top. There are only two choices. The default (labeled Debian GNU/Hurd) produces the behavior above (lockup after start ext2fs is displayed on the screen. The non-default entry is labelled "Advanced options for Debian GNU/Hurd" and when I select that I'm immediately taken to another grub-like screen, which also says GNU GRUB version 2.00-15 at the top (but unlike the previous blue one, this prompt has no color, and is rendered in mostly black and white). When I select the default option (which is labelled "Debian GNU/Hurd, with Hurd gnumach-1.3.99-486.gz") the behavior is the same as above (with a lockup at "start ext2fs..."). However, when I boot the non-default option (which has an identical label, but with "(recovery mode)" appended), the system seems to come up fine (giving me a login prompt, and bringing the network connection up) and I'm able to login either on the console or via SSH.



As far as I can tell, the only difference between normal and recovery
is the -s flag in the mach command line. /hurd/init handles this flag,
but does not care. /etc/hurd/runsystem.sysv also parses this flag, and
if it finds it, it adds -s to the /sbin/init invocation.

As far as I can see there is nothing to explain this :/


Thanks for the thoughts. If there's anything else I can try in order to give you folks more information, please do make suggestions.

    appreciative as always,
          ~c


Justus



Thanks very much.  I won't have definitive answers to your questions until Monday (though I *think* that what you
describe is accurate) as this is a physical (non-virtual) machine in my office (and obviously I can't reboot and select
boot menu options remotely).

   as always, I appreciate everyone's efforts,
      ~c




Reply to: