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

Re: Hurd F1 ISO and booting



hriedel@HTWM.De wrote in a state of fury:
> > Anyway, this fucking kernel still stops/halts just after the fdc gets
> > recognized. I already had taken off almost all cards I have in my system,
> > but no change. Is there anything I should know of, where gnumach does
> > NOT run on? Else, think about, distributing a small lean kernel, whithout

Henning, how do you expect us to help, if you don't provide us with
somewhat more detailed data?

1. What kernel are you using? gnumach or oskit-mach? Which version?
   Where/When did you get that from? Did you compile it yourself and
   if so, with what 'configure' options _exactly_? Did you cross-
   compile or did you compile it natively? What compiler and binutils
   versions did you use? If you used gnumach that came with Hurd F1
   CDs, please state it so.

2. What does your machine look _exactly_ like? What CPU model? What
   kind of bus? What's stuffed on that bus? Please be extremely
   precise here! If you can get another kernel (e.g. Linux, *BSD)
   to boot your system, please record exactly all boot-time messages
   from kernel and all drivers (dmesg should be sufficient) and note
   all irq's, dma's, io/ports etc... This kind of info can often be
   found in /proc. This will help you figure out, if gnumach runs in
   some interrupt conflict or something similar.

Personally, I can't say anything about the F1 series (waiting for
the F2 series to try again), but I just booted a vanilla E1 distrib.
without problems. I didn't capture the boot messages, but as far as
I can see, the drivers on my system appear ordered somewhat like this:
  [...]
  ide
  fdc
  scsi0 (aic7xxx)
  EATA not found
  ppa
  scsi0 (again)
  smc_ultra
  [...followed by partition check on sd0 and hd0, then com[0-3] etc]

My hardware configuration here is a vanilla pentium/{pci+isa} with
ide hd+cdrom, an adaptec 2940UW controller with a SCSI disk+cd-writer
and a smc-ultra isa (!) network card. I also have a AWE-64
soundblaster card (isa), which is not recognized by gnumach (of
course) and the graphics adapter is a Matrox mga 2MB(pci). No USB.
Mouse is logitech on serial port (no PS/2 stuff). 128 MB (2x64)
of EDO-RAM. As you can see, not the newest config, but that works
great here ;-).

I just gave this spec here, to show the level of detail needed in
bug reports.

> There is a Hurd compatibility guide:
> 
> 	http://www.urbanophile.com/arenn/hacking/hurd/hurd-hardware.html
> 
> You could try looking there for information on what you should/shouldn't
> try to boot it on at the moment.
Ian, that is a good list! Thanks.

> As the system is still being polished, I don't think it's a goal that it
> be able to boot on all the different hardware types that exist out
> there. It's more of a "match your hardware to Hurd" if you want to play
> with it. Not the otherway around.
Agreed. Depending on the kernel Henning is using, it must be noted
that most hardware drivers are linux-based anyway (even OSKit's!), so
if there is a hardware detection problem at boot time, it would
probably be attributable to one of these drivers. Someone with more
knowledge of gnumach/oskit-mach could correct me here if I'm wrong.

Henning, if you can read C, I'd suggest that to have a look at
gnumach sources and look at the way, how drivers are attached in
gnumach. You could probably figure out what driver comes next in the
chain after FDC0.

Ahemm... while we're at it: if you're booting from the F1 ISO, it
may well be, that you're first booting Linux, not gnumach. At least,
that was the way, Phil did realize the E1-series I'm using here. That
probably stuck in F1 as well. Are you sure that _gnumach_ hangs, not
_linux_? I know, it's a stupid question, but you never know...

> > fancy stuff. It would be good to start, and THEN when the installation is
> > done, there should be a new kernel compiled. So I won't have to install
> > a Debian Linux System besides my other systems. I already have a Linux
> > System, but somehow, your cross-compiler won't really fit in there. The
> > compiler seems to be made just for Debian Linux ( think about the .deb
> > packaging ).
> 
> You don't have to actually have a Debian linux system installed. What
> you need is a way to extract the Hurd tarfile onto the partition you
> will boot the Hurd from. From there, you can create a GRUB floppy and
> use it to boot to that new Hurd extraction. The directions worked
> perfectly for me.
I'm using the Hurd here on a Linux-free system. Actually, I'm running
FreeBSD as main OS, and the Hurd is installed in a UFS filesystem (I'm
using /hurd/ufs.static for that and /hurd/ufs for my FreeBSD file-
systems). This configuration works perfectly well. The reason I choose
to risk using (relatively unmaintained?) UFS was that under FreeBSD,
there were no means to 'mke2fs' and e2fstools (or whereever mke2fs
was located) are too Linux dependent to be of practical use elsewhere.

Well, not using Linux as primary system was only annoying a little
bit, because I had to learn how to build a true cross-compiler. But
that is easier than you might think and with the help of others on
this list, it was pretty easy. There are other related problems
not using Linux as development system, but that is probably not your
concern right now.

I personally strongly dislike dpkg & friends, being used to FreeBSD's
ports system for third party software. I won't critisize that dpkg/apt
is being used on a _Debian_ GNU/Hurd system though ;-), even if I
would have preferred a ports like mechanism for a GNU/Hurd system.
But, hey, no-one is _forcing_ us to use a Debian-style packaging
software on a Hurd-based system. People (like me) who don't like this,
can craft up their own distribution-scheme, cloning whatever OS
packaging system they like or even creating their own; so I'm not
complaining here.

> You could easily place a harddrive in your linux machine, extract the
> Hurd onto it, and then move the harddrive over to you Hurd machine. I
> think I did that at some point as well.
Yes, that should definitely work as well. I did that too on a
small experimental cluster and that worked pretty well. I'd
love to netboot gnumach/hurd off an NFS server though... ;-)

> As for the cross-compiler, you don't have to use the .debs to install
> the toolchain. You can build it yourself. I refer you to the email I
> sent two days ago about the subject. It also references instructions
> that were used to build the cross-compile system on FreeBSD.
> 
> 	http://lists.debian.org/debian-hurd-0104/msg00239.html
>
Ian, thanks for the update on cross-compiling and the patches. I'll
try to repeat that experiment [;-)] both on Linux and FreeBSD later.

I'll be very interested in your scripts/framework. Could you please
post them to this list? I'm also using some (now outdated) perl scripts,
but I never went the whole way (from cvs update-ing to rebuilding
cross-toolchain to cross-compiling and installing on /gnu-mounted
filesystem etc...). The more we can automate, the better!

> Ian Duggan                    ian@ianduggan.net
>                               http://www.ianduggan.net

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.



Reply to: