That might work for some scenerios; however, it wouldn't likely for the recent e2fsprogs-lib/ss/com_err fiasco because the booting system would be unable to execute mount and wait until the user either entered the root password for maintenance mode or pressed "CTRL+D" to continue. (Yep, I hosed one of my systems over that issue!) So the system would not be either in a kernel panic nor able to run /etc/conf.d/local.start. So it wouldn't reboot without user intervention.
In most cases that would likely work though. Ben ----- Original Message ---- From: Alex Schuster <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, October 30, 2008 4:44:53 PM Subject: Re: [gentoo-user] blocks to fix Mark Knecht writes: > Having a second install is a reasonable idea. I suppose I can probably > install that remotely but I cannot test it remotely (AFAIK) without > someone handy to choose the right line in the grub menu... You can use the grub-set-default command to boot another than the default entry: default saved fallback 0 ... title System A kernel (hd0,0)/A title System B kernel (hd0,1)/B System A is your default system. When you have installed B, activate the 2nd entry with "grub-set-default 1" (grub counts from 0). Put something like "sleep 600 & reboot" into B's /etc/conf.d/local.start that will make it reboot after a while, unless you are able to log in from remote and kill the sleep command. Now reboot. B will be started. Try to log in. If it fails, wait a little, and try again. This time A should be up again. Unless you have a kernel panic, and the system is just halted. Does anyone know if there is something one could do about that? Wonko
