with the new partition table I could boot the mach.
After a 'export TERM=mach' and './native-install' I had my debian
gnu/hurd installed. I had not to reboot the system and do a second
'./native-install'
Yes, running it once should be enough these days. Where did you read
about having to run it twice?
http://www.debian.org/ports/hurd/hurd-install
I knew the page from debian (I am debian GNU/Linux user), but the same
page is reported on the gnu-hurd site
(http://www.gnu.org/software/hurd/#index4h2).
The think that at the moment I would change:
- Chapter 2 (Real Estate or Finding A Home):
# mke2fs -b 4096 -I 128 -o hurd /dev/hda2 --> # mke2fs -o hurd /dev/hda2
(/-o hurd/ does exactly /-b 4096 && -I 128/, not reason to repeat)
- Chapter 6 (Native Install):
/Before the script terminates, it will indicate that it needs to be run
a second time. Follow its instructions and reboot using the reboot
command. Again, go into single user mode and run ./native-install./
This is not necessary.
At the moment I would also change the chapter 5 (Booting GNU/Hurd) with
the insertion directly in /boot/grub/menu.lst (will said on chapter 8.1,
The Grub Menu) because you have to copy the lines with the modules
elsewhere; with menu.lst you don't need this (but I recognize that could
be only philosophy this approach).
/After reboot on multi-user mode the Hurd console started automatically.
I controlled on /etc/default/hurd-console the string 'ENABLE', but it
was setting to 'false'... I don't know why, I tried others reboot but
I've got always the console started automatically.
Yes, but that's probably the Mach console, not the Hurd one.
I don't think so. The mach console is for me that with for example the
single-user mode (...#), the Hurd console is that one that begins with
GNU 0.3 (myhostname) (console) ... login>. I made some trials with QEMU
and I had always to put in /etc/default/hurd-console ENABLE='true' to
start this console.
With this installation ENABLE is set to 'false' but the hurd console
still booting.
Actually I've got others problem (like for example a freeze of the
system by taping "Shift" or "Control")
That's strange. Can you tell us more about that?
I think is a problem with an Apple USB keybord (also in the installation
I had the same problem). I always had problem with this keyboard (also
in GNU/Linux) but unfortunately I always found a solution and still have
this one. With QEMU I solved the problem with the package:
http://packages.hurdfr.org/experimental/binary-hurd-i386/clavier_0.2_hurd-i386.deb
I think "Shift" and "Control" are not really patched and the System goes
into an infinite loop.
For the partition table problem, it will be interesting to know if the
problem was a too higher index of the partition or a logical partition
or a partition at the end of the disk. Maybe when I find a little bit of
time i will try with another disk and different partition tables.
OK, please report back your findings.
It wouldn't be tomorrow but if I do it I will report for sure the results.
Cheers,
Bruno
