Re: boot1 changes and etherboot support
Luigi Rizzo wrote: + put some conditional-compilation code in boot1.s + have a separate file, say bootrom.s, maybe in the same directory as the existing boot1 + pass the modified code to the etherboot people so they can include in their source tree. in all sincerity i'd love to have this code in the FreeBSD source tree rather than have to resort to some external repository. My preference would be for a separate file in a separate directory, more or less similar to cdldr and pxeldr; I'd be least keen on handling this with conditional-compilation. ok.. do you mind then if i follow your advice and create /sys/i386/romldr/ and put there the modified boot1, makefile etc ? There has been no other feedback so i think most other people is neutral. Seems good to me. On a separate issue, and for picobsd purposes, it would be very convenient to have yet another boot sector type that would just take an ELF kernel appended to it, load into memory and start it. I suppose this would be a variant of boot2, but do you have any idea on how complex would it be to write such a beast ? I have a generic boot1, that would just about do this. Instead of understanding filesystems or file formats, it works off an embedded list of block address, block count pairs. I've used the same code to boot a.out and ELF kernels off ufs, fat, and iso9660 file systems; but it does need an installation utility rather than just dd. On the other hand, to create exactly what you had in mind isn't all that much work. A sort of combination of logic from boot1.s and btx/btxldr.s (which parses ELF) would do the job in pure assembly language; otherwise just stripping most of the functionality from boot2 should work in C (and would be similar to "rawboot" that phk did using the old aout bootblocks). -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: I have spent some time trying to put etherboot[1] code onto the hard disk so that it can be selected using the FreeBSD boot manager. I ended up doing it with a small amt of modifications to the "boot1" code, for which a patch is attached. Maybe it could be interesting in applying this patch to the standard boot1 code (apart for the PRT_BSD change, which should be unmodified). The size of the boot1 code must be = 446 bytes. The code already gets customised a lot, for example, in embedded work and space needs to be left to allow for that. So I wouldn't personally be in favour of adding this to the standard boot1. -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot1 changes and etherboot support
Luigi Rizzo wrote: Luigi Rizzo wrote: I have spent some time trying to put etherboot[1] code onto the hard disk so that it can be selected using the FreeBSD boot manager. I ended up doing it with a small amt of modifications to the "boot1" code, for which a patch is attached. Maybe it could be interesting in applying this patch to the standard boot1 code (apart for the PRT_BSD change, which should be unmodified). The size of the boot1 code must be = 446 bytes. The code already gets customised a lot, for example, in embedded work and space needs to be left to allow for that. So I wouldn't personally be in favour of adding this to the standard boot1. On the other hand, the ability to load a rom image is very useful, so i wonder what do you think is the best approach among the following: + put some conditional-compilation code in boot1.s + have a separate file, say bootrom.s, maybe in the same directory as the existing boot1 + pass the modified code to the etherboot people so they can include in their source tree. in all sincerity i'd love to have this code in the FreeBSD source tree rather than have to resort to some external repository. My preference would be for a separate file in a separate directory, more or less similar to cdldr and pxeldr; I'd be least keen on handling this with conditional-compilation. That's just me, though, and this probably isn't a case where the views of the author/maintainer should have any special weight. -- Robert Nordier [EMAIL PROTECTED] // Le monde est plein de fous, et qui n'en veut pas voir [EMAIL PROTECTED] // Doit se tenir tout seul, et casser son miroir. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More on BTX halted / crashes trying to use -stable /boot/loader
Matt Dillon wrote: I sure would appreciate it if one of the bootstrap gurus could take a look at what happens when the tftp open routine is called from a normal disk-based /boot/loader! I've already looked at this, investigating a problem reported in connection with PR 21559. I'll probably sort it out in the next day or two, unless someone else gets there first. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting Linux application to FreeBSD
Andrew Otwell wrote: same problem. I'm trying though bash-2.03$ gcc -static -nostdlib -L/usr/lib \ -lalias -lalias_p -lc -lc_p -lc_pic -lcalendar -lcalendar_p -lcom_err -lcom_err_p \ -lcompat -lcompat_p -lcrypt -lcrypt_p -lcurses -lcurses_p \ -ldialog -ldialog_p -ldisk -ledit -ledit_p -lf2c -lf2c_p -lfl -lfl_p -lftpio \ -lftpio_p -lg++ -lg++_p -lgcc -lgcc_p -lgcc_pic -lgmp -lgmp_p \ -lgnuregex -lgnuregex_p -lipx -lipx_p -lkeycap -lkeycap_p -lkvm \ -lkvm_p -ll -ll_p -lln -lln_p -lm -lm_p -lmd -lmd_p -lmp -lmp_p -lmytinfo \ -lmytinfo_p -lncurses -lncurses_p -lobjc -lobjc_p -lopie -lopie_p \ -lpcap -lpcap_p -lreadline -lreadline_p -lrpcsvc -lrpcsvc_p -lscrypt \ -lscrypt_p -lscsi -lscsi_p -lskey -lskey_p -lss -lss_p -lstdc++ -lstdc++_p -ltelnet -ltelnet_p -ltermcap -ltermcap_p -ltermlib -ltermlib_p \ -lutil -lutil_p -lvgl -lvgl_p -lxpg4 -lxpg4_p -ly -ly_p -lz -lz_p \ test2.c /var/tmp/ccaCTG6m.o: Undefined symbol `___main' referenced from text segment /var/tmp/ccaCTG6m.o: Undefined symbol `_printf' referenced from text segment /var/tmp/ccaCTG6m.o: Undefined symbol `_printf' referenced from text segment collect2: ld returned 1 exit status bash-2.03$ From the look of it, either your toolchain is mis-configured or you're generating the wrong object format. You should be seeing something like this (note lack of underscore): /tmp/ccmb1952.o: In function `main': /tmp/ccmb1952.o(.text+0xf): undefined reference to `printf' I think you mentioned somewhere you're generating ELF (not a.out); if so, your compiler is not doing the right thing for external symbols. What appeared in FreeBSD a.out libraries as "_printf" is plain "printf" in ELF. There is no "_printf" symbol in the standard FreeBSD libc, nowadays. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
Garance A Drosihn wrote:
The point about
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
is that it's a silly thing to do deliberately, but if I was
porting some hairy old C code I'd tend to expect it to work.
C is not a language in which you go out of your way to prevent
people making mistakes.
I would not expect it to work. This has nothing to do with
the C language, it has to do with fclose. Fclose gets rid
of the descriptor. In my own code, I usually follow 'fclose(fp)'
with 'fp = NULL', because that stream is GONE. I do realize that
this code does seem to work on several operating systems, but it
also causes dramatic problems with linux. Given the description
of fclose, I'd say it is the code which is wrong.
This has to do with the C language at least in the sense that the
standard library is a part of C. About half the bulk of the original
ANSI/ISO C Standard is taken up with specifying the library.
I don't think I really disagree with the points you make, mostly
not quoted; but I also think the fundamental issue is that you're
not entirely in sympathy with the C way of doing things, and that
you'd prefer to be using something else. (Someone who does the
fp = NULL thing is quite likely deep-down a Modula-3 guy, or an
Oberon guy, or an Ada guy, or something. :-)
The _Rationale_, which was put out by the original ANSI committee
somewhat in defence of the C Standard itself, talks about sticking
to "the spirit of C". And the first of the tenets it mentions is
"Trust the programmer".
It's probably fair to say that the lack of sanity-checking in the
routines of the standard library is one example of that kind of
trust. Though whether it is sensible to trust the programmer not
to make silly mistakes is a different matter altogether, of course.
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
Daniel C. Sobral wrote: Garance A Drosihn wrote: Undefined behavior means anything goes. On a standard, it means the behaviour is implementation-defined (which may be undefined or not). While not disagreeing with what I think Daniel means: at least in the C Standard itself, "undefined behavior" and "implementation-defined behavior" are kept carefully separate. A quote from X3J11's Rationale document probably addresses the crux of the issue Garance raised, though: Undefined behavior gives the implementor license not to catch certain program errors I am not saying that what freebsd does is wrong. But Robert said that "[that code is a silly thing], but if I was porting some hairy old C code I'd tend to expect it to work." It seems to me that if the behavior is explicitly undefined then you can NOT expect much of anything when porting. He said he would _tend_ to expect it to work. To me, that means the code is dubious, but is likely to work. Garance himself writes, two messages back: The thing with ferror is that it will generally "work" after the fclose, although the value it returns might not be the right (pre-close) value. and I really meant something very similar. Though I'd probably go a bit further and say -- knowing how ferror is likely to be implemented -- the most probable result of invoking it after fclose would be a failure to detect that an I/O error had occurred. For "hairy old C code", that "works" about as much as I'd expect it to. And notice that ferror() is not an access to the stream. In the section I quoted from unix spec, "stream" refers to the variable passed to fclose (though that isn't obvious, because I didn't copy the formatting). ferror certainly does access that variable. MM. That's a dubious interpretation. The variable is a handle to the stream, not the stream itself. Are you sure of the SUS wording? The original ISO standard defines "FILE" as an object capable of recording all the information needed to control a stream [7.9.1] and elsewhere goes on to describe a stream as, for example an ordered sequence of characters [7.9.2] so I think it's fairly clear that a stream is not what (FILE *) points at. I doubt that the SUS would intentionally deviate on such a fundamental point. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fclose vs ferror (from libc/getcap)
Garance A Drosihn wrote:
As mentioned in pr bin/22965, I stumbled across a bug
in libc/gen/getcap.c when compiling it under other
platforms. The basic problem is some code which does:
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
I find it surprising that the above works under FreeBSD.
(not only that, it seems to work OK under several other
OS's too). The fclose is supposed to throw away the
stream, but the ferror (apparently) still works with
that pointer.
The PR includes a patch for getcap.c (which is just to
use the result from fclose to determine if an error
occurred), but I also wonder if we should do something
so that this combination would ALWAYS fail. It seems
to me that fclose should clear out whatever fields that
ferror is using for sanity-checking, and ferror should
always return an errno of 'bad parameter', or something
like that.
Or is there some reason that we DO want ferror to work
on streams which have already been closed?
Bear in mind that ferror is one of a number of stdio functions that
are often implemented as macros. For instance: ferror and (say)
getc might look like this:
#define ferror(f) ((f)-fl _FERR)
#define getc(f) ((f)-p (f)-xr ? *(f)-p++ : fgetc(f))
Given the intentionally minimalist way those functions are written,
to do any consistent and obligatory sanity-checking on (FILE *) would
cause a big change in the actual code generated, and the amount of
code generated.
I think the best way to do what you want is to create a separate
debugging library.
The point about
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
is that it's a silly thing to do deliberately, but if I was porting
some hairy old C code I'd tend to expect it to work. C is not a
language in which you go out of your way to prevent people making
mistakes.
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel calls, are they documented somewhere?
G. Adam Stanislav wrote: On Thu, Nov 02, 2000 at 12:12:02AM -0500, Michael Bacarella wrote: gcc does not generate code that can make FreeBSD system calls directly. Most system calls as we know them by the manual have corresponding wrappers in libc. See /usr/src/lib/libc if you have the source installed. I do have the source code, and I have studied it, but it is uncommented. And, it seems, not all of it is included. For example, there is a /usr/src/lib/libc/sys/open.2 but no corresponding open.c. I have been unable to find the source code for open() in libc. There is an open.c in /usr/src/lib/libstand/ but it makes no system calls. Actually, it looks like a system call (it assigns its own file descriptors to files it opens), but it does not behave like our kernel (since it returns -1 on errors, while our kernel has been returning 2 in my tests when trying to open a non-existing file as O_RDONLY: sub eax, eax; EAX = 0 = O_RDONLY pusheax pusheax pushesi ; points at file name pusheax ; fake return address int 80h add esp, byte 16 (That's NASM syntax.) If the file exists, I get a file descriptor in EAX, otherwise EAX = 2. It would be nice if I could get some kind of formal confirmation that this is how it is supposed to be, and that all FreeBSD versions behave like that. Here's open(2) implemented as a C function: open: mov $0x5,%eax int $0x80 jc .L1 ret .L1:jmp __cerror __cerror: mov %eax,errno mov $-1,%eax ret The idea is to check the carry flag, since the kernel returns two different things in %eax, depending on whether an error has occurred. Our function maintains errno, since this is how things are done in the C library. If you need more info, e-mail me directly. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinux hardware
David O'Brien wrote:
On Fri, Oct 27, 2000 at 01:10:56PM +0200, Robert Nordier wrote:
Just doing the disklabel -w -r followed by the disklabel -B is creating
a dangerously dedicated disk,
Actually this is a "fully dedicated" disk. (made to look like a 50MB or
so disk to M$ products)
Sysinstall is used to create a "dangeriously dedicated" disk (when not
create slices.
I can't say I agree with the distinction (though I'm not sure it
really matters).
Consider this comment in sys/i386/i386/autoconf.c:
| * For properly dangerously dedicated disks (ones with a historical
| * bogus partition table), the boot blocks will give slice = 4, but
| * the kernel will only provide the compatibility slice since it
| * knows that slice 4 is not a real slice. []
The "historical bogus partition table" is defined in the file
sys/kern/subr_diskmbr.c as follows:
| static struct dos_partition historical_bogus_partition_table[NDOSPART] = {
| { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },
| { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },
| { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, },
| { 0x80, 0, 1, 0, DOSPTYP_386BSD, 255, 255, 255, 0, 5, },
| };
and this is the same table entry that appears in the hexdump provided
by Matt Dillon:
| Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto'
|
| 00f0 66 8b 46 08 52 66 0f b6 d9 66 31 d2 66 f7 f3 88 |f.F.Rf...f1.f...|
| . . . . .
| 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 ||
| 01f0 01 00 a5 ff ff ff 00 00 00 00 50 c3 00 00 55 aa |..P...U.|
It's a long time since I used sysinstall, but I assume that a "fully
dedicated disk" just has a normal partition table with a single entry
that allocates all available space.
The above, OTOH, is an illegal fdisk partition table entry, and what
I think most of us would refer to as "dangerously dedicated".
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinux
Fred Clift wrote: Why not edit the partition table after boot1 gets installed? Because you can never make it valid. By keeping it the same set of illegal values, at least the system can recognise it. What do you mean it can't be made valid? fdisk -u and a few keystrokes later and I have a valid partition table... Whats wrong with it? Really, if I'm being dense, sorry -- perhaps I just dont under stand yet -- please be patient with me :) If the PC partition (slice) includes boot1, it is invalid. A slice should can't include its own MBR. If the BSD partition excludes boot1, it is invalid. A partition can't exclude its own boot blocks. Just because fdisk is happy, doesn't mean it's valid. Just because it works (for you), doesn't mean it's valid, either. :) A final point: o Don't use dangerously dedicated mode. I'd love to but the tools for automated installs in non-dedicated mode dont really exist in a supported way. One of the things that was pointed out in the thread is that disklabel doesn't work inside an fdisk slice. Disklabel really needs to be rewritten. I could use expect to manipulate sysinstall? So, for now, I use dangerously dedicated installs with a hacked fake partition table to work around the broken bioses I use. I just might start using program posted in this thread that lets you do labels right in lieu of anything else, or perhaps I'll fix disklabel to work right as was suggeseted elsewhere. Don't sysinstall work in a script mode? I've never used it, but I thought it did. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinux hardware
Matt Dillon wrote:
:
: Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto'
:
:If you added "auto" after the "disklabel -B", that may be your problem.
:
:--
:Robert Nordier
type-o. No auto for the -B still blows up the dos partition
table.
Just doing the disklabel -w -r followed by the disklabel -B is creating
a dangerously dedicated disk, which your BIOS apparently doesn't like.
(See the first hex dump you did, where boot1 has ended up in the MBR.)
That's why installing boot blocks is messing with the partition table,
to answer the question you asked elsewhere.
You need to dd and fdisk before the disklabel commands, which will give
you a standard partition table (at the cost of 63 sectors of disk
space).
--
Robert Nordier
[EMAIL PROTECTED]
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Really odd BTX halted problem booting FreeBSD on VALinux hardware
Matt Dillon wrote: Raw data on disk after 'disklabel -w -r da0 auto; disklabel -B da0 auto' If you added "auto" after the "disklabel -B", that may be your problem. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to install BootEasy?
Bob Bishop wrote: Apologies for this, I'm sure I've seen the answer recently but I'm *^%ed if I can find it in the archives[1]. I have an installed FreeBSD hard disk that I want to use as the second drive on a machine with other stuff on the first drive. How do I install BootEasy on the first drive? TIA We don't use BootEasy any longer, but something called boot0 ... which is probably why you couldn't find anything in the archives. Something like boot0cfg -Bv $DRIVE should work, though see the man page. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Conflicting C/H/S values
Trent Nelson wrote: Could someone explain to me why the following HDD BIOS Geometries don't represent the values proposed by the drives. What am I missing? (snippets from boot -v) BIOS Geometries: 0:030c7f3f 0..780=781 cylinders, 0..127=128 heads, 1..63=63 sectors 1:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 2:03fefe3f 0..1022=1023 cylinders, 0..254=255 heads, 1..63=63 sectors 3:026dfe3f 0..621=622 cylinders, 0..254=255 heads, 1..63=63 sectors 0 accounted for These don't correlate to the C/H/S values proposed by the drives: ad0: 8063MB (16514064 sectors), 16383 cyls, 16 heads, 63 S/T, 512 B/S ad1: 9787MB (20044080 sectors), 19885 cyls, 16 heads, 63 S/T, 512 B/S ad2: 3079MB (6306048 sectors), 6256 cyls, 16 heads, 63 S/T, 512 B/S ad3: 4892MB (10018890 sectors), 10602 cyls, 15 heads, 63 S/T, 512 B/S I'm running 5.0 as of mid-September, but I don't think that's the issue as Windows tends to exhibit the same behaviour. The way the PC BIOS CHS disk interface was designed, too few cylinders (1024) and too many heads (256) are supported, compared with the geometry disk drives pretend to have nowadays. So most modern BIOSes do translation by default, representing 6256 cyls x 16 heads as (6256/8 x 16*8 =) 782 cyls x 128 heads. The off-by-one difference (782 vs. 781 given as BIOS geometry for drive 0) is due to reserving the last cylinder for diagnostics, etc., another BIOS quirk. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: putting FreeBSD in an extended partition
Zhiui Zhang wrote: On Tue, 26 Sep 2000, Mike Smith wrote: If that were possible, it would be trivial to improve the loader to deal with that case. The kernel most certainly can mount an extended partition as root, however. I know this is a minor subject. But Why Linux can be put in an extended partition while FreeBSD cannot? I can not find anywhere (e.g. kern/subr_diskslice.c) in the kernel that prevents this and I know LILO can boot FreeBSD. If it is the problem of booteasy, then we can use other boot loader. The standard bootblocks (ie. boot2) don't support this at present, nor do our tools like fdisk(8) and the equivalent part of sysinstall; so there's a reasonable amount of work needed to make booting from extended partitions a properly-supported feature. I'll most likely be adding this support in the next few months, though. It hasn't been a priority item as there's been little interest till recently. It should be fairly easy to hack boot2 to get this working in your particular case, if you have the time and inclination. -- Robert Nordier [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
Because most modern BIOSes do CHS translation, the BIOS geometry is not always evident from the geometry reported by the drive, and FreeBSD may get this wrong, particularly if no existing partitions are defined. Since you are installing to a drive with no pre-existing non-FreeBSD partitions, I suspect sysinstall got the geometry wrong. Probably you should re-install and use the 'G' command in sysinstall's fdisk, after determining what geometry the BIOS is actually using. The best way to determine BIOS geometry in FreeBSD is to boot -v (but it should be from the old "boot:" prompt, not from loader(8) in 3.2R) and then check using dmesg(8) for "BIOS Geometries" information. Hmmm - perhaps it isn't possible then to do what I want (without losing most of the drive). The drive is 17Gb, consisting of 33416 cyls, 16 heads and 63 sectors. The BIOS reports 1023 cyls, 255 heads and 63 sectors - which is approximately 8Gb. This doesn't change if I change the BIOS mode between normal, large or LBA, nor if I make the disk type in the BIOS user defined and enter the real parameters (the BIOS is an Award BIOS v4.51PG, probably from about 1996). 1023/255/63 as the BIOS geometry is OK. It means that only about half the drive will be accessible through the BIOS CHS interface, but there is an "8.4GB" CHS limit anyway. The BIOS CHS interface is mainly needed only for booting. Some OSes support booting using a more recent BIOS LBA interface, which doesn't (effectively) have a size limit. Windows 9x and FreeBSD can do that, provided your BIOS LBA support isn't broken. Because not many OSes (or boot managers) support BIOS LBA, how you set up your partitions, and what OSes you choose to install in which partitions, needs some thought. Personally, for maximum flexibility, I'd use FreeBSD's boot0 (or some commercial boot manager that also supports LBA). And I'd install 2.2.8 in partition 4, but using the boot blocks from -current. I'd also suggest ending partition 2 about 32-64M below cylinder 1024. So it isn't completely straightforward, but you can make use of the whole disk. I assume that if I set the gemoetry in fdisk to be the BIOS figures, that I will lose the other half of the disk? Use 2096/255/63 in sysinstall. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
It's usually best to temporarily change fdisk partition types, so that sysinstall sees no existing FreeBSD slice on the drive. However, there may be other problems involved here as well. Hmmm. This sounds a good plan. Would the following then work (I'm using `partition' to refer to a fdisk partition, and `file system' to refer to a BSD partition): * I partition my drive into 4 equal partitions (rather than 2; this gives me more future flexibility) * I install 2.2.8 in the first partition. * I change the type to something other than FreeBSD * I install 3.2 into the second partition * I change the type of the first partition back to FreeBSD * I install os-bs or some other boot selector * And now, hopefully, I can simply boot either from the boot selector menu? I tried this, and the installation went through fine. But after installing 3.2, I get a `Missing operating system' when I try to boot the second partition (the first still has its type set to something other than FreeBSD, so it won't boot either). Robert, you seem quite knowledgeable about all this, and seem to have had considerable success. How do I get this right? I want to install 2.2.8 in one partition and 3.2 in another. If I don't change the fdisk partition type after installing 2.2.8, then sysinstall won't allow me to install the second OS (it complains when I try to make the root BSD partition that the boot loader can't handle it). If I do change the fdisk partition type first, the install is fine, but I can't boot afterwards, as described above. Missing operating system indicates that the first sector of the OS bootstrap (boot1 in the FreeBSD case) isn't flagged bootable: that is, it doesn't have the bytes 0x55 and 0xaa right at the end. Almost invariably, the cause of this is a mismatch between the disk geometry the BIOS is using, and what FreeBSD thought the geometry was during the install. (So the wrong sector is read by the MBR code.) The first partition is less sensitive to geometry mismatches than the others, since it has a starting CHS value of 0,1,1. That relies only on sectors per track and not number of heads. Because most modern BIOSes do CHS translation, the BIOS geometry is not always evident from the geometry reported by the drive, and FreeBSD may get this wrong, particularly if no existing partitions are defined. Since you are installing to a drive with no pre-existing non-FreeBSD partitions, I suspect sysinstall got the geometry wrong. Probably you should re-install and use the 'G' command in sysinstall's fdisk, after determining what geometry the BIOS is actually using. The best way to determine BIOS geometry in FreeBSD is to boot -v (but it should be from the old boot: prompt, not from loader(8) in 3.2R) and then check using dmesg(8) for BIOS Geometries information. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple versions of FreeBSD on one HDD
Because most modern BIOSes do CHS translation, the BIOS geometry is not always evident from the geometry reported by the drive, and FreeBSD may get this wrong, particularly if no existing partitions are defined. Since you are installing to a drive with no pre-existing non-FreeBSD partitions, I suspect sysinstall got the geometry wrong. Probably you should re-install and use the 'G' command in sysinstall's fdisk, after determining what geometry the BIOS is actually using. The best way to determine BIOS geometry in FreeBSD is to boot -v (but it should be from the old boot: prompt, not from loader(8) in 3.2R) and then check using dmesg(8) for BIOS Geometries information. Hmmm - perhaps it isn't possible then to do what I want (without losing most of the drive). The drive is 17Gb, consisting of 33416 cyls, 16 heads and 63 sectors. The BIOS reports 1023 cyls, 255 heads and 63 sectors - which is approximately 8Gb. This doesn't change if I change the BIOS mode between normal, large or LBA, nor if I make the disk type in the BIOS user defined and enter the real parameters (the BIOS is an Award BIOS v4.51PG, probably from about 1996). 1023/255/63 as the BIOS geometry is OK. It means that only about half the drive will be accessible through the BIOS CHS interface, but there is an 8.4GB CHS limit anyway. The BIOS CHS interface is mainly needed only for booting. Some OSes support booting using a more recent BIOS LBA interface, which doesn't (effectively) have a size limit. Windows 9x and FreeBSD can do that, provided your BIOS LBA support isn't broken. Because not many OSes (or boot managers) support BIOS LBA, how you set up your partitions, and what OSes you choose to install in which partitions, needs some thought. Personally, for maximum flexibility, I'd use FreeBSD's boot0 (or some commercial boot manager that also supports LBA). And I'd install 2.2.8 in partition 4, but using the boot blocks from -current. I'd also suggest ending partition 2 about 32-64M below cylinder 1024. So it isn't completely straightforward, but you can make use of the whole disk. I assume that if I set the gemoetry in fdisk to be the BIOS figures, that I will lose the other half of the disk? Use 2096/255/63 in sysinstall. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple versions of FreeBSD on one HDD
This works, but has the restriction that I have to enter a command line at the boot prompt to boot one of the two. I would much prefer partitions, as I can use a boot selector instead, and also change the default as appropriate. If you do have the installations in two seperate slices on the one disk, you should be able to use a boot selector to boot which ever slice you want. Just to elaborate on this: The new boot code is specifically designed to handle the separate slices case. Where multiple FreeBSD slices are found, it will prefer the one marked active; the old boot code always chose the first slice. For this to work optimally, it's best to replace your 2.2 boot blocks with ones from 3.2 (or otherwise ensure the 2.2 system occupies the first FreeBSD slice). You also need to use a boot manager which sets the "active" flag of the selected slice. I don't know if this will work with booteasy the boot manager that comes with FreeBSD by default, but there is a nice boot manager called OS Select (tools/os-bs.exe in the FreeBSD distribution I think). Both booteasy and boot0 (distributed in place of booteasy from 3.1R) work as well. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
By now the floppies for PowerBoot had come, so I tried installing that. I could now boot the HD, and PowerBoot can see the two partitions with freebsd installed (it even recognizes them as freebsd). Right now, my situation is that: - If I select WinNT at the PowerBoot menu, it comes up fine. Everything looks about as I'd expect. - If I select 2.2.8 at the PowerBoot menu, it comes up with one error message about "no /boot/loader", but then it comes right up in the 2.2.8 system. So this works fine, although it looks odd. You're using the new boot blocks for 2.2.8, and these always try to pass control to loader(8). To get rid of the message, create a /boot.config file with the line /kernel in it. - If I select 3.2 at the PowerBoot menu, it comes up with two messages about "invalid partition", one about "no boot loader", and then it can't automatically boot up anything. The interesting thing is that I'm in the 2.2.8 bootloader at this point, not the 3.2 one. It seems to want to boot 'da(0,a)/kernel', but if I type in 'da(0,e)/kernel', then it boots up fine. The problem here is a missing `a' partition. Seems like your first partition on that slice is `e'. There's a one-line patch to boot2 to get this working, but the standard version only autoboots from the `a' partition. My last partition is meant for installing OpenBSD, but I wasn't ready to do that yet. Later I was talking with one of the other guys here, and I went to show him what I did by trying to do another freebsd install into that 4th partition. Much to my surprise, it won't *let* me install into that partition. It's usually best to temporarily change fdisk partition types, so that sysinstall sees no existing FreeBSD slice on the drive. However, there may be other problems involved here as well. (note that I wanted to try PowerBoot because I also have a second hard disk, and I want to install Win98 on that one, along with BeOS and maybe some other OS's. It seemed to me that multi-disk situations could use something more than booteasy). Actually booteasy can handle two drives, and boot0 (which replaced booteasy in 3.1R) can handle more than that. However, the OSes on the higher drives must be capable of booting from the non-default drive. Most can do that -- even UnixWare -- though not Windows, which ignores the drive number passed in to it. So, for Windows, something that swaps drive letters is more suitable. So, my guess is that my primary problem is that I have only a vague idea of what I'm doing... Where is a good point to start looking for a better idea? I tried searching the web site for "multi-boot", but that didn't turn up much. I have a number of questions from doing this: 1. why does the install turn my HD unbootable? (invalid partition table). I didn't ask it to re-fdisk anything, and I didn't ask for it to change my boot loader. There are a number of possibilities, but one would have to look at a copy of the broken MBR to be sure. (The most usual reason for an "invalid partition table" message is multiple partitions flagged as active, or partitions that use the new-style active flag that is supported from Win95. This can be sorted out by booting from floppy or CD-ROM and using fdisk.) 2. I have the BIOS option on so I can boot off larger hard disks, and indeed it seems I can boot to the first three partitions. Why can't I get to that final one? You need to enable something more than the BIOS option. For instance, for FreeBSD, you need to enable LBA support in the boot blocks by means of a build option, and use boot0cfg(8) to turn on "packet" support in boot0. 3. Can I get it so that booting off the third partition will smoothly boot into 3.2-stable? Either patch boot2 or change to using an `a' partition. 4. given the rapidly-expanding size of HD's, would it be useful to support installs into DOS-style extended partitions? Or are they a problem which we're better off to avoid? I think support for extended partitions is inevitable (it's now the RedHat default), whether it really is a good idea or not. Technically, it violates the IBM specification that deals with fdisk partitions, though I'm not sure that matters very much. It will break some older OS/2 device drivers, for instance, though. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
I should mention that what I have on the disk right now (with
the three systems) isn't too critical, so it is alright if I
have to start over and reinstall everything. On the other
hand, reinstalling does get a little tiring after awhile, so
I want to have a better idea of what I'm doing before I take
another stab at this, to minimize the number of reinstalls
that I wind up doing.
I should also mention that while I do have a second 4-gig scsi
disk to use, it isn't actually installed yet.
Also, I did intend to have a freebsd 4-current system as part
of this multi-boot mix. I don't think I mentioned that last
time. Perhaps I should create one fdisk-style partition per
hard disk, and put all freebsd-related slices (for all the
different freebsd installs) into that one partition? Would
that make things go smoother? (particularly if I put all the
boot-related slices at the start of that fdisk-style partition)
Using BSD terminology, "slice" == fdisk partition, and partitions
('a', 'e', etc.) are just "partitions". Though, IIRC, SVR5 uses
the terms the other way round.
I'd suggest you install one system per fdisk partition. I had a
system set up with 2.0R, 2.1R, 2.2R and 3-current (as was) in
separate slices, when testing the new boot code.
Some people do prefer the multiple systems per slice approach,
though, which is all that used to be supported. So either can
be made to work.
--
Robert Nordier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
This works, but has the restriction that I have to enter a command line at the boot prompt to boot one of the two. I would much prefer partitions, as I can use a boot selector instead, and also change the default as appropriate. If you do have the installations in two seperate slices on the one disk, you should be able to use a boot selector to boot which ever slice you want. Just to elaborate on this: The new boot code is specifically designed to handle the separate slices case. Where multiple FreeBSD slices are found, it will prefer the one marked active; the old boot code always chose the first slice. For this to work optimally, it's best to replace your 2.2 boot blocks with ones from 3.2 (or otherwise ensure the 2.2 system occupies the first FreeBSD slice). You also need to use a boot manager which sets the active flag of the selected slice. I don't know if this will work with booteasy the boot manager that comes with FreeBSD by default, but there is a nice boot manager called OS Select (tools/os-bs.exe in the FreeBSD distribution I think). Both booteasy and boot0 (distributed in place of booteasy from 3.1R) work as well. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple versions of FreeBSD on one HDD
By now the floppies for PowerBoot had come, so I tried installing that. I could now boot the HD, and PowerBoot can see the two partitions with freebsd installed (it even recognizes them as freebsd). Right now, my situation is that: - If I select WinNT at the PowerBoot menu, it comes up fine. Everything looks about as I'd expect. - If I select 2.2.8 at the PowerBoot menu, it comes up with one error message about no /boot/loader, but then it comes right up in the 2.2.8 system. So this works fine, although it looks odd. You're using the new boot blocks for 2.2.8, and these always try to pass control to loader(8). To get rid of the message, create a /boot.config file with the line /kernel in it. - If I select 3.2 at the PowerBoot menu, it comes up with two messages about invalid partition, one about no boot loader, and then it can't automatically boot up anything. The interesting thing is that I'm in the 2.2.8 bootloader at this point, not the 3.2 one. It seems to want to boot 'da(0,a)/kernel', but if I type in 'da(0,e)/kernel', then it boots up fine. The problem here is a missing `a' partition. Seems like your first partition on that slice is `e'. There's a one-line patch to boot2 to get this working, but the standard version only autoboots from the `a' partition. My last partition is meant for installing OpenBSD, but I wasn't ready to do that yet. Later I was talking with one of the other guys here, and I went to show him what I did by trying to do another freebsd install into that 4th partition. Much to my surprise, it won't *let* me install into that partition. It's usually best to temporarily change fdisk partition types, so that sysinstall sees no existing FreeBSD slice on the drive. However, there may be other problems involved here as well. (note that I wanted to try PowerBoot because I also have a second hard disk, and I want to install Win98 on that one, along with BeOS and maybe some other OS's. It seemed to me that multi-disk situations could use something more than booteasy). Actually booteasy can handle two drives, and boot0 (which replaced booteasy in 3.1R) can handle more than that. However, the OSes on the higher drives must be capable of booting from the non-default drive. Most can do that -- even UnixWare -- though not Windows, which ignores the drive number passed in to it. So, for Windows, something that swaps drive letters is more suitable. So, my guess is that my primary problem is that I have only a vague idea of what I'm doing... Where is a good point to start looking for a better idea? I tried searching the web site for multi-boot, but that didn't turn up much. I have a number of questions from doing this: 1. why does the install turn my HD unbootable? (invalid partition table). I didn't ask it to re-fdisk anything, and I didn't ask for it to change my boot loader. There are a number of possibilities, but one would have to look at a copy of the broken MBR to be sure. (The most usual reason for an invalid partition table message is multiple partitions flagged as active, or partitions that use the new-style active flag that is supported from Win95. This can be sorted out by booting from floppy or CD-ROM and using fdisk.) 2. I have the BIOS option on so I can boot off larger hard disks, and indeed it seems I can boot to the first three partitions. Why can't I get to that final one? You need to enable something more than the BIOS option. For instance, for FreeBSD, you need to enable LBA support in the boot blocks by means of a build option, and use boot0cfg(8) to turn on packet support in boot0. 3. Can I get it so that booting off the third partition will smoothly boot into 3.2-stable? Either patch boot2 or change to using an `a' partition. 4. given the rapidly-expanding size of HD's, would it be useful to support installs into DOS-style extended partitions? Or are they a problem which we're better off to avoid? I think support for extended partitions is inevitable (it's now the RedHat default), whether it really is a good idea or not. Technically, it violates the IBM specification that deals with fdisk partitions, though I'm not sure that matters very much. It will break some older OS/2 device drivers, for instance, though. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple versions of FreeBSD on one HDD
I should mention that what I have on the disk right now (with
the three systems) isn't too critical, so it is alright if I
have to start over and reinstall everything. On the other
hand, reinstalling does get a little tiring after awhile, so
I want to have a better idea of what I'm doing before I take
another stab at this, to minimize the number of reinstalls
that I wind up doing.
I should also mention that while I do have a second 4-gig scsi
disk to use, it isn't actually installed yet.
Also, I did intend to have a freebsd 4-current system as part
of this multi-boot mix. I don't think I mentioned that last
time. Perhaps I should create one fdisk-style partition per
hard disk, and put all freebsd-related slices (for all the
different freebsd installs) into that one partition? Would
that make things go smoother? (particularly if I put all the
boot-related slices at the start of that fdisk-style partition)
Using BSD terminology, slice == fdisk partition, and partitions
('a', 'e', etc.) are just partitions. Though, IIRC, SVR5 uses
the terms the other way round.
I'd suggest you install one system per fdisk partition. I had a
system set up with 2.0R, 2.1R, 2.2R and 3-current (as was) in
separate slices, when testing the new boot code.
Some people do prefer the multiple systems per slice approach,
though, which is all that used to be supported. So either can
be made to work.
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: bootloader....
[Cross-posted: replying to -hackers] I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? There is some information in the FreeBSD handbook http://www.freebsd.org/handbook/ for example, "PC Memory Utilization" and "The FreeBSD Booting Process", though much of this is currently out-of-date. Otherwise, as maintainer of the low-level i386 boot code, I can probably help with specific issues. I'm not aware off-hand of any code anywhere that doesn't rely on the BIOS at all, though in some cases (eg. src/sys/i386/boot/netboot) BIOS support could fairly easily be dispensed with, by writing a bit of extra code. I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? See src/sys/boot/i386/boot0 in the FreeBSD source tree. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bootloader....
[Cross-posted: replying to -hackers] I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? There is some information in the FreeBSD handbook http://www.freebsd.org/handbook/ for example, PC Memory Utilization and The FreeBSD Booting Process, though much of this is currently out-of-date. Otherwise, as maintainer of the low-level i386 boot code, I can probably help with specific issues. I'm not aware off-hand of any code anywhere that doesn't rely on the BIOS at all, though in some cases (eg. src/sys/i386/boot/netboot) BIOS support could fairly easily be dispensed with, by writing a bit of extra code. I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? See src/sys/boot/i386/boot0 in the FreeBSD source tree. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: /usr/src/sys/i386/boot/netboot problem during compile
Dima wrote: I have a problem compiling of files needed for network boot on a FreeBSD 3.2-Release. as I understand I need this file (scrt0.o) because netboot makes *com files only from a.out files, not from ELF. In sources I found where is this file compiled - /usr/src/lib/csu. But it will only compile if I manually set flag FREEBSD_AOUT. And even after this, compiling netboot gives me: ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) *** Error code 1 Please write me what I am doing wrong, and how can I get this *.com and *.rom files neede for network boot? This is legacy code which is being kept around until loader(8) supports equivalent functionality. For now, I suggest you use "etherboot" in the ports collection. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Sheldon Hearn wrote:
Could someone have a look at the patch proposed on PR 12852? I
understand the motivation, since it seems reasonable to me that ferror()
should return EBADF after an attempt to read from stdout. At the moment,
ferror() returns 0 after an attempt to read from stdout.
There's no question this needs changing. An ISO example actually
reads along the lines of:
while (!feof(fp) !ferror(fp))
fscanf(fp, ...);
with no further provision for error-detection. Applied to stdout,
this never terminates.
The SVID wording is more definite than ISO in discussing this ("less
than nitems only if a read error or end-of-file is encountered"),
but mostly the present behavior just conflicts with sense and
practice.
--
Robert Nordier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Including isa/isareg.h in sys/i386/boot/biosboot/serial.S
In the kernel config file you can use symbolic names for the various COM ports, IO_COM1, IO_COM2, and so on. These seem be defined in sys/isa/isareg.h. If you want to configure FreeBSD to boot from a serial console you have to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the defines here, you have to use 0x3F8, 0x2F8, and so on. As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down to sys/i386/boot/biosboot/serial.S. So, why not apply the following trivial patch to serial.S, so that /etc/make.conf can instead contain BOOT_COMCONSOLE_PORT= IO_COM2 which is just slightly friendlier? I'm not what you'd call a kernel hacker, so this might be a stupid idea. . . The sys/i386/boot/biosboot code is going away shortly. The corresponding non-legacy code is sys/boot/i386/boot2, though there are various other places in the new boot code this is used as well: kgzldr and libi386, for the i386. A suggestion similar to yours was discussed off the lists around seven months ago, but the majority view was that the perceived advantages didn't completely justify the required changes and potential confusion. Since the boot code works with the BIOS, the early binding of COM2 to 0x2f8 is probably not justified. COM2 could -- and maybe should -- mean "the port BIOS is using for COM2" which may be something quite different than 0x2f8. There's actually a fairly loose coupling between the kernel and the boot code, and making use of kernel configuration conventions, where the semantics may end up being just slightly different, is probably a less useful idea than it seems. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /usr/src/sys/i386/boot/netboot problem during compile
Dima wrote: I have a problem compiling of files needed for network boot on a FreeBSD 3.2-Release. as I understand I need this file (scrt0.o) because netboot makes *com files only from a.out files, not from ELF. In sources I found where is this file compiled - /usr/src/lib/csu. But it will only compile if I manually set flag FREEBSD_AOUT. And even after this, compiling netboot gives me: ld: /usr/lib/scrt0.o: malformed input file (not rel or archive) *** Error code 1 Please write me what I am doing wrong, and how can I get this *.com and *.rom files neede for network boot? This is legacy code which is being kept around until loader(8) supports equivalent functionality. For now, I suggest you use etherboot in the ports collection. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bin/12852: Non-standard behavior of fread(3)
Sheldon Hearn wrote: Could someone have a look at the patch proposed on PR 12852? I understand the motivation, since it seems reasonable to me that ferror() should return EBADF after an attempt to read from stdout. At the moment, ferror() returns 0 after an attempt to read from stdout. There's no question this needs changing. An ISO example actually reads along the lines of: while (!feof(fp) !ferror(fp)) fscanf(fp, ...); with no further provision for error-detection. Applied to stdout, this never terminates. The SVID wording is more definite than ISO in discussing this (less than nitems only if a read error or end-of-file is encountered), but mostly the present behavior just conflicts with sense and practice. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Including isa/isareg.h in sys/i386/boot/biosboot/serial.S
In the kernel config file you can use symbolic names for the various COM ports, IO_COM1, IO_COM2, and so on. These seem be defined in sys/isa/isareg.h. If you want to configure FreeBSD to boot from a serial console you have to set BOOT_COMCONSOLE_PORT in /etc/make.conf -- you can't use the defines here, you have to use 0x3F8, 0x2F8, and so on. As far as I can tell, BOOT_COMCONSOLE_PORT eventually gets passed down to sys/i386/boot/biosboot/serial.S. So, why not apply the following trivial patch to serial.S, so that /etc/make.conf can instead contain BOOT_COMCONSOLE_PORT= IO_COM2 which is just slightly friendlier? I'm not what you'd call a kernel hacker, so this might be a stupid idea. . . The sys/i386/boot/biosboot code is going away shortly. The corresponding non-legacy code is sys/boot/i386/boot2, though there are various other places in the new boot code this is used as well: kgzldr and libi386, for the i386. A suggestion similar to yours was discussed off the lists around seven months ago, but the majority view was that the perceived advantages didn't completely justify the required changes and potential confusion. Since the boot code works with the BIOS, the early binding of COM2 to 0x2f8 is probably not justified. COM2 could -- and maybe should -- mean the port BIOS is using for COM2 which may be something quite different than 0x2f8. There's actually a fairly loose coupling between the kernel and the boot code, and making use of kernel configuration conventions, where the semantics may end up being just slightly different, is probably a less useful idea than it seems. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Jamie Howard ([EMAIL PROTECTED]), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
A couple of general problems:
o Too many diagnostics have "Undefined error: 0" appended.
Particularly in the case of "err(2, re_error)" in file.c,
you probably want to look at using errx() instead.
o Errors other than "no match" need to return a exit status
of 2: some in file.c and util.c are returning 1.
A more general concern is whether Henry Spencer's regex routines
-- at least in our present "alpha-quality" version -- are up to
supporting a grep without much further debugging. I don't recall
many of the problems I found when I last looked at these, though
here are two, after 5 minutes playing:
echo xx | grep '\(x\{1,2\}\)\1'
echo x | grep '[--x]'
--
Robert Nordier
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: replacing grep(1)
Jamie Howard (howar...@wam.umd.edu), with a little help from yours
truly, has written a BSD-licensed version of grep(1) which has all the
functionality of our current (GPLed) implementation, plus a little
more, in one seventh the source code and one fourth the binary code.
I move that we replace GNU grep in our source tree with this
implementation, once it's been reviewed by all concerned parties.
A couple of general problems:
o Too many diagnostics have Undefined error: 0 appended.
Particularly in the case of err(2, re_error) in file.c,
you probably want to look at using errx() instead.
o Errors other than no match need to return a exit status
of 2: some in file.c and util.c are returning 1.
A more general concern is whether Henry Spencer's regex routines
-- at least in our present alpha-quality version -- are up to
supporting a grep without much further debugging. I don't recall
many of the problems I found when I last looked at these, though
here are two, after 5 minutes playing:
echo xx | grep '\(x\{1,2\}\)\1'
echo x | grep '[--x]'
--
Robert Nordier
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: make fails in 3.2-RELEASE for netboot
I found it when I went searching however I still can't get the netboot to compile as it was designed for aout. Any ideas of why it wasn't moved to elf along with the rest of the OS? Or if not how *I* can port it to elf instead? The intention is that loader(8) will provide the same functionality, and the framework is already in place for this. I suggest you use etherboot in the ports collection, at least until the loader support is completed. -- Robert Nordier To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make fails in 3.2-RELEASE for netboot
I found it when I went searching however I still can't get the netboot to compile as it was designed for aout. Any ideas of why it wasn't moved to elf along with the rest of the OS? Or if not how *I* can port it to elf instead? The intention is that loader(8) will provide the same functionality, and the framework is already in place for this. I suggest you use etherboot in the ports collection, at least until the loader support is completed. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
The standard boot partition selection softwre also works fine booting windoze OS's from other disks. All you need to do is set the disk id in the DOS MBR to the correct number, 0x81 for your second disk. That's the only thing that MS doesn't do correctly whe installing the OS on the non-primary disk. I used to do this a long time ago to boot FreeBSD of the C drive and the other stuff off of second C drive. I'll try that this weekend. Preumably I can just do this under FreeBSD using fdisk? You cannot do it using fdisk. I tonly manipulates the parition table poriton of the MBR. The bios device number is in portion before the partition table. I hesitate to just give an offset and say poke away, so I'd look for a disk editing tool like Norton Disk Editor. That's what I used when I last did this a few years ago. In the standard Microsoft way of doing things, the BIOS drive number is recorded both in the MBR (sector 0 of the disk) and in the DOS boot sector (sector 0 of the fdisk partition). A Microsoft-style MBR gets the drive number from the byte at offset 0 of the partition entry (field dp_flag of structure dos_partition in /sys/sys/disklabel.h). This is usually known as the active flag, and all standard fdisk utilities set this to 0x80 (corresponding to BIOS fixed drive 0) when flagging a partition as active. This can be patched by hand to some other value (eg. 0x81 for BIOS fixed drive 1) but in a standard pre-Win95 OSR2 MBR this causes problems, as the MBR code validates the partition table entries, and will respond to the 0x81 with the message Invalid partition table followed by a hang.
Re: Changing Bootmgr display
I notice that v1.10 is up in -current...does this patch still apply? Dennis v1.10 is just a variation on this patch, with support for dynamic configuration using boot0cfg(8) rather than by way of a build option. For instance boot0cfg -m 0xd da0 will cause the second partition to be ignored. (Needs boot0cfg.c v1.5 as well, though.) RN At 06:58 PM 6/19/99 +0200, Robert Nordier wrote: Dennis wrote: F1: FreeBSD F2: LINUX F3: FreeBSD F3 is a non-bootable file system...is there a way to get the boot manager to only display F1 and F2? At the moment, no. Though you could use the following patch, which allows the slices to be individually disabled. (The B0FLAGS setting in Makefile enables slices 1 and 2; use B0FLAGS=0xf to enable all four slices.) If worthwhile, boot0cfg(8) can later be modified to set/unset the flags, rather than using a build option. Note that the patch is against boot0.s rev 1.9 committed yesterday. -- Robert Nordier --- Makefile.origSat Jun 19 18:48:42 1999 +++ Makefile Sat Jun 19 18:43:07 1999 @@ -8,7 +8,7 @@ M4?=m4 -B0FLAGS=0x0 +B0FLAGS=0x3 B0TICKS=0xb6 ORG=0x600 --- boot0.s.orig Sat Jun 19 18:51:10 1999 +++ boot0.s Sat Jun 19 18:51:21 1999 @@ -71,6 +71,8 @@ movwir(partbl+0x4,_bx) # Partition table xorl %edx,%edx # Item number main.3: movbr1(_ch,-0x4,_bx_) # Zero active flag +btwr1(_dx,_FLAGS,_bp_) # Entry enabled? +jnc main.5 # No movb0r(_bx_,_al)# Load type movwir(tables,_di) # Lookup tables movb $TBL0SZ,%cl# Number of entries To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Changing Bootmgr display
Dennis wrote: F1: FreeBSD F2: LINUX F3: FreeBSD F3 is a non-bootable file system...is there a way to get the boot manager to only display F1 and F2? At the moment, no. Though you could use the following patch, which allows the slices to be individually disabled. (The B0FLAGS setting in Makefile enables slices 1 and 2; use B0FLAGS=0xf to enable all four slices.) If worthwhile, boot0cfg(8) can later be modified to set/unset the flags, rather than using a build option. Note that the patch is against boot0.s rev 1.9 committed yesterday. -- Robert Nordier --- Makefile.orig Sat Jun 19 18:48:42 1999 +++ MakefileSat Jun 19 18:43:07 1999 @@ -8,7 +8,7 @@ M4?= m4 -B0FLAGS=0x0 +B0FLAGS=0x3 B0TICKS=0xb6 ORG= 0x600 --- boot0.s.origSat Jun 19 18:51:10 1999 +++ boot0.s Sat Jun 19 18:51:21 1999 @@ -71,6 +71,8 @@ movwir(partbl+0x4,_bx) # Partition table xorl %edx,%edx # Item number main.3:movbr1(_ch,-0x4,_bx_) # Zero active flag + btwr1(_dx,_FLAGS,_bp_) # Entry enabled? + jnc main.5 # No movb0r(_bx_,_al)# Load type movwir(tables,_di) # Lookup tables movb $TBL0SZ,%cl# Number of entries To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Changing Bootmgr display
Warner Losh wrote: In message 199906191602.maa10...@etinc.com Dennis writes: : F3 is a non-bootable file system...is there a way to get the boot manager : to only display F1 and F2? More generally, I'd like my Win98 partition to be identified as Win98, not . Also, is there a list of partition types to ignore somehwere? My suspend partition also shows up as . The present boot manager is limited in size to 446 bytes, so there's just not space to provide an adequate list of known partitions. The best solution is probably to customise the sources or use a proper boot manager. (I see that at the FreeBSD Mall, they're offering Partition Magic and System Commander with FreeBSD.) To ignore a partition by type, see the following patch as an example (we ignore type 0x42). -- Robert Nordier --- boot0.s.origSat Jun 19 19:50:23 1999 +++ boot0.s Sat Jun 19 19:50:44 1999 @@ -24,7 +24,7 @@ .set PRT_OFF,0x1be # Partition table - .set TBL0SZ,0x3 # Table 0 size + .set TBL0SZ,0x4 # Table 0 size .set TBL1SZ,0xa # Table 1 size .set MAGIC,0xaa55 # Magic: bootable @@ -231,7 +231,7 @@ # Partition type tables tables: - .byte 0x0, 0x5, 0xf + .byte 0x0, 0x5, 0xf, 0x42 .byte 0x1, 0x4, 0x6, 0xb, 0xc, 0xe, 0x63, 0x83 .byte 0xa5, 0xa6 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Dual boot with LINUX
Dennis wrote: Can linux be booted using the freebsd boot manager? Lilo always seems to want to install itself. Provided you install Linux in a primary fdisk partition (slice 1-4), it should work OK. The RedHat default is to install to an extended fdisk partition, and we don't support booting from those. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Dual boot with LINUX
Dennis wrote: At 10:07 PM 6/18/99 +0200, you wrote: Dennis wrote: Can linux be booted using the freebsd boot manager? Lilo always seems to want to install itself. Provided you install Linux in a primary fdisk partition (slice 1-4), it should work OK. The RedHat default is to install to an extended fdisk partition, and we don't support booting from those. Well the problem with *should* is that lilo installs itself whenever you run it, and you have to run it to install a new kernel. So I was hoping to find someone that has actually done it. Should just implies YMMV: I have booted Linux with the freebsd boot manager. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Why we need two distinct MBRs in the sources?
1 Could it be possible to unite these ones in /src/sys/boot/i386/mbr/ ? It could be possible, yes. :) - Jordan Seems a good idea: I'll do that, unless of course Ruslan wants to do it himself. At least one of the present MBRs is a bit too strictly correct, and supports booting only from hard drive 0, which is all IBM/Microsoft officially support. It'd probably make life a bit easier to allow booting from any hard drive. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
