Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: While you're enhancing cdboot anyway, can I ask how complicated it would be to make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - but I'd be prepared to try and look at this myself if no-one else is interested). As it stands, the only way I've found to do a serial-console CD-based installation is by enabling the serial console in /boot/loader.conf, by which time you've already missed several useful points, particularly the entry to BIOS settings (if you have a serial-capable BIOS). cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Thursday 11 December 2008 10:45:41 Giorgos Keramidas wrote: On Thu, 11 Dec 2008 08:37:26 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: While you're enhancing cdboot anyway, can I ask how complicated it would be to make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - but I'd be prepared to try and look at this myself if no-one else is interested). As it stands, the only way I've found to do a serial-console CD-based installation is by enabling the serial console in /boot/loader.conf, by which time you've already missed several useful points, particularly the entry to BIOS settings (if you have a serial-capable BIOS). cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. Sorry, of course you're right: I'm talking nonsense. It's the stage immediately after that that isn't available. I wish I could remember why I thought that had caused me a problem once. Certainly there's a big chunk of the boot process that is accessible through a serial console on a disk-based boot that's not available on a serial-console boot. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. Sorry, of course you're right: I'm talking nonsense. It's the stage immediately after that that isn't available. I wish I could remember why I thought that had caused me a problem once. Certainly there's a big chunk of the boot process that is accessible through a serial console on a disk-based boot that's not available on a serial-console boot. I'm still not sure what sort of `serial console boot' we are talking about here. What's the difference between a `serial console on a disk-based boot' and a `serial console boot'? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Thursday 11 December 2008 14:42:46 Giorgos Keramidas wrote: On Thu, 11 Dec 2008 10:52:49 +0200, Jonathan McKeown [EMAIL PROTECTED] wrote: cdboot runs long after the prompt for BIOS setup. I don't think we can modify cdboot to add serial console support to systems whose BIOS setup doesn't support it. Sorry, of course you're right: I'm talking nonsense. It's the stage immediately after that that isn't available. I wish I could remember why I thought that had caused me a problem once. Certainly there's a big chunk of the boot process that is accessible through a serial console on a disk-based boot that's not available on a serial-console boot. I'm still not sure what sort of `serial console boot' we are talking about here. What's the difference between a `serial console on a disk-based boot' and a `serial console boot'? Sorry, there's been an element of ``ready - fire - aim'' about my messages today - I'm trying to do several other things at once. Let me get a serial-boot CD out and play with it - it's a while since I did a headless install so I'm working from a vague memory. I think what I'm saying is that there are several stages in the boot process; when booting from a hard drive and using a serial console, all the stages are accessible: but when booting from a CD, only the last stage is. I seem to remember that causing me a problem with a headless machine once upon a time (perhaps there was an error at an early stage, with the first hard drive failing, and I couldn't see loader(8) to tell it to boot off the second drive which was a mirror of the first?). Certainly I've taken part in a couple of discussions in -questions over the last year or two in which people want to know how to make a serial-capable install CD - which is not as straightforward as it might be if there were a serial-capable cdboot (along the same lines as putting boot0sio instead of boot0 on a hard drive). Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
This sounds and looks cool, diff looks OK (haven't applied), Luigi's comments seem well thought out and expressed. cheers BMS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Monday 08 December 2008 06:51:19 pm Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: Hi, Below please find patch that enhances cdboot with two compile-time options: ... Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. I don't think this is very useful because CDs are read-only. You can just as easily build a different cdboot rather than having to write some custom cdbootcfg util to patch the binary. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); I don't imagine anyone will know to press a key to get verbose messages, and the CD boot process is quick enough you would have to add an artificial delay to it to allow for the keypress. 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? No, because he relocates it, $start is now the relocated address, but the BIOS loads it at LOAD which is now != $start. Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx I prefer the existing code to make sure and copy the full boot loader, whatever it's size is. Maxim, My only comment is to please make the new block comment match the style of the existing block comments by having '#\n' lines before and after. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
While you're enhancing cdboot anyway, can I ask how complicated it would be to make cdboot serial-console capable? (I'm not a C programmer, I'm a sysadmin - but I'd be prepared to try and look at this myself if no-one else is interested). As it stands, the only way I've found to do a serial-console CD-based installation is by enabling the serial console in /boot/loader.conf, by which time you've already missed several useful points, particularly the entry to BIOS settings (if you have a serial-capable BIOS). Jonathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: Hi, Below please find patch that enhances cdboot with two compile-time options: ... Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote: Hi, Below please find patch that enhances cdboot with two compile-time options: ... Any comments/suggestions are appreciated. If there are no objections I would like to commit the change. The long-term goal is to make CDBOOT_PROMPT default mode for installation CD. http://sobomax.sippysoft.com/~sobomax/cdboot.diff Looks good. Some comments: Thank you for the review and comments. Please see my answers below. 1. since there is plenty of space in the cdboot sector, why don't you make the two option always compiled in, controlling which one to activate through flags in the bootsector itself, to be set patching the binary sector itself using a mechanism similar to boot0cfg. Of course you cannot alter a cdrom after you burn it, but it makes it easier to build CDs with one or the other defaults, patching cdboot or the iso image itself before creating/burning it. 2. in fact, the 'silent' option could be disabled at runtime by pressing some key (e.g. adding a short wait loop before proceeding; if this is meant for custom, unattended CDs the extra delay should not matter much); Good idea, I will see if I can put that in. In fact this behavior should have to be optional as well, since one of the uses for the silent option here is to provide tamper-resistant boot process on custom hardware. 3. one nitpick -- in one of the first chunks you replace $start with $LOAD, but if i am not mistaken operation depends on $LOAD = $start, so why don't you always use the same ? No, they are not the same. $LOAD is address where BIOS loads boot sector, which is 0x7c00 by default (you can configure it when building CD-ROM, which is why it's an option). On the other hand, $start is address where code is compiled to be located, which is 0x0600. Also in terms of relocation size, wouldn't it be the case of hardwiring the size of the cd boot sector: - mov $((end_init - start)/2),%cx + mov 1024,%cx Well, I don't see the reason to hardwire this. CDROM boot code can be of different size (within certain limits of course, to be selected when building ISO), it's not limited to fixed number of sectors like boot[012]. 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by point to partition entry exactly? Right now it points to the beginning on MBR. -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Mon, 08 Dec 2008 16:29:04 -0800, Maxim Sobolev [EMAIL PROTECTED] wrote:
Luigi Rizzo wrote:
On Mon, Dec 08, 2008 at 02:40:41PM -0800, Maxim Sobolev wrote:
Hi,
Below please find patch that enhances cdboot with two compile-time options:
...
Any comments/suggestions are appreciated. If there are no objections I
would like to commit the change. The long-term goal is to make
CDBOOT_PROMPT default mode for installation CD.
http://sobomax.sippysoft.com/~sobomax/cdboot.diff
Looks good. Some comments:
Thank you for the review and comments. Please see my answers below.
1. since there is plenty of space in the cdboot sector, why don't you
make the two option always compiled in, controlling which one to
activate through flags in the bootsector itself, to be set
patching the binary sector itself using a mechanism similar to
boot0cfg.
Of course you cannot alter a cdrom after you burn it,
but it makes it easier to build CDs with one or the other defaults,
patching cdboot or the iso image itself before creating/burning it.
2. in fact, the 'silent' option could be disabled at runtime by
pressing some key (e.g. adding a short wait loop before proceeding;
if this is meant for custom, unattended CDs the extra delay should not
matter much);
Good idea, I will see if I can put that in. In fact this behavior should
have to be optional as well, since one of the uses for the silent
option here is to provide tamper-resistant boot process on custom
hardware.
Nice pair of features :-)
If there are no pressing space constraints maybe we can build both
options in by default, but still make them opt-out when necessary?
With a bit of makefile glue we can make it possible to compile with an
`src.conf' that includes:
WITH_CDBOOT_SILENT=1
WITHOUT_CDBOOT_PROMPT=1
This way the defaults can include support for both options, but we can
conditionally compile *out* the bits that are not needed for some custom
installation.
Something like this can define one or both of these options in CFLAGS,
depending on what `src.conf' contains:
# When CDBOOT_SILENT is set, the cdboot doesn't produce any messages except
# Loading, please wait... and it also passes RBX_MUTE flag to the next
# stage to silence it as well. This is intended for custom installations
# where end-user is not required to see any messages or interfere with the
# boot process.
.if ${MK_CDBOOT_SILENT} != no
CFLAGS+= -DCDBOOT_SILENT
.endif
# When CDBOOT_PROMPT is enabled the cdboot behaves like windows xp or vista
# cd loader, that is it reads MBR from the first hard drive in the system
# and if the MBR is bootable (i.e. drive has some other operating system
# installed on it) then it presents user with Press any key to boot from
# CD prompt and waits for 20 seconds. If key is not pressed then the
# control is passed to the MBR, otherwise CD is booted. This is intended for
# installation CD to allow unattended mode and also helps when installation
# CD has been unintentionally left in the drive of the machine that is set
# to boot off CD.
.if ${MK_CDBOOT_PROMPT} != no
CFLAGS+= -DCDBOOT_PROMPT
.endif
The defaults for ${MK_CDBOOT_XXX} will have to be explicitly set in
`src/share/mk/bsd.own.mk', near line 281:
281 #
282 # MK_* options which default to yes.
283 #
284 .for var in \
...
But that shouldn't be a problem, AFAICT :-)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: Luigi Rizzo wrote: ... 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by point to partition entry exactly? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to relocate: it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Enhancing cdboot [patch for review]
Luigi Rizzo wrote: On Mon, Dec 08, 2008 at 04:29:04PM -0800, Maxim Sobolev wrote: Luigi Rizzo wrote: ... 4. another nitpick -- the value you pass in %si to the MBR does not seem to point to anything useful. As discussed about boot0.S and the followup in the mailing lists, there seems to be no standard but at least some MBR expect %si to point to a partition entry, so you should probably initialize one in a way similar way to that used by boot0.S Hmm, maybe I misunderstood it then. What do you mean by point to partition entry exactly? Right now it points to the beginning on MBR. ok, so here is what I know. Even though there is no standard, at least ldlinux.sys and perhaps other bootloaders expect %si to point to a 16-byte record containing the partition descriptor (same structure as one of the 4 records at 0x1be in the MBR) for the partition they were loaded from. ldlinux.sys uses this info to relocate: it knows the location of the other sectors of ldlinux.sys relative to the beginning of the partition, and uses the start-of-partition from the record at %si to compute these locations in terms of absolute disk positions. Note that in principle a MBR does not need this info -- even if it is a multi-sector boot code such as boot0ext, it may well assume to be located at offset 0. On the other hand if the code on the MBR uses %si, then you should set the entry so that at least the starting CHS and LBA info point to the first sector on disk, i.e. CHS=0,0,1 and LBA=0. In practical terms -- make %si point to a 16-byte area of memory containing all 0's except for the byte representing the sector number for the start of the partition. See the code in a recent sys/boot/i386/boot0/boot0.S which gives some details on this. I see, thank you for the explanation. It looks like it only makes sense for multi-stage boot loaders, when the stage has been loaded from some location within the disk and it needs some clue to determine where it has came from. In this case we simply emulate BIOS loading MBR, and from what I've read here MBR code should make no assumptions with regard to %si, so that I would just set it to zero. Do you think it could create any issues? -Maxim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
