25

I need to remotely install Ubuntu Server 10.04 (x86) on a server currently running RHEL 3.4 (x86). I'll have to be very careful because no one can press the restart button for me if anything goes wrong.

Have you ever remotely installed Linux? Which way would you recommend? Any advice for things to watch out?


Update:

Thanks for your help. I managed to "change the tires while driving"!

The main components of my method are drawn from HOWTO - Install Debian Onto a Remote Linux System, grub legacy: Booting once-only, grub single boot and kernel panic reboot , and Ubuntu Community Documentation: InstallationFromKnoppix

Here is the outline of what I did:

  1. Run debootstrap on an existing Ubuntu server
  2. Transfer the files to the swap partition of the RHEL 3.4 server
  3. Boot into tha swap partition (the debootstrap system)
  4. Transfer the files to the original root partition
  5. Boot into the new Ubuntu system and finish up the installation with tasksel, apt-get, etc

I tested the method in a VM and then applied to the server. I was lucky enough that everything went smoothly :)

8
  • 17
    Sounds like trying to fit new tyres to your car while driving it.
    – Orbling
    Dec 2, 2010 at 1:03
  • 10
    @Orbling: youtube.com/watch?v=dcQ_BTZ3mhg#t=1m45s
    – ephemient
    Dec 2, 2010 at 2:49
  • Theoretically possible. Bit like as Orbling puts it, changing your tyres while driving the car. Not very easy!
    – hookenz
    Dec 2, 2010 at 8:18
  • @ephemient Awesome. You see it is possible, just incredibly difficult.
    – Orbling
    Dec 2, 2010 at 11:59
  • 1
    Interesting, the update should have been an answer though.
    – AD7six
    Jun 14, 2013 at 12:33

9 Answers 9

9

I agree with the sentiment of the other answers here: Although it may be possible to install Ubuntu remotely on RHEL 3.4, you are likely going to be treading on some very thin ice.

I think the biggest problem you may have is the age of the kernel and libc on the existing system. Is that a 2.4.x-series kernel? If so, I'm not sure you'll be able to pull this off, because at some point during your install, you'll need to run tools that were compiled to run in Ubuntu's kernel and libc, and they may not function properly (or at all) on an older runtime environment. If you are not running a 2.6.x-series kernel on the remote server, I don't think you have much chance of success.

If you still think you might want to try this, there are a couple of guides I am aware of:

Both of those guides are kind of old, so neither can be treated as anything even close to a cut-and-paste guide. I would strongly suggest following the advice of others here and do some dry runs on a local server or a VM, because there are definitely kinks and gotchas you'll need to work out before going ahead for real.

12

The best practice for remotely installing any OS is to buy server hardware with out of band management (HP ilo, Dell drac) that lets you remotely power cycle and see the console of a server. Don't even try otherwise.

4
  • I agree, but I still need to deal with my current situation
    – netvope
    Dec 2, 2010 at 0:54
  • 6
    A lot of experienced people that have been doing this for a decade are going to tell you "good luck with that".
    – user15590
    Dec 2, 2010 at 1:05
  • 1
    Both embobo and troyengel are spot on; the situation you are in is only going to get worse if you try and do this remotely. My suggestion? Get in contact with the data center.
    – Andrew M.
    Dec 2, 2010 at 1:17
  • 1
    Remote management cards are great, and most of the new Supermicro systems come with them built in, including remote power, keyboard/video/mouse and remote CD/DVD drives. For this situation, I can't imagine being without one. Dec 2, 2010 at 8:40
5

Installing a new distro in place can be done, but is very challenging. It's something that you almost certainly will NOT get right the first time. In fact, you'll be luck if you get it right the third or fourth time.

Additionally, nobody here is going to be able to give you a laundry list that you can just follow and this will happen. You're going to have to experiment with different alternatives, depending on your exact disc partition and file-system layout, hardware configuration, etc.

That said, here's how I'd go about doing something like that if I had to:

  • Get a machine configured as similarly as possible to the existing machine: hard drives, network cards, disc adapters, RAM, you name it.
  • Set up this machine to mimic the current setup on that host.
  • Experiment with doing what you need to do on this test system.
  • Take copious notes on it so that you can reproduce it on the "live" system.
  • Run through these notes again on the test system before you do the final migration.

Some techniques that may be able to help you:

  • Decide if you want to install to a new partition, or try to install over the existing file-system. If you do a new partition, you can always back out by booting the old partition. However, that probably means you need to shrink the current file-system, which has to be done offline. I wrote up some notes back in 2007 when I did this.
  • You may be able to do an install to a small partition on your test machine, and then make appropriate changes such as the IP addresses and "dd" this file-system image off to use to populate the base install on the new partition. This would only be if you were using a separate partition for the new install.
  • You could instead put the root file-system in place in a sub-directory and then do something in the initrd so that it would: "cd /target; mv * oldroot; mv oldroot/newos/* ." to move all the old directories out of place and put the new ones in place. This would have to be done before the initrd does it's "pivotroot", probably right after it mounts the file-system.
  • Adding some code into the initrd scripts can allow you to do all sorts of wonderful things during the system boot. See the blog post I references above for more details.
  • Expect that you're going to fail at this. It's an extremely risky endeavor. When I did my file-system resize (mentioned above), I was shocked when it rebooted properly.
  • You'll have to decide what you want to do about the boot sectors, is it running LILO or GRUB? Do you want to try to stay with the current boot loader, or switch to 10.04's? Probably the ideal thing would be to use the existing loader to get booted into the new OS, then run "grub-install" from that OS to put the new one in place.

Good luck! You'll need it. :-)

2

If you have a different partition you can use that partition to install in a VM that see the entire disk. As long as you do not mount the same partition in both the VM and host or play with partition table you are safe. Another way would be to boot from network and do a installation using preseed or kickstart. Experiment with a local environment before playing remotely.

1

I write a simple solution based on preseed.

https://github.com/mhf-ir/ubuntu-overssh-reinstallation

You need installed version of ubuntu that have ssh. another http server for serving preseed file. I tested so many times in many datacenters.

If you have ubuntu you can reinstall and repartition over ssh without KVM/IPMI/VNC or any remote application. just using ssh. And pure installation using netiso/miniiso of ubuntu server.

It's based on grub image loader boot your custom iso file that contain your network settings and ssh password.

0
  1. Good luck.

  2. This is conceivably doable, under some circumstances (which may not apply here / to you).

  3. This is hard; I recommend you practice on a local (virtual if necessary) machine. A lot.

0

If you can get just one visit to the server, you could add a KVM over IP port to the system. I found a $310 Lantronix Spider 1-port at CDW that does this. It doesn't help with a "restart button" or getting media to eject though, although you could go into the BIOS on reboot and change the boot order so that a CD is ignored.

0

I've done it before, as a test. Not something I'd recommend doing if there's no fallback plan, though.

As it turns out systems are fairly reliable if all the applications needed are already loaded. I successfully ran dd and overwrote the first 8gb or so of the target server with a default Ubuntu installation and then rebooted the server into Ubuntu without issue. You could then expand the partition from there to fill the rest of the drive.

You could also set up a new partition, debootstrap a new installation into it, and modify your bootloader to boot into this new partition. Again, expect failure and hope for success.

0

Good news people, all is super easy now (year 2020) as there is the new Ubuntu installer (Subiquity? or sth like that) where SSH install is build into installer (tested at least for ubuntu-20.04.1-live-server-amd64.iso so for server install, not desktop)

  1. When the installer launches and gets IP address (you can safely proceed to the network screen to make sure about that) ...
  2. ... you then activate the Help option (or press F1) and choose Help on SSH access or sth like that
  3. A window should popup with information on how to connect to SSH - you should of course have the network set up properly in a way that allows you to connect to that machine's port 22

See screenshot below.

installer screenshot - enable SSH

Important notes:

  • When you loose connection (e.g. during partitioning) you may reconnect but probably you will start again from the beginning of setup step you were interrupted (e.g. if you disconnected on partitioning, then you would have to start with it again).
  • If you update the installer when it asks and something goes wrong, then reboot whole machine and start setup and try again without updating the installer
  • More information here (working in November 2020): https://ubuntu.com/server/docs/install/general
1
  • I'm booting the 22.04 server installer in a VM, but after setting up the network, my help menu does not include that last line, "Help on SSH access". When I go to a shell, the network is working, though. This quesiton seems to indicate that the password is random and unrecoverable without being able to see the screen.
    – Diagon
    Nov 7, 2022 at 9:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .