2

Assuming a remote machine where you can PXE boot into a GRML image that also provides ssh access.

Now the question is how to install CentOS in such an environment.

Something like KVM access is not available.

A few years ago I used debootstrap with success to install Debian in a similar environment. Is there is something similar for CentOS/RHEL?

What is the state of the art method to install CentOS/RHEL in such an environment?

1

For automated installs of RHEL or distributions based on this, use Kickstart.

When you build a RHEL server a /root/anaconda-ks.cfg file is created that can be used to build a duplicate host.

There are various options, the two most suitable:
1. Custom Live CD / removable media build from the kiskstart image.
2. Full PXE boot network installation.

The network installation requires a network share containing the ks file and the installation source.

Your PXE environment could then just boot from a boot / kickstart server and identify which kickstart configuration to use from ths hosts mac address.

References

Kickstart Installations
How to make a create a live cd

  • Yes, kickstart (KS) looks promising. The thing is that the remote environment is really restricted. That means I can't even configure/add an PXE entry. It is just PXE-boot-into-GRML or boot-from-disk that I can toggle. Kickstart is still an option - because I could kexec into a KS-based install - or I could install a temporary grub that boots into a KS install. One missing piece is: CentOS 7 does not seem to verify package signatures when using netinstall images, thus I can't use that method and I have to find a way to get the DVD tree accessible by the kickstart image in a secure way. – maxschlepzig Oct 27 '14 at 16:55
  • The only other method that I can think of is using qemu to boot into an nfs mounted livecd image. – geedoubleya Oct 28 '14 at 10:04
  • There seems to be limitations in the creation of the /root/anaconda-ks.cfg - for example when installing Cent OS 7 on RAID mirrors, the partition layout/RAID setup is not recorded at all. – maxschlepzig Dec 2 '14 at 13:17
0

You can prepare a minimal install inside a qemu KVM instance and then transfer the image to the remote system.

For example to install a RAID-1 Centos 7 system:

On you local workstation:

$ truncate --size 5G disk1.img
$ truncate --size 5G disk2.img
$ qemu-system-x86_64 \
    -cdrom CentOS-7.0-1406-x86_64-DVD/CentOS-7.0-1406-x86_64-DVD.iso \
    -hda disk1.img -hdb disk2.img -m 2G -boot d -enable-kvm \
    -net user,hostfwd=tcp::10022-:22 -net nic # enable net, ssh portforwarding

Inside the qemu instance, you can install CentOS 7 using the offical recommended installer - i.e. select the 2 disks, manual partitioning, automatically create partitions, select raid1 for the / volume group, select raid1 in the /boot device-type settings, etc. After the install is finished, you can even configure comfortably some basic stuff, e.g. update the system via yum update, accept the systems GPG keys, configure network (with the MAC-address of the target system), ssh keys etc.

For later resizing it is important that you disable the RAID 1 write intent bitmap (inside the vm):

# mdadm --grow /dev/md/*pv00 --bitmap none

To transfer the image, i.e. the left leg of the mirror (from the workstation to the server):

$ gzip -c disk1.img | ssh example.org "gzip -d | dd of=/dev/sda bs=128K"

An minimal image should compress with a very good ratio - in my experiment compressed size was about ~ 230 MiB.

For the right leg only the grub2 part is necessary:

$ dd if=disk2.img bs=512 count=2048 | gzip -c \
    | ssh example.org "zip -d | dd of=/dev/sdb bs=128K"

On the server (inside the booted rescue system) you enlarge the root volume group:

# partx -v --add /dev/sda
# mdadm --stop /dev/md/*boot --stop /dev/md/*pv00
# echo -e 'd\n2\nn\np\n2\n\n\nt\nfd\nw\n' | fdisk /dev/sda
# mdadm --run /dev/md/*boot --run /dev/*pv00
# mdadm --grow /dev/md/*pv00 --size max
# pvresize /dev/md/*pv00
# lvchange --activate y centos/root
# lvresize --resizefs --extents +100%FREE centos/root
# echo -e 'd\n2\nn\np\n2\n\n\nt\nfd\nw\n' | fdisk /dev/sdb
# mdadm --add /dev/md/*boot /dev/sdb1
# mdadm --add /dev/md/*pv00 /dev/sdb2
# mdadm --wait /dev/md/*pv00
# mdadm --grow /dev/md/*pv00 --bitmap internal
# mdadm --wait /dev/md/*pv00
# shutdown -r now

Advanced stuff

When you want to use this method to install several bare metal machines from a base image you have to use some init scripts that adjust the base image. Besides the obvious stuff (e.g. hostname, network configuration etc.) you have to change all UUIDs in the systems. This includes UUIDs of:

  • RAID devices
  • LVM PVs and VGs
  • Filesystems
  • Swap
  • Network configuration scripts under (/etc/sysconfig/network-scripts)

And then, of course, you have to change all configuration files that use those UUIDS:

  • /etc/default/grub (call grub2->mkconfig then ...)
  • /etc/mdadm.conf
  • /etc/fstab

Caveats

The process gets a little bit more complicated if the client/target system use different physical sector sizes. For example, when the target system uses 4k sectors (instead of 512 bytes). Then you have to configure qemu such that it also uses/emulates 4k physical sectors (which qemu is able to do).

Another thing to watch out is whether the target system only support UEFI boot. In that case you would also have to make sure that qemu emulates UEFI as well.

Conclusion

Using a qemu kvm instance and then transplanting the resulting install to remote machine is a relatively straight-forward process.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.