2009/5/23 Thomas Schwinge <email@example.com>
[Posting this to bug-hurd -- Mahesh, I hope that's fine?]
Great! Please take some minutes to properly document what you've done
On Sat, May 23, 2009 at 11:06:57AM +0530, മഹേഷ് മുകുന്ദന് | Mahesh M wrote:
> I was able to re-master a live cd, boot it, create a ramdisk, create a
> chroot environment in ramdisk, run sh in chroot, fdisk an attached hdd and
> mount it.
> Now this is what GNU/Linux does in the current installer and thus it can be
> completely replaced. Current method DO NOT install grub. In Hurd, Grub is
> broken too.. (It doesnt know how to talk to Mach -- tschwinge). As per
> current installation, a baseGNU.tgz is uncompressed and dumped into the
> target hdd, from where a "native-install" script is used to configure some
> of the files. This can be done as of now.
and how you've done that, so that we can put this documentation online.
(Just talk to me and I'll tell you where to put it.)
Sure. I will do that soon.
That sould like some essential translators (like pflocal on
> Praveen: When I run dbootstrap from within Hurd, I do get all the "required"
> file and the bin, dev, etc, usr etc folders created. But error occurs when
> it configures the packages. The dbootstrap log shows some broken pipe error
> and resource busy error. Will attach the log file soon. You had successfully
> run dbootstrap right (as the webpage tells).
/servers/socket/1) aren't running.
Do have pflocal running. Couldnt figure out.
Too young, hehe ;-). And I'm getting old, it seems: on 2005-08-23,
> Can anyone fix the Grub. I am too young for that!
nearly four years ago, it was the last time that I had been looking at
porting GRUB to run on GNU/Hurd... Anyways, I now put that stuff up on
don't think that fixing the remaining bits would even be that difficult.
Perhaps Barry is willing to do that and learn a bit of programming for
enabling GRUB to access our disk drives?
That would be great. Currently, the installer cd boots Hurd, creates a ramdisk, chroot into it and mount the target partition and cdrom. While copying the baseGNU.tgz (from cdrom to target) I often encountered error from pager and system hanged. And its taking too long for transfering just 45MB of baseGNU file.
BTW, Mach seems to know the devices (hdd) attached to the system as well as the partitions present in it. Why cant that information be used to automatically create device nodes in /dev ? Currently is there a way the Hurd knows about the partitions and hdd's? That will help the partitioning. What I have done is "assume" that hd0 is target device and hd0s1 is the target partition! Well that is too much of an assumption. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
-----END PGP SIGNATURE-----