Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Maxim writes, >Correct me if I'm wrong, but loader is unable to directly load kernel from >non-FreeBSD partition (DOS in your case), so problem is slightly more >complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it >to match your needs. > I have tried booting /boot/loader from a floppy, and then have loader boot a kernel that resides in a DOS file system. As far as I can tell, it works flawlessly. Carlos C. Tapang http://www.genericwindows.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
"Carlos C. Tapang" wrote: > Thanks to all who pitched in their input to this issue. Most users of my > system are running Windows and don't want to have to reformat or repartition > their hard disk. So I am stuck with the DOS file system. I think the best > solution is to have my users use a FreeBSD boot floppy. The floppy will have > /boot/loader which I will point to the DOS-formatted hard disk in which the > kernel resides. Correct me if I'm wrong, but loader is unable to directly load kernel from non-FreeBSD partition (DOS in your case), so problem is slightly more complicated but I though your can take PicoBSD (FreeBSD on floppy) and tweak it to match your needs. Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Sounds like you want something like a FreeBSD version of DOS Linux. See http://www.tux.org/pub/people/kent-robotti/index.html. How do they overcome this problem? Greg At 02:45 PM 5/19/99 -0700, Carlos C. Tapang wrote: >Thanks to all who pitched in their input to this issue. Most users of my >system are running Windows and don't want to have to reformat or repartition >their hard disk. So I am stuck with the DOS file system. I think the best >solution is to have my users use a FreeBSD boot floppy. The floppy will have >/boot/loader which I will point to the DOS-formatted hard disk in which the >kernel resides. > >>The flags and values in the BIOS data area would not necessarily >>be at their default values, so restoring the vectors might itself >>crash the BIOS (because it's reconfigured itself for the present >>vectors/drivers, not the default ones). >> >>Some hardware (eg. popular SCSI controllers) also configures itself >>differently when it finds it's running on DOS/Windows. This kind >>of thing in any scenario in which we start DOS then kill it would >>have the potential to seriously confuse matters. >> >>Incidentally (to correct a point made in an earlier post) *all* >>versions of DOS since 1.x have changed interrupt vectors. This is >>not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at >>this stage is that, in the future, VM86 will be increasingly relied >>on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a >>VM86 context. >> >>-- >>Robert Nordier >> >> >>To Unsubscribe: send mail to majord...@freebsd.org >>with "unsubscribe freebsd-current" in the body of the message >> > > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Thanks to all who pitched in their input to this issue. Most users of my system are running Windows and don't want to have to reformat or repartition their hard disk. So I am stuck with the DOS file system. I think the best solution is to have my users use a FreeBSD boot floppy. The floppy will have /boot/loader which I will point to the DOS-formatted hard disk in which the kernel resides. >The flags and values in the BIOS data area would not necessarily >be at their default values, so restoring the vectors might itself >crash the BIOS (because it's reconfigured itself for the present >vectors/drivers, not the default ones). > >Some hardware (eg. popular SCSI controllers) also configures itself >differently when it finds it's running on DOS/Windows. This kind >of thing in any scenario in which we start DOS then kill it would >have the potential to seriously confuse matters. > >Incidentally (to correct a point made in an earlier post) *all* >versions of DOS since 1.x have changed interrupt vectors. This is >not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at >this stage is that, in the future, VM86 will be increasingly relied >on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a >VM86 context. > >-- >Robert Nordier > > >To Unsubscribe: send mail to majord...@freebsd.org >with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > > > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > > > and hence the whole system. > > > > > > Obviously it makes no sense at all to make special DOS boot floppy with > > > old > er DOS > > > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot > > > flopp > y with > > > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > > > dri > ve, so it > > > seems that FBSDBOOT now totally useless :( > > > > > > Sincerely, > > > > > > Maxim > > > > > Why can't we make a copy of the vector table and save to file and have > > fbsdboot use the table from the file? > > How do we get this vector table in the first place? > > How do we keep it updated? The flags and values in the BIOS data area would not necessarily be at their default values, so restoring the vectors might itself crash the BIOS (because it's reconfigured itself for the present vectors/drivers, not the default ones). Some hardware (eg. popular SCSI controllers) also configures itself differently when it finds it's running on DOS/Windows. This kind of thing in any scenario in which we start DOS then kill it would have the potential to seriously confuse matters. Incidentally (to correct a point made in an earlier post) *all* versions of DOS since 1.x have changed interrupt vectors. This is not a DOS 7+ phenomenon. The reason FBSDBOOT.EXE is deprecated at this stage is that, in the future, VM86 will be increasingly relied on by FreeBSD. And FBSDBOOT.EXE has *never* worked reliably in a VM86 context. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > > and hence the whole system. > > > > Obviously it makes no sense at all to make special DOS boot floppy with > > older DOS > > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot > > floppy with > > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > > drive, so it > > seems that FBSDBOOT now totally useless :( > > > > Sincerely, > > > > Maxim > > > Why can't we make a copy of the vector table and save to file and have > fbsdboot use the table from the file? How do we get this vector table in the first place? How do we keep it updated? -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
> > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > > and hence the whole system. > > Obviously it makes no sense at all to make special DOS boot floppy with older > DOS > just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot floppy > with > /boot/loader and hacked /boot/loader.conf to boot kernel from your hard > drive, so it > seems that FBSDBOOT now totally useless :( > > Sincerely, > > Maxim > Why can't we make a copy of the vector table and save to file and have fbsdboot use the table from the file? -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
Matthew Thyer wrote: > Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 > boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel > and hence the whole system. Obviously it makes no sense at all to make special DOS boot floppy with older DOS just to run FBSDBOOT - it simply enough to make "native" FreeBSD boot floppy with /boot/loader and hacked /boot/loader.conf to boot kernel from your hard drive, so it seems that FBSDBOOT now totally useless :( Sincerely, Maxim To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
SUMMARY: why you cant use FBSDBOOT.EXE anymore (Was: Re: FBSDBOOT.EXE)
The problem is that recent versions of MS-DOS (version 7 and above ? ...definitely the DOS that comes with Windows 98 and I think the DOS with Windows 95 under some circumstances) change various vectors which destroy FBSDBOOTs ability to work (this is because there is no way to determine where these vectors used to point and the original addresses are required for correct operation of either FBSDBOOT or the kernel/ loader). What I do know is that at least some older versions of MS-DOS do not do this. Therefore it *MAY* be possible to make a DOS 6.0, 6.20 or even 6.22 boot floppy which runs FBSDBOOT.EXE to boot your a.out FreeBSD kernel and hence the whole system. Hopefully now that Carlos Tapang has updated FBSDBOOT.EXE for ELF, such a boot floppy could boot a 3.1, 3.2 or -CURRENT system. Unfortunately the project cannot guarantee anything when you are booting from another vendor's operating system (such as MS-DOS) so its a lot easier to say that FBSDBOOT.EXE has been retired. Given the number of different DOSes that exist, that's an entirely understandable policy. I hope this clears things up (and adds a good summary to the archives). "Carlos C. Tapang" wrote: > > Mike, Thanks for trying fbsdboot.exe. I need more information to fix it. I > would like to fix it, so please describe exactly what the problem is. What > do you mean by the "need to reboot the system to restore various vectors > that DOS destroys"? Do you mean that prior to executing the FreeBSD kernel > init routines, DOS does something to the loaded area? I'm sorry I can't find > any info on this either in the mail threads or in freebsd.org. Probably I'm > not looking hard enough, but I believe it would be more efficient to just > ask you. > > Carlos C. Tapang > http://www.genericwindows.com > > -Original Message- > From: Mike Smith > To: Carlos C. Tapang > Cc: Bob Bishop ; Mike Smith ; > curr...@freebsd.org > Date: Sunday, May 16, 1999 7:28 PM > Subject: Re: FBSDBOOT.EXE > > >> >It doesn't work. Don't use it. You need to reboot the system to > >> >restore various vectors that DOS destroys. Please see the previous > >> >threads on this topic, especially anything from Robert Nordier. > >> > > >> The most relevant piece I can find from R. Nordier is the following: > >> "The fbsdboot.exe program should probably be considered obsolete. It > >> should (in theory) be possible to use it to load /boot/loader, which > >> can then load the kernel, but there are various reasons this doesn't > >> work too well." > > > >These reasons were also expounded, and I did summarise them in another > >message on this thread. > > > >> I have not tested the updated program with /boot/loader. /boot/loader does > >> not help me because my root directory is in a memory file system, and I can > >> not assume that my users will want to reformat their DOS drives or even > >> repartition it. So all FreeBSD files are in the DOS file system. > > > >The loader won't help you because you are booting from under DOS, but > >the loader will boot the kernel just fine off a DOS filesystem. > > > >-- > >\\ Sometimes you're ahead, \\ Mike Smith > >\\ sometimes you're behind. \\ m...@smith.net.au > >\\ The race is long, and in the \\ msm...@freebsd.org > >\\ end it's only with yourself. \\ msm...@cdrom.com > > > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message -- /===\ | Work: matthew.th...@dsto.defence.gov.au | Home: thy...@camtech.net.au | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
