Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 07 Nov 1999 11:57:26 -0800
From:      Mike Smith <mike@smith.net.au>
To:        Juergen Lock <nox@jelal.kn-bremen.de>
Cc:        Mike Smith <mike@smith.net.au>, zzhang@cs.binghamton.edu, freebsd-stable@FreeBSD.ORG
Subject:   Re: easyboot far into disk 
Message-ID:  <199911071957.LAA13619@dingo.cdrom.com>
In-Reply-To: Your message of "Sun, 07 Nov 1999 03:54:54 %2B0100." <19991107035454.B59629@saturn.kn-bremen.de> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > Rootdev ought to work, actually.  But if you get it wrong, the loader 
> > will fall back to using currdev.
> 
> Hmm then thats strange.  I first tried rootdev, which didn't work, and
> then later currdev, which did work, and i believe i used the same value
> both times!  Or was rootdev fixed only recently, the boot floppies i
> had lying around and tested this on weren't the latest...

I thought rootdev was fixed a long time back.  If it's not, please tell 
me and I'll fix it again.  8)

> > >  Btw i remember reading in a commitlog that the concept of a `current
> > > device' in loader is about to go, so maybe now this no longer works in
> > > -current...
> > 
> > The model I'm currently looking at tries to hide the way the loader 
> > thinks about devices as much as possible simply because it's too 
> > confusing.
> 
>  Well its just the BIOS' way to think about devices, isn't it?

Not really; it's a confusing mix of sort-of the way the BIOS thinks 
about devices, and sort-of the way that we think about them.

> >  In -current the "best" way to tell your loaded kernel where 
> > to find its root filesystem is with the vfs.root.mountfrom tunable.
> 
>  But since the kernel isn't using the BIOS to mount its root that
> of course still makes much more sense.  (no need to fiddle with
> root_disk_unit if the disk is on the second IDE channel and there
> aren't two more on the first, or if there are both IDE and SCSI
> disks...)

That's exactly the point.  The crucial problem has always been working 
out how to translate the BIOS unit number into a device name (or major/
minor).  So we don't bother anymore (except for fall-back emergency 
cases).

> > >  (Maybe this should be added to the FAQ as a method of last resort when
> > > the BIOS boot code can't see above cyl 1024?)
> > 
> > From what I've been hearing from people lately, in most cases it's 8GB 
> > that's the new sound barrier,
> 
>  Yea, probably true with later boards. (anyone know if there's a
> real technical reason for that, or just again short-sightedness of
> the BIOS writers?  I mean first 32M if i remember right, then 512M,
> then 2G, now 8G...  shouldn't everyone know by now that disks are
> getting bigger all the time?)

It's a limitation of the c/h/s interface and the practical translations 
available.  Over 8GB we finally have to use LBA mode; the problem there 
is that there's still too much legacy hardware out there that will 
break if we default to it.

> >  but yes, a FAQ entry is probably worth 
> > writing.  Go to it!
> 
>  Thats what i get for saying such things... :)  Well OK, once i know
> why `rootdev' didn't work i should have a try.

Thanks!
-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911071957.LAA13619>