Remote install of Debian or Gentoo - steps and grub?

1

I have a remote server currently installed with CentOS and I'll be doing a remote install of a new operating system - either gentoo or debian.

I've seen other related questions in here, but given this is a somewhat risky procedure I want to make sure my planning is right.

Here's the steps I'll be taking:

  1. create a new partition and set it up with the desired filesystem for the new OS
  2. mount the partition in /tmp/newos
  3. use debootstrap or a stage3 install (depending on OS) to configure a minimal install in the partition
  4. chroot to /tmp/newos and setup network configuration, (xen) kernel, sshd and a new user
  5. exit from chroot
  6. add the new OS to the current OS grub config
  7. set the new kernel to boot only once according to [these instructions][1]

I'm thinking it might be best to enable "reboot-on-panic" and "reboot-on-oops" on the new kernel, just in case.

Any step I'm missing or other things that can go wrong?

tomeduarte

Posted 2012-04-11T09:30:53.117

Reputation: 111

Gentoo instructions here: http://www.gentoo.org/doc/en/altinstall.xml#doc_chap5

– reisio – 2012-05-23T12:09:37.467

Answers

1

Assuming your lost link in the question is to use the save-default option in grub so that upon next boot it reverts to the current install, then having the oops and panic reboots are definitely worth doing.

The other gotchas are catching those events that don't lead to a panic or oops, but still render the OS inaccessible. Make absolutely sure your /etc/fstab reflects the disk situation as the booting OS will see it. If you keep things simple for your first boot, such as having everything in a single partition (with a file system that your version of grub can boot from), then this should be straightforward.

The other thing to consider is if the server boots fine, but you cannot access it - for example, if ssh doesn't come up correctly. You might want to put a script in the boot up sequence that reboots the server even if it boots successfully. If you are able to get in, then you can simply kill the script before it runs.

Another thing to consider is investing in a remote console solution so none of this would be a concern. Most server hosting businesses and corps would have these.

Paul

Posted 2012-04-11T09:30:53.117

Reputation: 52 173