I am running OBSD 4.4/i386 on a Dell Inspiron 6400 (E1505) w/ 2GB RAM

and a 2.0 GHz Intel Core 2 Duo CPU ("Merom").
I am running the GENERIC OBSD 4.4/i386 'bsd' kernel and would like

to set up the bsd.mp kernel instead.
How do I go about this?
Attached is my dmesg as a text file.
-minsai0000

OpenBSD 4.4 (GENERIC) #1021: Tue Aug 12 17:16:55 MDT 2008

    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz ("GenuineIntel" 686-class) 2 GHz

cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,CX16,xTPR

real mem  = 2145820672 (2046MB)

avail mem = 2066497536 (1970MB)

mainbus0 at root

bios0 at mainbus0: AT/286+ BIOS, date 06/13/07, BIOS32 rev. 0 @ 0xffa10, SMBIOS rev. 2.4 @ 0xf7980 (44 entries)

bios0: vendor Dell Inc. version "A17" date 06/13/2007

bios0: Dell Inc. MM061

acpi0 at bios0: rev 0

acpi0: tables DSDT FACP HPET APIC MCFG SLIC BOOT SSDT SSDT

acpi0: wakeup devices LID_(S3) PBTN(S4) MBTN(S5) PCI0(S3) USB0(S0) USB1(S0) USB2(S0) USB3(S0) EHCI(S0) AZAL(S3) PCIE(S4) RP01(S4) RP02(S3) RP03(S3) RP04(S3) RP05(S3) RP06(S3)

acpitimer0 at acpi0: 3579545 Hz, 24 bits

acpihpet0 at acpi0: 14318179 Hz

acpiprt0 at acpi0: bus 0 (PCI0)

acpiprt1 at acpi0: bus 1 (AGP_)

acpiprt2 at acpi0: bus 3 (PCIE)

acpiprt3 at acpi0: bus 11 (RP01)

acpiprt4 at acpi0: bus -1 (RP02)

acpiprt5 at acpi0: bus -1 (RP03)

acpiprt6 at acpi0: bus 12 (RP04)

acpiprt7 at acpi0: bus -1 (RP05)

acpiprt8 at acpi0: bus -1 (RP06)

acpicpu0 at acpi0: C3, C2, C1

acpitz0 at acpi0: critical temperature 126 degC

acpiac0 at acpi0: AC unit offline

acpibat0 at acpi0: BAT0 model " DELLPD9458" serial 987 type LION oem "Sanyo"

acpibtn0 at acpi0: LID_

acpibtn1 at acpi0: PBTN

acpibtn2 at acpi0: SBTN

acpivideo at acpi0 not configured

acpivideo at acpi0 not configured

acpivideo at acpi0 not configured

bios0: ROM list: 0xc0000/0x10000

cpu0 at mainbus0

cpu0: Enhanced SpeedStep disabled...
[ message continues ]

Another way would be through creating/editing /etc/boot.conf and

having an entry for the mp kernel

ex:  boot wd0a:/bsd.mp
where wd0a is your root partition.
-Parvinder Bhasin

I recommend against that.
Firstly, one developer has already been fried on an upgrade using the

-current bsd.rd
Secondly, it is not portable to all our architectures, so why do it?

On Sat, 02 May 2009 21:26:05 -0600 Theo de Raadt
Thirdly, it should be removed. The new installer destined for 4.6

already does the right thing, so the i386\amd64 specific etc/boot.conf

hack is redundant and leads to confusion.
--

J.C. Roberts

Does bsd.mp still break some machines?  It works on every machine I try

it with, but I don't have that many unusual machines.

On Sun, 3 May 2009 08:45:55 -0700
Hmm, how should I specify that I want to use com0 as console then?

Agreed, boot.conf is VERY useful.
Another important use is to reboot into another temporary kernel.  I

use this to boot into a YAIFO-like installer, so I can easily re-

install a running machine from the network without

having to much with BIOS setting for pxeboot, etc.  And if this

process fails for some reason (before you reformat your disks :-) ),

it is good to have the regular kernels sitting around for recovery

purposes.
Don

On Sun, 3 May 2009 09:39:23 -0700 Don Jackson <don.jackson@gmail.com>
I never said the boot.conf was not useful. I said the i386\amd64 hack

for loading kernels is redundant and leads to confusion.
The new installer (destined for 4.6) in snapshots *already* picks the

right kernel (GENERIC or GENERIC.MP) for the system, and installs it

as /bsd.
On all archs, when you wish to boot to a different on-disk kernel you

cab do it either by copying/moving kernel file to /bsd, and/or

specifying the kernel file at boot time `boot /mybsd.custom.hack`
When you treat i386\amd64 differently with the boot.conf kernel

designation feature, you are not only making things less portable, but

worse, you're showing a bias towards what many consider to be a flawed

system design.
Now, let's say you are using the /etc/boot.conf hack to boot to bsd.mp,

and you go to update your stable system running an MP kernel. You read

the FAQ and follow the directions for installing a new kernel and

rebooting before building the whole system.
When you do `make install` in your ../compile/GENERIC.MP/ directory,

the newly built kernel gets installed as /bsd
You supposedly reboot to your new kernel... and guess what? --Due to

your boot.conf hack you're still running your *old* /bsd.mp kernel

rather than your newly built /bsd kernel.
If your subsequent build of the whole system fails with some mysterious

error due to booting to the old kernel, and you start yammering on misc@

about reading/following the FAQ, you're still wrong because you weren't

paying attention.
Tricky, confusing situations like the above should not be allowed to

happen. It's a design flaw, and especially so since it's a hack to

support an unnecessary feature for particular architecture. 
--

J.C. Roberts

Hi,
I don't see how 'set image ...' is a hack, nor how it would be specific
This makes it harder to move a set of already-installed disks to a
Hmmm... Can you please point me to some reading about the upcoming
This problem imho *only* arises as a consequence due to installing the

new kernel in the wrong place. Would it have been installed in /bsd.mp,

nothing would have gone wrong. You could even opt to overwrite /bsd.mp

in that case, too, to make sure that you are backwards-compatible.
Kind regards,

--Toni++

On Mon, 4 May 2009 12:35:12 +0200 Toni Mueller <openbsd-misc@oeko.net>
If you read the boot.conf(8) man page, you'd already know it's a hack
You need to inspect your own bias and hence, opinion. There is no solid

technical reason for one being OK and the other being disliked.
The only place where moving kernels around can be problematic is on

systems where there is a limitation of "bootable" disk space (i.e.

often the first 512MB of the disk). Again, this is caused by a bad
I think a more accurate way to phrase it is "less-flawed" ;-)
Doing some reading and testing with OpenFirmware (macppc, sparc,

alpha, ...) will show you some better ways to handle things. If you

understand the hardware itself, know how to program in Forth, and the

system has NVRAM, you can actually write scripts to patch the
Nope. It is better for everything to be consistent. When a new kernel

is built and installed, it should be written to "/bsd" rather than some

custom name.
Having a second stage boot loader like boot.conf that on *only* some

archs will change the decision of which kernel to load leads to

confusion and mistakes.
Just because you might like the non-portable utility offered by the "set

image" feature of boot.conf does not make it a good idea.
--

J.C. Roberts

Hi!
Rather "set image ..." so you still have the timeout so you can override
Kind regards,
Hannah.

For that, you would use boot.conf
You need to read more carefully.  Specifying the kernel in boot.conf

should be stopped, though, perhaps.  At least people should stop using

it because it will cause them problems soon.

On Sun, 3 May 2009 18:15:16 +0200

Meh, ignore that please.  I misread.

but don't do it this way.

not only did it not improve things in the past, it will

make things less fun in the future.
it's also quite i386/amd64-centric.
Nick.

cd /

mv bsd bsd.sp

mv bsd.mp bsd
reboot

As an additional note, in the new -current snapshots this is done

automatically.  As is a lot of other stuff....

Hi,
what was wrong with:
# echo 'set image /bsd.mp' >> /etc/boot.conf

# reboot
Kind regards,

--Toni++

This has been discussed recently.
Summary: changes in the OpenBSD 4.6 install script, plus: after

building a new kernel 'make install' copies it to /bsd. In both cases

you end up running and old kernel. 
	-Otto

Hi Otto,
I agree to be guilty of posting before reading the entire thread, but

after doing it, I still miss the reasoning behind this change (ie,

*why* you want to install bsd.mp as bsd), and thus create installed

disks individually and non-portably, as far as I can see from here.
Kind regards,

--Toni++