BitFolk » Operating Systems

I think I have this working, but there's a fairly major issue compared to how things work with CentOS 5.x: RHEL 6 (and therefore all clones) has removed the ability for the text mode installer to do custom partitioning, bootloader config or package selection:

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Installation_Guide/index.html#s1-kickstart2-file

If you select text mode for a kickstart installation, make sure that you specify choices for the partitioning, bootloader, and package selection options. These steps are automated in text mode, and anaconda cannot prompt you for missing information. If you do not provide choices for these options, anaconda will stop the installation process.

GUI mode installs are not feasible on BitFolk's current infrastructure, so it's got to be text mode.

If you don't give the installer any partitioning info then it goes ahead with its defaults, which for CentOS 6 is an LVM-based layout using ext4.

We can debate whether LVM is appropriate for the average small VM, but ext4 is not yet supported by the pygrub software BitFolk uses to boot VMs, so that's not going to work.

We can specify partitioning in the kickstart file, like this:

http://tools.bitfolk.com/ks/centos/6/ks.cfg

That results in a CentOS 6 VPS with a single ext3 root filesystem across xvda, a single swap partition across xvdb, and the core selection of packages. This is most likely good enough for most people, but it's a bit of a shame for those who wanted a more complicated partition layout.

So, I'd like some feedback from customers, especially those of you who are interested in using CentOS 6 (or Scientific Linux 6, which I will be investigating as part of #78 and will almost certainly have the same issue) regarding what you would like to see done here.

There's an open feature request (#79) for allowing customers to specify their own kickstart config. If there's going to be no other way to define custom partitioning for RHEL 6 clones then that changes from a "nice to have" feature to a "pretty much essential" feature IMHO.

If we said:

• There'll be a default BitFolk kickstart config that just does a simple unattended install as http://tools.bitfolk.com/ks/centos/6/ks.cfg almost does now, or;
• If that's not suitable, the customer will have the ability to specify their own kickstart file to do whatever custom stuff they like, on the understanding that BitFolk can only help with that on a consultancy basis.

would you consider that an acceptable enough situation to declare CentOS 6 as supported?

admin wrote:

I think I have this working, but there's a fairly major issue compared to how things work with CentOS 5.x: RHEL 6 (and therefore all clones) has removed the ability for the text mode installer to do custom partitioning, bootloader config or package selection:

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Installation_Guide/index.html#s1-kickstart2-file

If you select text mode for a kickstart installation, make sure that you specify choices for the partitioning, bootloader, and package selection options. These steps are automated in text mode, and anaconda cannot prompt you for missing information. If you do not provide choices for these options, anaconda will stop the installation process.

GUI mode installs are not feasible on BitFolk's current infrastructure, so it's got to be text mode.

You could offer the VNC GUI, so people installing the OS get given the IP to connect to over the text console and then just connect up to the GUI from their local machine.

Installing through VNC

chaldene wrote:

You could offer the VNC GUI, so people installing the OS get given the IP to connect to over the text console and then just connect up to the GUI from their local machine.

Installing through VNC

Good idea. I can imagine then offering a couple of options:

• Default unattended kickstart
• VNC GUI install
• Specify your own kickstart config

I think that should cover most bases..

I'd be happy with the option to be able to specify my own kickstart file or even just use the default one provided as I believe this is enough for the vast majority of installs.

admin wrote:

That results in a CentOS 6 VPS with a single ext3 root filesystem across xvda, a single swap partition across xvdb, and the core selection of packages.

Will I have to specify my own kickstart file if I don't have xvdb? (I prefer swapfiles over partitions)

From ks.cfg:

selinux --disabled

Is there any reason for SELinux to be disabled, other than it being too much hassle for most people?

moggers87 wrote:

Will I have to specify my own kickstart file if I don't have xvdb? (I prefer swapfiles over partitions)

Yep.

From ks.cfg:

selinux --disabled

Is there any reason for SELinux to be disabled, other than it being too much hassle for most people?

Mainly just that it's trivial to re-enable for anyone who cares about selinux. selinux has been disabled by default on all BitFolk CentOS VPSes for the last 4 years and you're the first person to ever mention it.

Looks like the VNC GUI install is working nice and simply, so is going to be a nice option for people who want an easy custom installer.

I think all the options have been covered above, but I'd vote for being able to plumb in my own KS and use that for the reinstall.

Re: Enabling SELinux - it would require a filesystem relabel (which could take a long time) if you were to re-enable it after it was disabled. Given the "defaults" on RHEL5+ are to have SELinux enabled, I'd vote for leaving it enabled and letting people disable it if they want.

If you're allowing people to have their own kickstarts, you'd need to make sure the partitioning setup is clearly documented (i.e. what drive maps to what). I did notice when doing an install on another VM providers system (who had separate disks for /boot, / and swap) that if you're using devices without partition tables the installer gets a bit 'funny' about them, and I had to create partition tables to let graphical-mode Anaconda install to the device. I don't know if this would be an issue in rescue mode or not.

cashmere wrote:

I think all the options have been covered above, but I'd vote for being able to plumb in my own KS and use that for the reinstall.

This will definitely happen.

Re: Enabling SELinux - it would require a filesystem relabel (which could take a long time) if you were to re-enable it after it was disabled. Given the "defaults" on RHEL5+ are to have SELinux enabled, I'd vote for leaving it enabled and letting people disable it if they want.

OK. I'll remove that selinux bit for centos and sl 6 onwards.

If you're allowing people to have their own kickstarts, you'd need to make sure the partitioning setup is clearly documented (i.e. what drive maps to what). I did notice when doing an install on another VM providers system (who had separate disks for /boot, / and swap) that if you're using devices without partition tables the installer gets a bit 'funny' about them, and I had to create partition tables to let graphical-mode Anaconda install to the device. I don't know if this would be an issue in rescue mode or not.

Customers define their own disks now using the "disks" command in the xen shell. The default layout is xvda and xvdb but you can add as any as you like. You can use them as disks or put filesystems directly on them.

The only restrictions in place by BitFolk at the moment are:

• First disk has to have the grub config, kernel and initrd on it. That means that / (or /boot) has to be on xvda (or xvda1).
• First disk has to be ext2 or ext3.

Other than as far as I know all installers will let you put whatever filesystems they support on as many disks as you like, LVM, encrypted disks, RAID, whatever.

Pre-existing VPSes will likely have a disk layout different to the above, quite likely with filesystems directly on block devices, which the various OS installers might not like. But should this be the case the "disks" command does allow you to just nuke it all and create new disks, which seems reasonable if you are about to do a reinstall anyway.

I believe I have this working now. That is, installer support:

• install centos_6
• install scientific_6

For each of the above, kickstart config support via the "kickstart" command for:

• Text mode install, default partitioning, default package selection
• VNC GUI mode install, largely manual
• Supply custom kickstart HTTP URL

To try out any of that make sure you're seeing xen-shell v1.48bitfolk16 (use "help" command to see version; exit and reconnect if it's not this version).

Still needs documenting.