Jun Kuriyama wrote:
kuriyama2003/11/12 00:08:16 PST
FreeBSD src repository
Modified files:
release/i386 drivers.conf
Log:
Move cd9660 module from 3rd floppy to 2nd to unbreak release.
Revision ChangesPath
1.31 +1 -1 src/release/i386/drivers.conf
>
I
On 27-Jul-2002 Terry Lambert wrote:
> Peter Wemm wrote:
>> > So, given that the install from a CDROM boots from a floppy
>> > image that's faked up by the CDROM drive BIOS, and the image
>> > doesn't include the full boot loader, how exactly is it that
>> > the partial boot loader code acts like
Peter Wemm wrote:
> > So, given that the install from a CDROM boots from a floppy
> > image that's faked up by the CDROM drive BIOS, and the image
> > doesn't include the full boot loader, how exactly is it that
> > the partial boot loader code acts like the full bootloader
> > code for accessing
On 25-Jul-2002 Terry Lambert wrote:
> "M. Warner Losh" wrote:
>> : Think "CDROM install".
>>
>> Dude, what crack are you smoking? How many times to we have to tell
>> you. We have a boot loader that knows how to read the kernel from the
>> cdrom or scsi or whatever. IT is a tiny increment to
Terry Lambert wrote:
> "M. Warner Losh" wrote:
> > I've noticed that some of the older cam drivers are about all that is
> > in the way of making CAM truly loadable. By that I mean having a
> > kernel with all supported devices that aren't loadable forces CAM to
> > be in the kernel because some
Terry Lambert wrote:
> "M. Warner Losh" wrote:
> > : Think "CDROM install".
> >
> > Dude, what crack are you smoking? How many times to we have to tell
> > you. We have a boot loader that knows how to read the kernel from the
> > cdrom or scsi or whatever. IT is a tiny increment to also load
>
On Thu, 2002-07-25 at 14:01, Terry Lambert wrote:
> So, given that the install from a CDROM boots from a floppy
> image that's faked up by the CDROM drive BIOS, and the image
> doesn't include the full boot loader, how exactly is it that
> the partial boot loader code acts like the full bootloader
On Wed, Jul 24, 2002 at 06:47:01PM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Makoto Matsushita <[EMAIL PROTECTED]> writes:
> :
> : ru> This was "broken" again. I don't have any ideas of what to move
> : ru> out.
> :
> : There are some ideas to do around boot f
"M. Warner Losh" wrote:
> : Think "CDROM install".
>
> Dude, what crack are you smoking? How many times to we have to tell
> you. We have a boot loader that knows how to read the kernel from the
> cdrom or scsi or whatever. IT is a tiny increment to also load
> additional modules at that time
On Thu, 2002-07-25 at 13:11, Terry Lambert wrote:
> > If your argument was true then the kernel would need to load itself :)
>
> Think "CDROM install".
Think "No Emulation Booting"
True the default is emulation booting off a 2.88Mb image but work is
being done for no-emulation booting (actually
Daniel O'Connor wrote:
> On Thu, 2002-07-25 at 11:45, Terry Lambert wrote:
> > Anything in the boot path needs to be static, by definition,
> > or you face the Catch-22 of needing to load the driver in
> > order to be able to load the driver.
>
> Uhh, not really.
> If your BIOS supports it (which
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: Daniel O'Connor wrote:
: > On Thu, 2002-07-25 at 11:45, Terry Lambert wrote:
: > > Anything in the boot path needs to be static, by definition,
: > > or you face the Catch-22 of needing to load the driver in
:
In message: <[EMAIL PROTECTED]>
Terry Lambert <[EMAIL PROTECTED]> writes:
: "M. Warner Losh" wrote:
: > I've noticed that some of the older cam drivers are about all that is
: > in the way of making CAM truly loadable. By that I mean having a
: > kernel with all supported devices that
On Thu, 2002-07-25 at 11:45, Terry Lambert wrote:
> Anything in the boot path needs to be static, by definition,
> or you face the Catch-22 of needing to load the driver in
> order to be able to load the driver.
Uhh, not really.
If your BIOS supports it (which it must for you to boot off it) then
In the last episode (Jul 24), Terry Lambert said:
> "M. Warner Losh" wrote:
> > I've noticed that some of the older cam drivers are about all that is
> > in the way of making CAM truly loadable. By that I mean having a
> > kernel with all supported devices that aren't loadable forces CAM to
> > b
"M. Warner Losh" wrote:
> I've noticed that some of the older cam drivers are about all that is
> in the way of making CAM truly loadable. By that I mean having a
> kernel with all supported devices that aren't loadable forces CAM to
> be in the kernel because some of the SCSI devices aren't (yet
In message: <[EMAIL PROTECTED]>
Makoto Matsushita <[EMAIL PROTECTED]> writes:
:
: ru> This was "broken" again. I don't have any ideas of what to move
: ru> out.
:
: There are some ideas to do around boot floppies in my mind:
:
: 1) More drivers to move kernel modules, including oth
brooks> It does work though.
It should work, but I wonder if 5-current kernel can mount CD-ROM as
the root filesystem. I've tried before (March/2002 or something), but
it doesn't work, kernel refused to mount CD-ROM (see email archive for
more detail). Sorry if it was already fixed.
-- -
Mako
On Wed, Jul 24, 2002 at 03:03:44PM -0400, John Baldwin wrote:
>
> On 24-Jul-2002 Makoto Matsushita wrote:
> >
> > jhay> nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
> > jhay> reside somewhere else.
> >
> > It seems that it's time to make the 3rd floppy for kernel modules...
On 24-Jul-2002 Makoto Matsushita wrote:
>
> jhay> nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
> jhay> reside somewhere else.
>
> It seems that it's time to make the 3rd floppy for kernel modules...
We could start using cdboot for CD installs, and then just tailor the
flopp
< said:
> We can save some space (I think) by not gziping the individual help
> files, but leave them unzipped. Then the final gzip of the whole image
> should be able to do a better job of it. But I doubt if it will give
> us enough room for nfsclient.ko and msdosfs.ko. :-/ Maybe we should
> sta
jhay> nfsclient.ko and msdosfs.ko exists nowadays, so in theory it can
jhay> reside somewhere else.
It seems that it's time to make the 3rd floppy for kernel modules...
-- -
Makoto `MAR' Matsushita
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
ru> This was "broken" again. I don't have any ideas of what to move
ru> out.
There are some ideas to do around boot floppies in my mind:
1) More drivers to move kernel modules, including other network
drivers, pccard and friends, filesystems, etc. Apparantly it
reduces kernel size so ke
> On Wed, Jul 24, 2002 at 08:07:11PM +0200, John Hay wrote:
> > > On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
> > > >
> > > > ru> Moved vx(4) and all miibus consumers (including miibus) out
> > > > ru> from kern.flp to mfsroot.flp. This leaves 9K of the free
> > > > ru
On Wed, Jul 24, 2002 at 08:07:11PM +0200, John Hay wrote:
> > On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
> > >
> > > ru> Moved vx(4) and all miibus consumers (including miibus) out
> > > ru> from kern.flp to mfsroot.flp. This leaves 9K of the free
> > > ru> space fo
> On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
> >
> > ru> Moved vx(4) and all miibus consumers (including miibus) out
> > ru> from kern.flp to mfsroot.flp. This leaves 9K of the free
> > ru> space for kern.flp.
> >
> > Yey! 5-current distribution will come back aga
On Fri, Jul 05, 2002 at 12:54:26AM +0900, Makoto Matsushita wrote:
>
> ru> Moved vx(4) and all miibus consumers (including miibus) out
> ru> from kern.flp to mfsroot.flp. This leaves 9K of the free
> ru> space for kern.flp.
>
> Yey! 5-current distribution will come back again, thank you!
27 matches
Mail list logo
