Changing the startup device for the next restart at the command line

  • Thread starter Thread starter Anonymous
  • Start date Start date
A

Anonymous

Guest
Hi,

I am looking for a command that can be used to switch the startup device for the next restart, i.e. something like bless for Mac OS X. Does something like this exist for FreeBSD 8.2.

I know how to do this in the BIOS setup, however, at times, I am miles away from the system, and need to prevent it restarting from the wrong device.

Many thanks and best regards

Rolf
 
How do you select what to start up?

The FreeBSD bootmanager will boot the last chosen option when it times out.
 
I am talking about FreeBSD systems with no physical access (headless, no keyboard, no monitor).

SirDice said:
How do you select what to start up?

My question is basically about choosing the "startup device", e.g. an internal SATA disk over an external USB disk.

The BIOS has been setup upon first installation to boot from USB first, if a USB booting device is connected. This is necessary for having the possibility of emergency recovering from a purposely prepared USB stick.

This came now into conflict with ONE part of the backup strategy, which is cloning (= mirroring != archiving) the internal disk to an external USB device once a night. Everyday in the morning, somebody takes away the clone to another building after connecting another for cloning the other night, and so on.

The procedure is trained and works well without interference of a system admin. The only problem left is now, that on occasional restarts (either forced or because of power failure), the system will restart from the external USB Clone, and not from the internal disk.

So, what I need is something that allows me to remotely choose the next boot device by the way of ssh.


SirDice said:
The FreeBSD bootmanager will boot the last chosen option when it times out.

Doesn't the FreeBSD Boot Manager only choose boot volumes on a given device? Or, does it somehow also switch devices? If yes (switch devices), can this be done remotely by ssh - i.e. writing some magic into any configuration file?

Many thanks

Rolf
 
What you need is a BIOS that's configurable over a serial connection or a KVM switch that's accessible from the network.
 
Changing the startup device for the next restart at the command line Reply to Thread

SirDice and Phoenix,

many thanks for your replies. As a matter of fact, I read already the threads about IPMI and KVM and for sure I will consider this for new installations.

For the already installed machines, I hoped for something like the bless tool of Mac OS X, but it seems that BIOS settings are not writeable by software, so no go here, and I have to find an organizational solution for this problem.

Best regards

Rolf
 
If you're using boot0 on the flash disk, you should be able to configure it to chain load the hard disk by using boot0cfg(8) to update its boot code.

This, however, will undermine your strategy of being able to easily boot off the flash disk in an emergency situation. You really need IPMI or an IP-KVM as the others said.
 
aragon said:
If you're using boot0 on the flash disk, you should be able to configure it to chain load the hard disk by using boot0cfg(8) to update its boot code.

This, however, will undermine your strategy of being able to easily boot off the flash disk in an emergency situation. You really need IPMI or an IP-KVM as the others said.

Wait a moment, boot0cfg(8) sounds promising. However, not being a native English speaker, I have some difficulties in completely rationalizing what the respective man file is going to tell me.

Again the situation:

  • There is an emergency flash drive (USB stick) which won't be touched.
  • There is a set of 3 external USB 2 TB (MBR formatted) drives, one of which receive each night the clone before it is replaced by another drive (outdated clone) in the morning.
  • The internal drive to be nightly cloned is a 3 TB GPT formatted drive.

So, what if I programatically add after cloning has finished 2 lines at the top of /clone/etc/rc.conf of the cloned disk:

Code:
boot0cfg -d 0x80
shutdown -r now

Wouldn't this have the effect, that an occasional restart would, YES, boot the clone first, but this immediately restarts after setting the internal drive for the next boot?

Did I understand this correctly? Then this would be totally sufficient for my actual needs.

However, boot0cfg seems to be somehow dangerous for the GPT formatted drive (overwriting boot blocks ?!?), so before doing the experiment, I would like to hear some comments on this.

Many thanks and best regards

Rolf
 
rolfheinrich said:
Did I understand this correctly?
No, and I don't understand what you're trying to accomplish.

You need to call boot0cfg with "-s 5" to have boot0 boot from a second disk.
 
aragon said:
No, and I don't understand what you're trying to accomplish.

In the first place I was looking for a shell command that let me define the startup device/disk/volume for the next restart, like the bless command of Mac OS X does. This definition would involve the command writing something into the CMOS/BIOS, which I learned is impossible. bless on Mac OS X writes something into the NVRAM which in turn is consulted by EFI in the course of booting.

aragon said:
You need to call boot0cfg with "-s 5" to have boot0 boot from a second disk.

At the bottom line, I do not need the total flexibility of bless. Instead, I only need to prevent that the system restarts from an external USB Clone Disk instead of the internal system disk.

I did the experiment with boot0cfg -s 5, and indeed this did somehow the trick. According to /var/log/messages the system tried first to boot from the USB drive, but it received an USB error:[CMD=""]usbd_set_config_index: could not read device status: USB_ERR_SHORT_XFER.[/CMD] And after this it failed back to booting from the internal disk.

Finally, I achieved the same by unsetting the active attribute of slice 1 of the external Clones.

[CMD=""]gpart unset -a active -i 1 da0[/CMD]

I feel more comfortable with gpart setting the activity over the obscure boot0cfg command. Anyway, many thanks for pushing me into the right direction.

Problem solved!

Best regards

Rolf
 
Back
Top