Re: Editing boot.conf to set tty to fb0 in miniroot69.img
On 2021-05-11, Paul W. Rankin wrote: > Hello, > > I am trying to install OpenBSD on a Raspberry Pi 4B without the > assistance of the serial console. The Pi firmware is set to boot from > USB. I have arm64 miniroot69 on a USB and the system boots; I see the > "BOOT>" prompt, but my USB keyboard does not appear to be recognised at > this point in boot, so I cannot interrupt and set tty to fb0. The boot > then proceeds to the serial console (i.e. blank screen). > > The thought occurred that it may be possible to change boot.conf in the > miniroot69 image to set tty to fb0 but so far my attempts have been > unsuccessful. I have tried... > > ...on my macOS system, I tried many variations of the following without > success: > > # qemu-system-aarch64 -machine raspi3 -hda /dev/disk2 > # qemu-system-aarch64 -machine virt -hda /dev/disk2 > # qemu-system-aarch64 -machine raspi3 -drive > file=miniroot69.img,format=raw > # qemu-system-aarch64 -machine virt -drive file=/dev/disk2,format=raw > > The qemu system just presents a blank screen. Nothing on serial or > parallel screens. > > ...on my OpenBSD server, I tried mounting the miniroot69.img and > altering boot.conf directly: > > # vnconfig vnd0 miniroot69.img > # mount /dev/vnd0a /mnt > > But this just presents: > > # ls -1 > bsd > bsd.rd > > Does anyone have any suggestion of how I might achieve editing boot.conf > on the miniroot69 image or otherwise how to boot the Raspberry Pi 4B > into fb0? That would go on the booted disk, not inside the ramdisk kernel, so cd /mnt mkdir etc echo set tty fb0 > etc/boot.conf Pretty sure I tested that scenario and it worked without boot.conf though I'm not sure if it was with the pftf firmware or U-Boot.
Editing boot.conf to set tty to fb0 in miniroot69.img
Hello, I am trying to install OpenBSD on a Raspberry Pi 4B without the assistance of the serial console. The Pi firmware is set to boot from USB. I have arm64 miniroot69 on a USB and the system boots; I see the "BOOT>" prompt, but my USB keyboard does not appear to be recognised at this point in boot, so I cannot interrupt and set tty to fb0. The boot then proceeds to the serial console (i.e. blank screen). The thought occurred that it may be possible to change boot.conf in the miniroot69 image to set tty to fb0 but so far my attempts have been unsuccessful. I have tried... ...on my macOS system, I tried many variations of the following without success: # qemu-system-aarch64 -machine raspi3 -hda /dev/disk2 # qemu-system-aarch64 -machine virt -hda /dev/disk2 # qemu-system-aarch64 -machine raspi3 -drive file=miniroot69.img,format=raw # qemu-system-aarch64 -machine virt -drive file=/dev/disk2,format=raw The qemu system just presents a blank screen. Nothing on serial or parallel screens. ...on my OpenBSD server, I tried mounting the miniroot69.img and altering boot.conf directly: # vnconfig vnd0 miniroot69.img # mount /dev/vnd0a /mnt But this just presents: # ls -1 bsd bsd.rd Does anyone have any suggestion of how I might achieve editing boot.conf on the miniroot69 image or otherwise how to boot the Raspberry Pi 4B into fb0? Much thanks, -- Paul W. Rankin https://bydasein.com The single best thing you can do for the world is delete your social media accounts.
Re: I hold the ctrl key and boot still runs my boot.conf
I guess this would explain it.
/usr/src/sys/arch/amd64/stand/efiboot/efiboot.c:
efi_cons_getshifts(dev_t dev)
{
/* XXX */
return (0);
}
Any reason for this?
-alfred
I hold the ctrl key and boot still runs my boot.conf
boot(8) man page says: "boot.conf processing can be skipped, and the automatic boot cancelled, by holding down either Control key as boot starts." I hold the ctrl key and boot still runs my boot.conf. Is anyone else also having this issue? # uname -a OpenBSD upgrade.lan 6.7 GENERIC.MP#182 amd64 -alfred
Re: sysupgrade failure due to boot.conf
Theo wrote: > Interesting. Wonder how common this is. It could possibly come back in some future bios update bug/change as well but very very rarely I would expect. This problem showed up for me in a different way as well; My clock would always drift and ntpd would report that it was always trying to adjust the clock but would never get closer to the target time. Now I can explain why since my bios clock was stuck. > Should our code eventually advance if it has done millions of inspection loops? I saw code in there in /usr/src/sys/stand/boot/cmd.c that counted 1000 before calling getsecs() so I would weary about adding more counts: /* check for timeout expiration less often (for some very constrained archs) */ while (!cnischar()) if (!(i++ % 1000) && (getsecs() >= tt)) break; I don't know the amd64 architecture too well but I would think there would be a more reliable timer that can be used instead of the system clock. Only relative time is needed for the timeout to operate correctly. Or possibly use some known tick. http://books.gigatux.nl/mirror/kerneldevelopment/0672327201/ch10lev1sec2.html > If you can re-create the condition, can you propose a diff which does that? I would if I can get someone to point me to a good timer or tick to use. -alfred On Wed, Jul 15, 2020 at 9:43 PM Theo de Raadt wrote: > Alfred Morgan wrote: > > > Theo wrote: > > > Figure out how to build and install. It is not hard to test. > > > > Thank you, I did as you suggested and I was able to narrow down the issue > > to this line of code in /usr/src/sys/arch/amd64/stand/efiboot/efiboot.c: > > > > EFI_CALL(ST->RuntimeServices->GetTime, , NULL); > > > > > > The GetTime call would always return the same time. It turned out that my > > BIOS clock was frozen and was not ticking so the boot prompt was waiting > > for a time that never arrived. > > > > I learned a lot about OpenBSD efiboot and a good BIOS lesson. Always use > > the clear CMOS hardware jumper after a BIOS update. I have been using the > > "Load defaults" in the BIOS after a BIOS update but that is not good > enough. > > > > Thanks again Theo for your direction and encouragement. > > Interesting. Wonder how common this is. > > Should our code eventually advance if it has done millions of inspection > loops? If you can re-create the condition, can you propose a diff which > does that? >
Re: sysupgrade failure due to boot.conf
> On Jul 13, 2020, at 6:58 AM, Alfred Morgan wrote: > > > Brian wrote: > > (echo boot /bsd.upgrade; echo boot) > /etc/boot.conf > > Brian, that doesn't work. I tried that already before. It seems to stop at > the error not finding bsd.upgrade and won't continue. > > -alfred Thanks for checking this, it was untested advice. I’m glad it didn’t work, your follow-up emails regarding the root cause were enlightening for me.
Re: sysupgrade failure due to boot.conf
Alfred Morgan wrote: > Theo wrote: > > Figure out how to build and install. It is not hard to test. > > Thank you, I did as you suggested and I was able to narrow down the issue > to this line of code in /usr/src/sys/arch/amd64/stand/efiboot/efiboot.c: > > EFI_CALL(ST->RuntimeServices->GetTime, , NULL); > > > The GetTime call would always return the same time. It turned out that my > BIOS clock was frozen and was not ticking so the boot prompt was waiting > for a time that never arrived. > > I learned a lot about OpenBSD efiboot and a good BIOS lesson. Always use > the clear CMOS hardware jumper after a BIOS update. I have been using the > "Load defaults" in the BIOS after a BIOS update but that is not good enough. > > Thanks again Theo for your direction and encouragement. Interesting. Wonder how common this is. Should our code eventually advance if it has done millions of inspection loops? If you can re-create the condition, can you propose a diff which does that?
Re: sysupgrade failure due to boot.conf
Theo wrote: > Figure out how to build and install. It is not hard to test. Thank you, I did as you suggested and I was able to narrow down the issue to this line of code in /usr/src/sys/arch/amd64/stand/efiboot/efiboot.c: EFI_CALL(ST->RuntimeServices->GetTime, , NULL); The GetTime call would always return the same time. It turned out that my BIOS clock was frozen and was not ticking so the boot prompt was waiting for a time that never arrived. I learned a lot about OpenBSD efiboot and a good BIOS lesson. Always use the clear CMOS hardware jumper after a BIOS update. I have been using the "Load defaults" in the BIOS after a BIOS update but that is not good enough. Thanks again Theo for your direction and encouragement. -alfred
Re: sysupgrade failure due to boot.conf
I wrote: > I attempted over the weekend and I'm trying but my new code is not taking. > when I reboot I see "OpenBSD/amd64" not "HelloBoot/amd64" I figured out the issue. I need to compile efiboot separately. # cd /usr/src/sys/arch/amd64/stand/efiboot/ # make # make install ... This did the trick. I see my expected HelloBoot so I can continue with my deep dive. -alfred
Re: sysupgrade failure due to boot.conf
Brian wrote: > (echo boot /bsd.upgrade; echo boot) > /etc/boot.conf Brian, that doesn't work. I tried that already before. It seems to stop at the error not finding bsd.upgrade and won't continue. -alfred
Re: sysupgrade failure due to boot.conf
> Figure out how to build and install. It is not hard to test.
I attempted over the weekend and I'm trying but my new code is not taking.
I am using 6.6 release source code and it looks like I'm doing the right
steps but when I reboot UEFI I still see the old boot not my new HelloBoot
that I installed.
Here are my steps:
# uname -a
OpenBSD upgrade.lan 6.6 GENERIC.MP#372 amd64
# fdisk sd0
Disk: sd0 Usable LBA: 64 to 976773104 [976773168 Sectors]
#: type [ start: size ]
1: EFI Sys [ 64: 960 ]
3: OpenBSD [1024:976772081 ]
# cd /usr/src/sys/arch/amd64/stand/boot/
# diff -u boot.c~ boot.c
--- boot.c~ Sun Jul 12 06:22:46 2020
+++ boot.c Sun Jul 12 06:23:04 2020
@@ -66,7 +66,7 @@
machdep();
snprintf(prog_ident, sizeof(prog_ident),
- ">> OpenBSD/" MACHINE " %s %s", progname, version);
+ ">> HelloBoot/" MACHINE " %s %s", progname, version);
printf("%s\n", prog_ident);
devboot(bootdev, cmd.bootdev);
# make
...
# make install
install -c -s -o root -g bin -m 555 boot /usr/mdec/boot
BFD: /usr/mdec/sttIyjey: warning: allocated section `.bss' not in segment
install -c -o root -g bin -m 444 boot.8 /usr/share/man/man8/amd64/boot.8
# installboot -v sd0
Using / as root
installing bootstrap on /dev/rsd0c
using first-stage /usr/mdec/biosboot, second-stage /usr/mdec/boot
copying /usr/mdec/BOOTIA32.EFI to
/tmp/installboot.F3tHu75peT/efi/BOOT/BOOTIA32.EFI
copying /usr/mdec/BOOTX64.EFI to
/tmp/installboot.F3tHu75peT/efi/BOOT/BOOTX64.EFI
#reboot
when I reboot I see "OpenBSD/amd64" not "HelloBoot/amd64"
-alfred
Re: sysupgrade failure due to boot.conf
> On Jul 10, 2020, at 7:31 PM, Alfred Morgan wrote: > > >> >> You claimed sysupgrade does this. >> sysupgrade does nothing like that. It placed a /bsd.upgrade file, and > that is the end of the story. >> You told boot (via commands in boot.conf) to do something, so it did, > before discovering the file. > > Theo, > When I mentioned sysupgrade I was referring to the full sysupgrade > procedure all the way through to completion. Sorry for not being specific > enough. Thank you, you brought focus to boot which is really where my > suggestion will be focused on. > > So, how can I explicitly tell boot to act normally to boot /bsd.upgrade and > if that doesn't exist then boot /bsd? I would expect # echo boot > > /etc/boot.conf to do just that. > (echo boot /bsd.upgrade; echo boot) > /etc/boot.conf
Re: sysupgrade failure due to boot.conf
On 2020-07-10 15:37, Alfred Morgan wrote: Please, I have had this problem for several versions now and it still isn't working right. I have this on all three of my servers: echo boot > /etc/boot.conf I have this boot.conf because openbsd fails to boot (on all three servers) because it hangs on the boot> prompt because of some ghost input (I have no keyboard plugged in). So I was told that putting "boot" in my boot.conf would solve the problem and it did the trick. BUT, sysupgrade now fails trying to upgrade 6.6 -> 6.7. So what can I put in my boot.conf that will ignore the ghost input in the boot> prompt and allow sysupgrade to succeed? I feel that it's a bug in sysupgrade that it doesn't behave the same having "boot" in the boot.conf. Any help? -alfred Relevant xkcd? https://xkcd.com/1172/
Re: sysupgrade failure due to boot.conf
Alfred Morgan wrote:
> > You claimed sysupgrade does this.
> > sysupgrade does nothing like that. It placed a /bsd.upgrade file, and
> that is the end of the story.
> > You told boot (via commands in boot.conf) to do something, so it did,
> before discovering the file.
>
> Theo,
> When I mentioned sysupgrade I was referring to the full sysupgrade
> procedure all the way through to completion. Sorry for not being specific
> enough. Thank you, you brought focus to boot which is really where my
> suggestion will be focused on.
>
> So, how can I explicitly tell boot to act normally to boot /bsd.upgrade and
> if that doesn't exist then boot /bsd? I would expect # echo boot >
> /etc/boot.conf to do just that.
The code is in sys/stand/boot.c
devboot(bootdev, cmd.bootdev);
strlcpy(cmd.image, kernelfile, sizeof(cmd.image));
cmd.boothowto = 0;
cmd.conf = "/etc/boot.conf";
cmd.addr = (void *)DEFAULT_KERNEL_ADDRESS;
cmd.timeout = boottimeout;
if (upgrade()) {
strlcpy(cmd.image, "/bsd.upgrade", sizeof(cmd.image));
printf("upgrade detected: switching to %s\n", cmd.image);
isupgrade = 1;
}
st = read_conf();
Figure out how to build and install. It is not hard to test.
Re: sysupgrade failure due to boot.conf
> You claimed sysupgrade does this. > sysupgrade does nothing like that. It placed a /bsd.upgrade file, and that is the end of the story. > You told boot (via commands in boot.conf) to do something, so it did, before discovering the file. Theo, When I mentioned sysupgrade I was referring to the full sysupgrade procedure all the way through to completion. Sorry for not being specific enough. Thank you, you brought focus to boot which is really where my suggestion will be focused on. So, how can I explicitly tell boot to act normally to boot /bsd.upgrade and if that doesn't exist then boot /bsd? I would expect # echo boot > /etc/boot.conf to do just that. -alfred
Re: sysupgrade failure due to boot.conf
Alfred Morgan wrote: > Theo, right on point and I agree with the workarounds statement. I would love > to send > my server in for someone to look at it. I have 3 different machines (2 are > similar) all > experiencing the same problem with the ghost keyboard at the boot prompt. > > What my issue is that the bootloader seems to act differently if the prompt > times out > or if the "boot" command is given. I would expect the boot command with no > arguments to > do the same thing as a timeout at the prompt. > > the boot(8) man page says: > "prompt, which means you are in interactive mode and may enter commands. If > you do not, > boot will proceed to load the kernel with the current parameters after the > timeout > period has expired." > > and boot(8) also says: > "If device or image are omitted, values from boot variables will be used." > > (I find a discrepancy between "current parameters" and "boot variables" but I > take it > to mean the same thing.) > > sysupgrade(8) says: > "The bootloader will automatically choose /bsd.upgrade" > > I'm either missing something or one of these statements doesn't seem to be > entirely > true. I feel stuck with no options. You claimed sysupgrade does this. sysupgrade does nothing like that. It placed a /bsd.upgrade file, and that is the end of the story. You told boot (via commands in boot.conf) to do something, so it did, before discovering the file.
Re: sysupgrade failure due to boot.conf
Theo, right on point and I agree with the workarounds statement. I would love to send my server in for someone to look at it. I have 3 different machines (2 are similar) all experiencing the same problem with the ghost keyboard at the boot prompt. What my issue is that the bootloader seems to act differently if the prompt times out or if the "boot" command is given. I would expect the boot command with no arguments to do the same thing as a timeout at the prompt. the boot(8) man page says: "prompt, which means you are in interactive mode and may enter commands. If you do not, boot will proceed to load the kernel with the current parameters after the timeout period has expired." and boot(8) also says: "If device or image are omitted, values from boot variables will be used." (I find a discrepancy between "current parameters" and "boot variables" but I take it to mean the same thing.) sysupgrade(8) says: "The bootloader will automatically choose /bsd.upgrade" I'm either missing something or one of these statements doesn't seem to be entirely true. I feel stuck with no options. -alfred On Fri, Jul 10, 2020 at 3:43 PM Theo de Raadt wrote: > Alfred Morgan wrote: > > > Please, I have had this problem for several versions now and it still > isn't > > working right. > > I have this on all three of my servers: > > echo boot > /etc/boot.conf > > > > I have this boot.conf because openbsd fails to boot (on all three > servers) > > because it hangs on the boot> prompt because of some ghost input (I have > no > > keyboard plugged in). So I was told that putting "boot" in my boot.conf > > would solve the problem and it did the trick. BUT, sysupgrade now fails > > trying to upgrade 6.6 -> 6.7. So what can I put in my boot.conf that will > > ignore the ghost input in the boot> prompt and allow sysupgrade to > succeed? > > > > I feel that it's a bug in sysupgrade that it doesn't behave the same > having > > "boot" in the boot.conf. Any help? > > sysupgrade has nothing to do with this. the bootblocks decide to do > bsd.upgrade > instead, but if you've supplied it commands it does that instead. > > everything is working *precisely* as designed. > > As to what makes your keyboard controller do something wrong? That's > the real issue and needs a fix (who knows what), so the workaround is > causing you harm. > > But that's not really news, is it? There is always a cost associated > with workarounds >
Re: sysupgrade failure due to boot.conf
Alfred Morgan wrote: > Please, I have had this problem for several versions now and it still isn't > working right. > I have this on all three of my servers: > echo boot > /etc/boot.conf > > I have this boot.conf because openbsd fails to boot (on all three servers) > because it hangs on the boot> prompt because of some ghost input (I have no > keyboard plugged in). So I was told that putting "boot" in my boot.conf > would solve the problem and it did the trick. BUT, sysupgrade now fails > trying to upgrade 6.6 -> 6.7. So what can I put in my boot.conf that will > ignore the ghost input in the boot> prompt and allow sysupgrade to succeed? > > I feel that it's a bug in sysupgrade that it doesn't behave the same having > "boot" in the boot.conf. Any help? sysupgrade has nothing to do with this. the bootblocks decide to do bsd.upgrade instead, but if you've supplied it commands it does that instead. everything is working *precisely* as designed. As to what makes your keyboard controller do something wrong? That's the real issue and needs a fix (who knows what), so the workaround is causing you harm. But that's not really news, is it? There is always a cost associated with workarounds
sysupgrade failure due to boot.conf
Please, I have had this problem for several versions now and it still isn't working right. I have this on all three of my servers: echo boot > /etc/boot.conf I have this boot.conf because openbsd fails to boot (on all three servers) because it hangs on the boot> prompt because of some ghost input (I have no keyboard plugged in). So I was told that putting "boot" in my boot.conf would solve the problem and it did the trick. BUT, sysupgrade now fails trying to upgrade 6.6 -> 6.7. So what can I put in my boot.conf that will ignore the ghost input in the boot> prompt and allow sysupgrade to succeed? I feel that it's a bug in sysupgrade that it doesn't behave the same having "boot" in the boot.conf. Any help? -alfred
Re: pxeboot reading boot.conf and MAC address-boot.conf
On 2014-06-13, Jiri B ji...@devio.us wrote:
+.Pa /etc/boot.conf.OpenBSD-mm.nn-arch
The version info parts (and probably also arch) aren't very useful and are
a source of possible confusion as boot loader version isn't tightly coupled
to the OS version. Probably better just start with the MAC address.
+char boot_mac_str[14] =
+{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
That's not needed for a global variable is it?
pxeboot reading boot.conf and MAC address-boot.conf
Hi,
is there a plan to make pxeboot load additional config
like installer does it while prefixing path with MAC address?
- installer:
MAC address-install.conf
install.conf
- pxeboot:
/etc/boot.conf
There's old diff[1] which adds support for pxeboot loading
additional config which could help but it's 6 years old,
and location of MAC address in the filename is not consistent
with install.conf/MAC address-install.conf.
Anyway I'm including the diff if anybody would be interested.
j.
[1] http://nbender.com/install.netboot/netboot.diff
~~~
Index: sys/arch/amd64/stand/libsa/pxe.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/pxe.c,v
retrieving revision 1.5
diff -u -p -r1.5 pxe.c
--- sys/arch/amd64/stand/libsa/pxe.c27 Jul 2007 17:48:01 - 1.5
+++ sys/arch/amd64/stand/libsa/pxe.c30 Sep 2008 01:37:01 -
@@ -110,6 +110,7 @@ voidpxecall_bangpxe(u_int16_t); /* pxe_
void pxecall_pxenv(u_int16_t); /* pxe_call.S */
char pxe_command_buf[256];
+extern char boot_mac_str[14];
BOOTPLAYER bootplayer;
@@ -207,6 +208,9 @@ static struct iodesc desc;
int
pxe_netif_open()
{
+ char hexdigits[] = 0123456789abcdef;
+ int i;
+
t_PXENV_UDP_OPEN *uo = (void *) pxe_command_buf;
#ifdef NETIF_DEBUG
@@ -232,6 +236,13 @@ pxe_netif_open()
}
bcopy(bootplayer.CAddr, desc.myea, ETHER_ADDR_LEN);
+ addbootarg(BOOTARG_BOOTMAC, sizeof(bios_bootmac_t), bootplayer.CAddr);
+ boot_mac_str[0] = '.';
+ for (i = 1; i = 12; i += 2) {
+ boot_mac_str[i] = hexdigits[desc.myea[i / 2] 4 0xf];
+ boot_mac_str[i+1] = hexdigits[desc.myea[i / 2] 0xf];
+ }
+ boot_mac_str[13] = '\0'; /* ensure proper termination */
bootmac = bootplayer.CAddr;
/*
Index: sys/arch/amd64/stand/pxeboot/Makefile
===
RCS file: /cvs/src/sys/arch/amd64/stand/pxeboot/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- sys/arch/amd64/stand/pxeboot/Makefile 25 Nov 2007 18:25:30 -
1.8
+++ sys/arch/amd64/stand/pxeboot/Makefile 30 Sep 2008 01:37:01 -
@@ -12,6 +12,7 @@ PROG= pxeboot
SRCS= srt0.S conf.c devopen.c net.c open.c
LD?= ld
SIZE?= size
+CPPFLAGS+=-DPXEBOOT
LDFLAGS+=-melf_i386 -nostdlib -Bstatic -Ttext $(LINKADDR) -N -x -noinhibit-exec
LDFLAGS+=-L/usr/libdata
INSTALL_STRIP=
@@ -43,6 +44,12 @@ SRCS+= divdi3.c moddi3.c qdivrem.c
.PATH: ${S}/lib/libz
SRCS+= adler32.c crc32.c inflate.c inftrees.c
+
+# version info for pxeboot
+SRCS+= vers.c
+
+vers.c: $S/conf/newvers.sh
+ sh $S/conf/newvers.sh
${PROG}: $(OBJS)
$(LD) $(LDFLAGS) -o ${PROG} $(OBJS)
Index: sys/arch/amd64/stand/pxeboot/pxeboot.8
===
RCS file: /cvs/src/sys/arch/amd64/stand/pxeboot/pxeboot.8,v
retrieving revision 1.9
diff -u -p -r1.9 pxeboot.8
--- sys/arch/amd64/stand/pxeboot/pxeboot.8 31 May 2007 19:20:02 -
1.9
+++ sys/arch/amd64/stand/pxeboot/pxeboot.8 30 Sep 2008 01:37:02 -
@@ -50,11 +50,32 @@ The ROM downloads the boot program using
.Pp
The
.Nm
-boot program will look for an
+boot program searches for a configuration file on the TFTP server
+using paths in the following order:
+.Bd -literal -offset indent
+.Bl -item -compact
+.It
+.Pa /etc/boot.conf.x0x1x2x3x4x5
+.It
+.Pa /etc/boot.conf.OpenBSD-mm.nn-arch
+.It
.Pa /etc/boot.conf
-configuration
-file on the TFTP server.
-If it finds one, it processes the commands within it.
+.El
+.Ed
+.Pp
+where
+.Em x0x1x2x3x4x5
+corresponds to the hardware address of the
+PXE network interface with the colons removed,
+.Em mm.nn
+is the version number as reported by
+.Ic uname -r
+and
+.Em arch
+is the machine architecture as reported by
+.Ic uname -m
+.Nm
+will only exectute the commands in the first file found.
.Pa boot.conf
processing can be skipped by holding down either Control key as
.Nm
@@ -74,9 +95,7 @@ kernel
.Pa bsd
via TFTP.
It may be told to boot an alternative kernel,
-either by commands in the
-.Pa boot.conf
-file,
+either by commands in the configuration file,
or by commands typed by the user at the
.Ic boot\*(Gt
prompt.
Index: sys/arch/i386/stand/libsa/Makefile
===
RCS file: /cvs/src/sys/arch/i386/stand/libsa/Makefile,v
retrieving revision 1.47
diff -u -p -r1.47 Makefile
--- sys/arch/i386/stand/libsa/Makefile 30 May 2007 01:25:43 - 1.47
+++ sys/arch/i386/stand/libsa/Makefile 30 Sep 2008 01:37:03 -
@@ -45,6 +45,12 @@ SRCS+= ufs.c nfs.c tftp.c cd9660.c
# debugger
SRCS+= debug.c
+# version info for pxeboot
+SRCS+= vers.c
+
+vers.c: $S/conf/newvers.sh
+ sh $S/conf/newvers.sh
+
NOPROFILE=noprofile
NOPIC=nopic
Index: sys/arch/i386/stand/libsa/pxe.c
Re: Serial console only works if set tty com0 is specified in boot.conf
I have exactly the same problem. When i redirect default console to com0 (set tty com0 in /etc/boot.conf) serial console on tty00 then is working. But when i don't want to have default console there, then serial access is not working, but /usr/lib/getty std.9600 tty00 is running Only if i edit /etc/ttys and replace tty00 with cua00 - serial console is then working fine. Is this some bug ? -- View this message in context: http://www.nabble.com/Serial-console-only-works-if-set-tty-com0-is-specified-in-boot.conf-tp21757534p22179579.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Re: Serial console only works if set tty com0 is specified in boot.conf
On Fri, Jan 30, 2009 at 11:12 PM, Tom tdmurp...@gmail.com wrote: Hi all, I'm having a strange problem. I wanted to get a serial console working, but not necessarily divert the console to the serial port at boot time, so what I did was just edit /etc/ttys as specified in FAQ part 7.7 and rehupped getty. I couldn't get a peep out of /dev/tty00 (despite ps showing getty was running on /dev/tty00), so I ran fstat /dev/tty00 and nothing showed up. Then I rebooted and checked again. Still nothing in fstat, nothing on the serial port, and getty was still running on /dev/tty00. Hi Tom, The /etc/boot.conf deals with loading the kernel - adding set tty com0 tells the kernel to use com0 as the default console. Using boot.conf won't solve your serial console issue man 4 cua might help... Fred
Serial console only works if set tty com0 is specified in boot.conf
Hi all, I'm having a strange problem. I wanted to get a serial console working, but not necessarily divert the console to the serial port at boot time, so what I did was just edit /etc/ttys as specified in FAQ part 7.7 and rehupped getty. I couldn't get a peep out of /dev/tty00 (despite ps showing getty was running on /dev/tty00), so I ran fstat /dev/tty00 and nothing showed up. Then I rebooted and checked again. Still nothing in fstat, nothing on the serial port, and getty was still running on /dev/tty00. I added 'set tty com0' to /etc/boot.conf, rebooted, and then logged in and ran fstat /dev/tty00 to be greeted with 3 lines saying getty finally grabbed the serial port. The serial connection worked fine. So I'm just a bit confused here. Are we meant to have 'set tty com0' in boot.conf if we are to get serial console working in amd64? I tested this on 4 different machines, some were 4.4-release, others 4.4-stable and they had the same result. I haven't tried i386 yet as I don't have OpenBSD on any i386 platforms. I could just keep the 'set tty com0' in there, but I would like to know why I can't just have getty grab /dev/tty00 when told? Without the 'set tty com0', I was able to load up minicom, and specify /dev/cua00 and have it talk to minicom on a machine on the other side of the null modem cable. (I was able to echo characters back and forth.) Perhaps getty is silently failing because it can't open /dev/tty00? Thanks, Tom
serial console: how to reset terminal in boot.conf?
Hi folks, Short question: Is there some magic in /etc/boot.conf I could use to reset the terminal before booting? Here is the problem: AFAICS the BIOS in my Supermicro board switches to black chars on a black background before disabling console redirection and handing off control to the OpenBSD boot process :-(. (Using script I captured console output: The control sequence sent by the BIOS is ^[[0;30;40m if you are interested. 30 and 40 mean black foreground and background colors.) As a workaround I had set boot.conf to set timeout 30 stty com0 9600 set tty com0 echo ^[[0;30;47m boot , but without luck. Regards Harri
use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
I use a amd64 MP server, default boot into GENERIC, not GENERIC.MP. I can use boot.conf boot into GENERIC.MP, but this remove the 5 second pause at boot-time. How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? Thanks for some help, Dongsheng Song
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 05:19:16PM +0800, Dongsheng Song wrote: | I use a amd64 MP server, default boot into GENERIC, not GENERIC.MP. | | I can use boot.conf boot into GENERIC.MP, but this remove the 5 | second pause at boot-time. Then you probably have the following boot.conf : boot bsd.mp You may want to change it to : set image bsd.mp This is what I do on my MP systems. You should be aware of the fact that this breaks make install for your own kernel builds, but this may not be an issue for you. | How can I default boot into GENERIC.MP, and not remove the 5 second | pause at boot-time? Read boot.conf(5) for more details. You can even configure the timeout in there. Cheers, Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 05:19:16PM +0800, Dongsheng Song wrote: I use a amd64 MP server, default boot into GENERIC, not GENERIC.MP. I can use boot.conf boot into GENERIC.MP, but this remove the 5 second pause at boot-time. How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? Thanks for some help, set image bsd.mp
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 05:19:16PM +0800, Dongsheng Song wrote: How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? Use the following in your boot.conf: set image bsd.mp man boot.conf for more details...
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 05:19:16PM +0800, Dongsheng Song wrote: I use a amd64 MP server, default boot into GENERIC, not GENERIC.MP. I can use boot.conf boot into GENERIC.MP, but this remove the 5 second pause at boot-time. How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? Thanks for some help, Dongsheng Song set image bsd.mp It's documented in boot.conf(8)...
Re: use boot.conf boot into GENERIC.MP with the 5 second pause at boot-time
On Mon, Jun 16, 2008 at 11:28:36AM +0200, Michiel van Baak wrote: How can I default boot into GENERIC.MP, and not remove the 5 second pause at boot-time? cd / mv bsd bsd.up mv bsd.mp bsd reboot This is not really good advice, because it breaks next time you accidentally copy the wrong kernel into /bsd (for example, next time you upgrade the system)
Cd boot issue, boot.conf
Hello! Do you know why bootloader ignores option set device cd0a on etc/boot.conf while booting from cd? It's always asking me about root device. I'm trying to build livecd from snapshot and I'usinf GENERIC kernel, all works fine, except what I must specify boot device each time. Thanks in advance. My /etc/boot.conf on cd: set image /bsd set device cd0a set timeout 5 Opions to build iso: -no-iso-translate -R -T -allow-leading-dots -l -d -D -N -b cdbr -boot-load-size 4 -c boot.catalog -no-emul-boot -o /tmp/livecd.iso ./
Re: Cd boot issue, boot.conf
On Mon, Mar 31, 2008 at 06:21:30PM +0400, B A wrote: Hello! Do you know why bootloader ignores option set device cd0a on etc/boot.conf while booting from cd? It's always asking me about root device. because root on cd is not supported. there are diffs that were sent about 2-3y ago but they were not welcome for some reason... cu -- paranoic mickey (my employers have changed but, the name has remained)
Cd boot issue, boot.conf
Hello! Do you know why bootloader ignores option set device cd0a on etc/boot.conf while booting from cd? It's always asking me about root device. I'm trying to build livecd from snapshot and I'usinf GENERIC kernel, all works fine, except what I must specify boot device each time. Thanks in advance. My /etc/boot.conf on cd: set image /bsd set device cd0a set timeout 5 Opions to build iso: -no-iso-translate -R -T -allow-leading-dots -l -d -D -N -b cdbr -boot-load-size 4 -c boot.catalog -no-emul-boot -o /tmp/livecd.iso ./
Re: open(hd0a:/etc/boot.conf): Invalid argument
Thanks everyone who responded. Your helpful suggestions are appreciated.
Being new to BSD I was struggling a bit with some of the command line
differences to linux, but when I took a look at fdisk, it showed me that the
MBR partition ('slice') id was A5 and not A6. Wierd. I simply changed it
to A6 et voila! It's now working fine.
Once again, thanks for the suggestions. This thread is now closed.
On 6/7/07, Shag Bag [EMAIL PROTECTED] wrote:
I've installed OpenBSD4.1 from the 3 CD set which I purchased shortly
after it was released and have been running it on and off ever since.
However, this morning I tried to boot it and it came up with the above error
(full error listing below).
I re-installed the whole OS yesterday (everything except bsd.mp and
game41.tgz) and it was working fine. The only thing I did after
re-install was add a few packages and ports and compile the LookXP source
packages from http://lxp.sourceforge.net. I have not knowingly touched
the boot.conf file at all so I'm at a loss as to how the above error is
showing.
I have read the biosboot(8) man page but it didn't help. I am new to
OpenBSD having come from a brief linux background and would appreciate any
help.
I could always simply re-install OpenBSD4.1 again but this would be a last
resort as:
i) I'd like to know what the cause of the problem is and how to fix it -
in case it happens again;
ii) I wouldn't learn anything if I simply reinstalled everytime; and
iii) I've spent a lot of time configuring icewm to get it like I want and
am loathed to go through this process again.
The full error list I'm getting is:
Loading...
probing: pc0 apm mem[632K 2046M a20=on]
disk: fd0 hd0+*
OpenBSD/i386 BOOT 2.13
open(hd0a:/etc/boot.conf): Invalid argument
boot
booting hd0a:/bsd: open hd0a:/bsd: Invalid argument
failed(22). will try /obsd
boot
booting hda0:/obsd: open hda0a:/obsd: Invalid argument
failed(22). will try /bsd.old
boot
booting hda0:/bsd.old: open hda0a:/bsd.old: Invalid argument
failed(22). will try /bsd
boot
booting hda0:/bsd: open hda0a:/bsd: Invalid argument
failed(22). will try /obsd
boot
booting hda0:/obsd: open hda0a:/obsd: Invalid argument
failed(22). will try /bsd.old
boot
booting hda0:/bsd.old: open hda0a:/bsd.old: Invalid argument
failed(22). will try /bsd
Turning timeout off.
boot _
open(hd0a:/etc/boot.conf): Invalid argument
I've installed OpenBSD4.1 from the 3 CD set which I purchased shortly after it was released and have been running it on and off ever since. However, this morning I tried to boot it and it came up with the above error (full error listing below). I re-installed the whole OS yesterday (everything except bsd.mp and game41.tgz) and it was working fine. The only thing I did after re-install was add a few packages and ports and compile the LookXP source packages from http://lxp.sourceforge.net. I have not knowingly touched the boot.conf file at all so I'm at a loss as to how the above error is showing. I have read the biosboot(8) man page but it didn't help. I am new to OpenBSD having come from a brief linux background and would appreciate any help. I could always simply re-install OpenBSD4.1 again but this would be a last resort as: i) I'd like to know what the cause of the problem is and how to fix it - in case it happens again; ii) I wouldn't learn anything if I simply reinstalled everytime; and iii) I've spent a lot of time configuring icewm to get it like I want and am loathed to go through this process again. The full error list I'm getting is: Loading... probing: pc0 apm mem[632K 2046M a20=on] disk: fd0 hd0+* OpenBSD/i386 BOOT 2.13 open(hd0a:/etc/boot.conf): Invalid argument boot booting hd0a:/bsd: open hd0a:/bsd: Invalid argument failed(22). will try /obsd boot booting hda0:/obsd: open hda0a:/obsd: Invalid argument failed(22). will try /bsd.old boot booting hda0:/bsd.old: open hda0a:/bsd.old: Invalid argument failed(22). will try /bsd boot booting hda0:/bsd: open hda0a:/bsd: Invalid argument failed(22). will try /obsd boot booting hda0:/obsd: open hda0a:/obsd: Invalid argument failed(22). will try /bsd.old boot booting hda0:/bsd.old: open hda0a:/bsd.old: Invalid argument failed(22). will try /bsd Turning timeout off. boot _
Re: open(hd0a:/etc/boot.conf): Invalid argument
On Thu, 7 Jun 2007, Shag Bag wrote: I've installed OpenBSD4.1 from the 3 CD set which I purchased shortly after it was released and have been running it on and off ever since. However, this morning I tried to boot it and it came up with the above error (full error listing below). I re-installed the whole OS yesterday (everything except bsd.mp and game41.tgz) and it was working fine. The only thing I did after re-install was add a few packages and ports and compile the LookXP source packages from http://lxp.sourceforge.net. I have not knowingly touched the boot.conf file at all so I'm at a loss as to how the above error is showing. I have read the biosboot(8) man page but it didn't help. I am new to OpenBSD having come from a brief linux background and would appreciate any help. I could always simply re-install OpenBSD4.1 again but this would be a last resort as: i) I'd like to know what the cause of the problem is and how to fix it - in case it happens again; ii) I wouldn't learn anything if I simply reinstalled everytime; and iii) I've spent a lot of time configuring icewm to get it like I want and am loathed to go through this process again. The full error list I'm getting is: Loading... probing: pc0 apm mem[632K 2046M a20=on] disk: fd0 hd0+* OpenBSD/i386 BOOT 2.13 open(hd0a:/etc/boot.conf): Invalid argument boot Well, evidently there's something wrong with /etc/boot.conf, right? First, if you haven't done it already, print out the man page for ed(1), even from a linux system. On paper. So boot the installation CD again. Instead of update or install, select shell At the prompt (#), mount your root partition. Do I know what it is? No. I'll guess that it is either /dev/sd0a or /dev/wd0a Anyway, mount it: # mount /dev/sd0a /mnt Now you can look at (and edit, using ed(1)) the file in question. (Maybe you get errors? Maybe you need to run fsck on that partition before mounting it?) # cat /mnt/etc/boot.conf Tell us what you see. You can edit it. The routine PeeCee installation doesn't even need this file to exist. To edit: # ed /mnt/etc/boot.conf What no manpage? Didn't print it out? Don't know how to use ed(1)? Expected ed to pop up help windows? Thought I was lying? Here's your second chance: # mount /dev/sd0d /mnt/usr Assuming sd0d is where your /usr is. Forgot where that is? # cat /mnt/etc/fstab read what it says. Maybe your /usr is on the same partition as /, (linux having poisoned your mind in this regard), in which case it's already mounted. (partition = what disklabel makes. Not what fdisk manipulates). The man page is right there /mnt/usr/share/man/cat1/ed.0 Try to more it. I don't recall if more is available on the bsd.cd ramdisk, if not you're going to have to read quickly. Try running /mnt/usr/bin/more Would rather use vi? Well, maybe it's there under /mnt/usr/bin/vi Maybe it will even work. But this is diverging from topic. Summary: you can mount and manipulate your harddrive(s) from the installation CD using sh. It is not scary, just touchy. The simple manipulation might be just: # mv /mnt/etc/boot.conf /mnt/etc/boot.conf.bad and try rebooting from the harddisk. I have an uneasy feeling that something else may be wrong. If you found this post highly useful and full of new info and startling concepts, there's a openbsd-newbies list at sfobug.org. Visit http://sfobug.org for further info. Dave
boot.conf
Hello, I would like to run an OpenBSD machine where I want that the boot prompt disappears, reason is that I do not want others having access to the boot prompt. In case you put a boot into boot.conf or set timeout to zero then you do not have the opportunity to boot in single user when it may be necessary. Are there ways to circumvent the latter? Have a nice day Michael -- Michael Schmidt MIRRORS: DJGPP ftp://ftp.fh-koblenz.de/pub/DJGPP/ Ghostscript ftp://ftp.fh-koblenz.de/pub/Ghostscript/
Re: boot.conf
On Fri, Feb 24, 2006 at 02:53:06PM +0100, Michael Schmidt wrote: Hello, I would like to run an OpenBSD machine where I want that the boot prompt disappears, reason is that I do not want others having access to the boot prompt. In case you put a boot into boot.conf or set timeout to zero then you do not have the opportunity to boot in single user when it may be necessary. Are there ways to circumvent the latter? yeah. boot from a floppy cu -- paranoic mickey (my employers have changed but, the name has remained)
Re: boot.conf
On 2/24/06, Michael Schmidt [EMAIL PROTECTED] wrote: Hello, I would like to run an OpenBSD machine where I want that the boot prompt disappears, reason is that I do not want others having access to the boot prompt. In case you put a boot into boot.conf or set timeout to zero then you do not have the opportunity to boot in single user when it may be necessary. Are there ways to circumvent the latter? what problem are you trying to solve? --knitti
Re: boot.conf
Boot off of the cd38.iso, mount your / partition and remove your /etc/boot.conf is the first way that comes to mind. You could also work some magic with the boot prompt that you get from booting off the CD. Something like boot -s hd0a:/bsd should do it and I'm sure I could find a half dozen other ways to do it if i really wanted in. In other words, just adding boot to your boot.conf does not really add any security. It does make your life more difficult when you actually need to access single user mode, but without physical security, nothing is secure. Tim Donahue On Friday 24 February 2006 08:53, Michael Schmidt wrote: Hello, I would like to run an OpenBSD machine where I want that the boot prompt disappears, reason is that I do not want others having access to the boot prompt. In case you put a boot into boot.conf or set timeout to zero then you do not have the opportunity to boot in single user when it may be necessary. Are there ways to circumvent the latter? Have a nice day Michael
Re: boot.conf
On Friday, February 24, Michael Schmidt wrote: In case you put a boot into boot.conf or set timeout to zero then you do not have the opportunity to boot in single user when it may be necessary. Are there ways to circumvent the latter? With physical access to the machine, yes, there are many ways. --Toby.
boot.conf timeout ignored on amd64?
Hi, I'm working on an amd64 box (Opteron 146) with a soft raid with autoconfig in place. The soft raid works fine, but boot.conf is somewhat weird. Some experimenting revealed that I have three partitions which are recognized as boot partitions: /dev/wd0a, /dev/wd1a, and /dev/raid0a. On /dev/wd0a, the /etc/boot.conf file is recognized (what happens if wd0 goes bad??). But the kernel listed therein is taken from /dev/raid0a: - /etc/boot.conf --- set timeout 30 boot /bsd.mpr - /etc/boot.conf --- This should give me a 30 second pause before the machine boots the named kernel, but instead, it boots _immediately_, so I have no time to make up my mind to choose a different kernel. What am I doing wrong? This is a machine originally installed with 3.7, now running stock 3.8 on it's way to -stable. TIA! Best, --Toni++
Re: boot.conf timeout ignored on amd64?
On Fri, Jan 27, 2006 at 06:05:16PM +0100, Toni Mueller wrote: - /etc/boot.conf --- set timeout 30 boot /bsd.mpr - /etc/boot.conf --- The boot commands instructs it to boot there and then.
Re: boot.conf timeout ignored on amd64?
On 2006/01/27 17:30, John Wright wrote: On Fri, Jan 27, 2006 at 06:05:16PM +0100, Toni Mueller wrote: - /etc/boot.conf --- set timeout 30 boot /bsd.mpr - /etc/boot.conf --- The boot commands instructs it to boot there and then. 'set image' is probably what's wanted instead.
Re: boot.conf timeout ignored on amd64?
On Friday, January 27, Toni Mueller wrote: - /etc/boot.conf --- set timeout 30 boot /bsd.mpr - /etc/boot.conf --- This should give me a 30 second pause before the machine boots the named kernel, but instead, it boots _immediately_, so I have no time to make up my mind to choose a different kernel. What am I doing wrong? No, boot.conf is just as if you had typed the stuff on the command line. When you say 'boot foo', the bootblocks go ahead, and boot foo. No wait. No sleep. What you want is something like: set timeout 30 set image /bsd.mpr --Toby.
Re: Sad boot problem (boot.conf: invalid argument)
--On 09 June 2005 19:00 -0600, Tobias Weingartner wrote: On Thursday, June 9, Luciano ES wrote: Hello, Stuart. The answers to your latest questions: On 09/06/05 at 12:11, Stuart Henderson wrote in 7K: How does 'fdisk wd0' look? - The second slice (offset 63) was marked as unknown. Then I fixed it with OpenBSD's fdisk. Now it is marked as OpenBSD. The problem is that I have done that many times. The OpenBSD gets lost mysteriously. Often, between two reboots of OpenBSD (without booting any other system). Something is overwriting it. Where does your 'a' slice begin? What is the output of 'disklabel wd0'? Email from o.p. with URLs to text files with the information doesnbt seem to have made it to the list, Ibll include it below for reference and paste in the disklabels for ease of use; # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST3120022A flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 234441648 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0# microseconds track-to-track seek: 0# microseconds drivedata: 0 16 partitions: # sizeoffset fstype [fsize bsize cpg] a: 102406563 4.2BSD 2048 16384 328 # Cyl 0*- 1015 b: 1024128 1024128swap # Cyl 1016 - 2031 c: 234441648 0 unused 0 0 # Cyl 0 -232580 d: 1024128 2048256 4.2BSD 2048 16384 328 # Cyl 2032 - 3047 e: 9625392 3072384 4.2BSD 2048 16384 328 # Cyl 3048 - 12596 f:204624 12697776 4.2BSD 2048 16384 204 # Cyl 12597 - 12799 g: 2054115 12902400 4.2BSD 2048 16384 328 # Cyl 12800 - 14837* i: 1847475 14956515 MSDOS # Cyl 14837*- 16670* j: 32004 16804116 ext2fs # Cyl 16670*- 16702* k: 2618532 16836183 unknown # Cyl 16702*- 19300* l: 10361862 19454778 ext2fs # Cyl 19300*- 29579 m: 10361862 29816703 ext2fs # Cyl 29580*- 39859* n: 10329732 40178628 ext2fs # Cyl 39859*- 50107* o: 31535532 50508423 MSDOS # Cyl 50107*- 81392* p: 25189857 82044018 MSDOS # Cyl 81392*-106382* [and from bsd.rd with broken MBR partition table] c: 234441648 0 unused 0 0 # Cyl 0 -232580 i: 1847475 14956515 MSDOS # Cyl 14837*- 16670* j: 1495645263 unknown # Cyl 0*- 14837* k: 32004 16804116 ext2fs # Cyl 16670*- 16702* l: 2618532 16836183 unknown # Cyl 16702*- 19300* m: 10361862 19454778 ext2fs # Cyl 19300*- 29579 n: 10361862 29816703 ext2fs # Cyl 29580*- 39859* o: 10329732 40178628 ext2fs # Cyl 39859*- 50107* p: 31535532 50508423 MSDOS # Cyl 50107*- 81392* Forwarded Message Date: 09 June 2005 00:42 -0300 From: Luciano ES [EMAIL PROTECTED] To: Stuart Henderson [EMAIL PROTECTED] Cc: misc@openbsd.org Subject: Re: Sad boot problem (boot.conf: invalid argument) Hello, Stuart. Thanks for sending me a copy of your reply. I don't know if anyone else has added anything to this thread because I subscribe in digest mode. So here is all the info you told me to post, with comments. First off, the boot error message: http://tinyurl.com/8qexk So I booted with the CD and used the (S)hell. Here is dmesg: http://tinyurl.com/7wwdg And here is the first attempt at disklabel: http://tinyurl.com/8ezsx That's weird, isn't it? OpenBSD has disappeared completely. So I ran fdisk and saw that the slice was marked unknown instead of OpenBSD. Hmmm... That reminds me of a page I read that actually complains about problems with OpenBSD's fdisk: http://geodsoft.com/howto/dualboot/ This tutorial makes several complaints about OpenBSD's fdisk. And, in my own experience, it was clearly difficult not to lose the slice's ID every now and then with no apparent cause. I found myself fixing the OpenBSD slice's ID all the time. And it only happens with OpenBSD. If I boot into Linux and run fdisk, I see that slice correctly identified as OpenBSD. Then I go back to OpenBSD and it still won't boot. It still will see the slice as unknown. And it does not accept IDs set with Linux's fdisk. It really must be done by OpenBSD's fdisk. Grrr... So I did it again: changed the ID with OpenBSD's fdisk and ran disklabel again: http://tinyurl.com/bowlc Ha! There it is now. So I recorded another dmesg, but there was no difference. So I removed the CD and rebooted. Yay! It worked! OpenBSD is booting off the hard disk again. But for how
Re: Sad boot problem (boot.conf: invalid argument)
--On 09 June 2005 00:42 -0300, Luciano ES wrote: First off, the boot error message: Loading... probing: pc0 com0 com1 apm mem [508K 254M a20=on] disk: fd0 hd0+* hd1+* hd2* OpenBSD/i386 BOOT 2.06 open(hd0a:/etc/boot.conf): Invalid argument boot booting hd0a:/bsd: open hd0a:/bsd: Invalid argument failed(22). will try /obsd http://www.openbsd.org/faq/faq14.html#Boot386 ok, * means that no BSD disklabel was found, which isn't a surprise if the fdisk partition was somehow lost as there wouldn't be anywhere to look for a disklabel. This is also reported in the dmesg; http://tinyurl.com/7wwdg wd0: no disk label wd1: no disk label wd2: no disk label If the label isn't present, you'd expect to have a default label generated from the fdisk partitions (but of course this has just the one 'container' BSD partition, not each individual partitions with the filesystems for / /usr /var etc), which fits with the disklabels you gave. How does 'fdisk wd0' look? Have you used any disk tools on the drive from another OS which might have changed the MBR? Are you loading the OpenBSD boot directly from MBR, or is there some other bootmanager in the way? Any chance some program might have decided that the OpenBSD partition is bogus because it doesn't know the type, and decides to change it? # /dev/rwd0c: type: ESDI disk: ESDI/IDE disk label: ST3120022A flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 16383 total sectors: 234441648 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0# microseconds track-to-track seek: 0# microseconds drivedata: 0 # sizeoffset fstype [fsize bsize cpg] a: 102406563 4.2BSD 2048 16384 328 # Cyl 0*- 1015 b: 1024128 1024128swap # Cyl 1016 - 2031 c: 234441648 0 unused 0 0 # Cyl 0 -232580 d: 1024128 2048256 4.2BSD 2048 16384 328 # Cyl 2032 - 3047 e: 9625392 3072384 4.2BSD 2048 16384 328 # Cyl 3048 - 12596 f:204624 12697776 4.2BSD 2048 16384 204 # Cyl 12597 - 12799 g: 2054115 12902400 4.2BSD 2048 16384 328 # Cyl 12800 - 14837* i: 1847475 14956515 MSDOS # Cyl 14837*- 16670* j: 32004 16804116 ext2fs # Cyl 16670*- 16702* k: 2618532 16836183 unknown # Cyl 16702*- 19300* l: 10361862 19454778 ext2fs # Cyl 19300*- 29579 m: 10361862 29816703 ext2fs # Cyl 29580*- 39859* n: 10329732 40178628 ext2fs # Cyl 39859*- 50107* o: 31535532 50508423 MSDOS # Cyl 50107*- 81392* p: 25189857 82044018 MSDOS # Cyl 81392*-106382* -and- 16 partitions: # sizeoffset fstype [fsize bsize cpg] c: 234441648 0 unused 0 0 # Cyl 0 -232580 i: 1847475 14956515 MSDOS # Cyl 14837*- 16670* j: 1495645263 unknown # Cyl 0*- 14837* k: 32004 16804116 ext2fs # Cyl 16670*- 16702* l: 2618532 16836183 unknown # Cyl 16702*- 19300* m: 10361862 19454778 ext2fs # Cyl 19300*- 29579 n: 10361862 29816703 ext2fs # Cyl 29580*- 39859* o: 10329732 40178628 ext2fs # Cyl 39859*- 50107* p: 31535532 50508423 MSDOS # Cyl 50107*- 81392* The listed partitions cover 50% of the HD, so I guess there are probably other partitions. disklabel only supports partitions a-p (which is why the MSDOS partition disappears when the others are moved to the next letter when the unknown OpenBSD partition becomes 'j'). I don't know if any problems are exposed by using so many partitions (other than not being able to mount some of them from OpenBSD), but when you deal with corner cases, there's more chance of finding problems. This tutorial makes several complaints about OpenBSD's fdisk. And, in my own experience, it was clearly difficult not to lose the slice's ID every now and then with no apparent cause. I haven't really found that myself, but the most I've done is dual-boot OpenBSD and Windows on one box with two fdisk partitions using ntldr (as described in the faq), so it's a far less complex setup. Never seen a partition-type change with OpenBSD tools except when deliberately doing so with fdisk...
Re: Sad boot problem (boot.conf: invalid argument)
Hello, Stuart. The answers to your latest questions: On 09/06/05 at 12:11, Stuart Henderson wrote in 7K: How does 'fdisk wd0' look? - The second slice (offset 63) was marked as unknown. Then I fixed it with OpenBSD's fdisk. Now it is marked as OpenBSD. The problem is that I have done that many times. The OpenBSD gets lost mysteriously. Often, between two reboots of OpenBSD (without booting any other system). Have you used any disk tools on the drive from another OS which might have changed the MBR? - After, and only after I had the problem, I tried using Linux's fdisk a couple of times. But it didn't work, so I gave up. But I hadn't got anywhere near the MBR until the problem occurred for the first time. And, like I said, the slice also loses its OpenBSD ID mysteriously between two reboots of OpenBSD. Are you loading the OpenBSD boot directly from MBR, or is there some other bootmanager in the way? Any chance some program might have decided that the OpenBSD partition is bogus because it doesn't know the type, and decides to change it? - I am using Grub with these options: rootnoverify (hd0,1) makeactive chainloader +1 Always worked fine with Windows, Linux, FreeBSD and NetBSD. Thank you again for your attention. -- Luciano ES Santos, SP - Brasil
Re: Sad boot problem (boot.conf: invalid argument)
On Thursday, June 9, Luciano ES wrote: Hello, Stuart. The answers to your latest questions: On 09/06/05 at 12:11, Stuart Henderson wrote in 7K: How does 'fdisk wd0' look? - The second slice (offset 63) was marked as unknown. Then I fixed it with OpenBSD's fdisk. Now it is marked as OpenBSD. The problem is that I have done that many times. The OpenBSD gets lost mysteriously. Often, between two reboots of OpenBSD (without booting any other system). Something is overwriting it. Where does your 'a' slice begin? What is the output of 'disklabel wd0'? --Toby.
Re: Sad boot problem (boot.conf: invalid argument)
On 6/9/05, Luciano ES [EMAIL PROTECTED] wrote: Hello, Stuart. The answers to your latest questions: On 09/06/05 at 12:11, Stuart Henderson wrote in 7K: How does 'fdisk wd0' look? - The second slice (offset 63) was marked as unknown. Then I fixed it with OpenBSD's fdisk. Now it is marked as OpenBSD. The problem is that I have done that many times. The OpenBSD gets lost mysteriously. Often, between two reboots of OpenBSD (without booting any other system). Have you used any disk tools on the drive from another OS which might have changed the MBR? - After, and only after I had the problem, I tried using Linux's fdisk a couple of times. But it didn't work, so I gave up. But I hadn't got anywhere near the MBR until the problem occurred for the first time. And, like I said, the slice also loses its OpenBSD ID mysteriously between two reboots of OpenBSD. Are you loading the OpenBSD boot directly from MBR, or is there some other bootmanager in the way? Any chance some program might have decided that the OpenBSD partition is bogus because it doesn't know the type, and decides to change it? - I am using Grub with these options: rootnoverify (hd0,1) makeactive chainloader +1 From what I know of grub (don't remember what version, It was like 6 months ago), you need to put rootnoverify (hd0,1a) (assuming you boot from the 'a' slice). I have absolutely no idea if this causes the problem but maybe it can help. Always worked fine with Windows, Linux, FreeBSD and NetBSD. Thank you again for your attention. -- Luciano ES Santos, SP - Brasil -- They allowed us to set up a separate division almost, that is physically, geographically, psychologically and spiritually different from what Bill himself calls the Borg - Peter Moore, V.P. in charge of Xbox 360 marketing at Microsoft.
Sad boot problem (boot.conf: invalid argument)
Hi to all. I have been interested in BSD for about a year and have tried all of the three most popular free ones. I would like to start by saying something good: OpenBSD was a very pleasant surprise to me. After trying FreeBSD and NetBSD, I left OpenBSD to the end of the queue because of so many bad things I had heard about it, like it's slow or it's too difficult. I didn't find any of this while testing it. Instead, this is my favorite BSD so far and I actually think I could use it every day instead of Linux. I also want to build a server, BTW. Now, the bad thing. Contrasting with the very good experience I had in my tests, I have already installed it three times because of a problem that beats the heck out of me. You certainly have heard about it before: disk: fd0 hd0+ OpenBSD/i386 BOOT 2.02 open(hd0a:/etc/boot.conf: Invalid argument boot booting hd0a:/bsd: open hd0a:/bsd: Invalid argument failed(22). will try /obsd boot booting hd0a:/obsd: open hd0a:/obsd: Invalid argument failed(22). will try /bsd.old My first line is different from disk: fd0 hd0+ because I have three hard disks. And I guess it's not BOOT 2.02 anymore. I have OpenBSD 3.7. Actually, I copied the block above from the archives: http://archives.neohapsis.com/archives/openbsd/2003-11/0143.html It was very sad. In the first time, I could boot with the cd: boot boot hd0a:/bsd But I couldn't find out how to fix the system and boot without the CD. Reinstalling didn't work either. Neither did deleting and recreating the disk labels. Actually, even if I format the slice with another file system, the disk labels are still there when I try to reinstall. The only method that worked for me was the following: - Format the slice with another file system. In my case, ext2. - Boot into Linux and copy an awful lot of data to that slice until no space is left. - Boot with the CD and reinstall everything all over again. Yes, this method actually worked twice and had me piloting OpenBSD again. That's when I tested OpenBSD and found it so good. But it only survives about 4 or 5 reboots until that nasty problem bites me again. And in the last two times, booting with boot hd0a:/bsd didn't work either. Then I just gave up. What I have now is an unbootable slice. If I had actual data in there, I wouldn't know what to do to have it back. But what is also a very bad consequence is that now I am afraid of OpenBSD. All the time during my tests, I stared nervously at the boot sequence waiting for the strange problem to happen again. And, sure enough, it's happened three times already in less than two days. I really liked all the rest of the experience, but I don't think I'll have the courage to actually use it. I almost formatted the slice to install something else and left OpenBSD behind, but decided to take a shot and ask for a little enlightenment here. Back to that message I found in the archives, it seems that the person that signs as herk solved the problem with a BIOS update. Actually, I found another case in Google of someone who had the same problem and also solved the problem with a BIOS update. But I don't want to go that way. I do not feel comfortable at all updating my BIOS. Lots of things can go wrong and trash my motherboard. Besides, I really would like someone to tell me why that has to be the only way if: - I never had that problem with FreeBSD; - I never had that problem with NetBSD; - I never had that problem with Windows 95, 98 or 2000 (this machine never saw and never will see XP); - I never had that problem with any of the 10 or more Linux distros I have tried, over 30 if we count multiple versions of these 10 distros as individual distros. In light of these facts, what would the technical explanation be for such a discouraging flaw not to be viewed and addressed as a bug or, at least, a shortcoming of OpenBSD? Of course, alternative and effective solutions to my problem would be greatly appreciated, but for now I only beg that you gentlemen at least tell me, in very clear wording, why it is not considered a bug if it only seems to happen with OpenBSD. Many thanks in advance for your time and attention. -- Luciano Espirito Santo Santos, SP - Brasil
Sad boot problem (boot.conf: invalid argument)
I am sorry, I forgot to say that my motherboard is an Asus A7N 266 VM. I am sure that someone will want to know. -- Luciano Espirito Santo Santos, SP - Brasil
Re: Sad boot problem (boot.conf: invalid argument)
--On 08 June 2005 21:22 -0300, Luciano ES wrote: Now, the bad thing. Contrasting with the very good experience I had in my tests, I have already installed it three times because of a problem that beats the heck out of me. You certainly have heard about it before: disk: fd0 hd0+ OpenBSD/i386 BOOT 2.02 open(hd0a:/etc/boot.conf: Invalid argument boot booting hd0a:/bsd: open hd0a:/bsd: Invalid argument failed(22). will try /obsd boot booting hd0a:/obsd: open hd0a:/obsd: Invalid argument failed(22). will try /bsd.old My first line is different from disk: fd0 hd0+ because I have three hard disks. And I guess it's not BOOT 2.02 anymore. I have OpenBSD 3.7. Actually, I copied the block above from the archives: Well, you want help with your problem, not someone else's problem from 2003, with a very different bootloader... Copy the exact message from your system. Either type it from the screen, being very careful that you don't miss any punctuation characters etc., or use a serial console as described on http://www.openbsd.org/faq/faq4.html#getdmesg Output from disklabel might be useful, and you should include dmesg too. But I couldn't find out how to fix the system and boot without the CD. Reinstalling didn't work either. Neither did deleting and recreating the disk labels. Actually, even if I format the slice with another file system, the disk labels are still there when I try to reinstall. The only method that worked for me was the following: You can usually clear a disklabel by overwriting the start of the partition by dd'ing /dev/zero over it.
