Eugene Grosbein wrote:
I also always use boot0 for my NanoBSDs as I need safe way for remote
upgrades, so have two code slices. And I always use these knobs:
NANO_BOOTLOADER="boot/boot0"
NANO_BOOT0CFG="-o packet -s 1 -m 3 -t 36"
...
Good p
On Fri, Sep 12, 2008 at 05:53:39PM +0100, Bruce M. Simpson wrote:
>So it appears the "active" flag was not being set for the first
> partition, it seems NanoBSD's fdisk script didn't set it; that should
> probably get patched, as this was the root cause of the USB booting delay.
I also alwa
Bruce M. Simpson wrote:
Woops, I noticed right after I sent this message, that there was an
I/O error writing to the USB key from dd in my shell -- I think I was
using a 32768 block size instead of 16384 which might account for the
problem.
I'll be sure to try this all again after I've had som
Bruce M Simpson wrote:
>
> Eugene Grosbein wrote:
> > For me, it helps to include these knobs to Nano config file:
> >
> > CONF_WORLD='
> > BOOT_MBR_FLAGS=0x0
> > BOOT_BOOT1_FLAGS=0x0
> > ...
> > '
> >
>
> I added this to the CONF_WORLD in my config file. Unfortunately this
> seems to break USB b
Woops, I noticed right after I sent this message, that there was an I/O
error writing to the USB key from dd in my shell -- I think I was using
a 32768 block size instead of 16384 which might account for the problem.
I'll be sure to try this all again after I've had some sleep.
cheers
BMS
Eugene Grosbein wrote:
For me, it helps to include these knobs to Nano config file:
CONF_WORLD='
BOOT_MBR_FLAGS=0x0
BOOT_BOOT1_FLAGS=0x0
...
'
I added this to the CONF_WORLD in my config
On Thu, 11 Sep 2008 16:49:56 BST, Bruce M Simpson wrote:
> Interesting, that's classic USB-HDD geometry (255H, 63S). Can you
> tell me what make, model of stick this is?
It's Kingston DTI/512
# diskinfo -v da0
da0
512 # sectorsize
512753664 # mediasize in bytes (
On Thu, Sep 11, 2008 at 01:55:01PM +0100, Bruce M Simpson wrote:
> I have hacked NanoBSD locally to deal with generation of images for
> booting off USB keys. I am using the RELENG_7 branch as real-mode BTX
> support is necessary to support USB boot.
>
> During testing I noticed that whilst the
[Ccing to list to track up thread]
Douglas Berry wrote:
Perhaps this doesn't help... I do RELENG_7 based images
for USB keys/CDROM using the FreesBIE toolkit, and haven't
noticed such delays. I do fill the stick 'tho. Here's
fdisk output...
*** Working on device /dev/md4 ***
paramete
Bruce M. Simpson wrote:
Bruce M Simpson wrote:
...
During testing I noticed that whilst the images eventually boot,
there is an extremely long delay before doing so, between when the
BIOS reads the boot sector and when the BTX loader messages appear.
I can reproduce the boot delay condition
Bruce M Simpson wrote:
...
During testing I noticed that whilst the images eventually boot, there
is an extremely long delay before doing so, between when the BIOS
reads the boot sector and when the BTX loader messages appear.
P.S. It appears none of QEMU, VMware 3.0, or VirtualBox 1.6.6 are
Hi,
I have hacked NanoBSD locally to deal with generation of images for
booting off USB keys. I am using the RELENG_7 branch as real-mode BTX
support is necessary to support USB boot.
During testing I noticed that whilst the images eventually boot, there
is an extremely long delay before doi
12 matches
Mail list logo
