SLES partitionless Installation

Question

Windows VMWare guests can easily be resized live. For linux guests I've used LVM (add disk, partprobe, add disk to vg, lvextend, resize2fs). This works.

I've just stumbled across the sketch of better approaches. The first seems eminently doable, use LVM physical volume without partitions. This allows extending with one extra volume (and significanly simpler and less work). It'd be even better if I could whittle it down to s single VMDK

The more tantilizing option though is hinted at in a couple of posts scattered about the internet (including the unix cousin of this sight) running off of a partitionless VMDK. This seems very clean, but I'm running into a major roadblock for testing (and implementation) installing to a partionless system.

We are a SLES/OES shop, this may well be easy with another distro, but I cannot get the installer to skip partitioning. I've tried presenting it with preformatted whole disk and various permutations of the SLES installation disk formatting process.

FWIW, here are some postings...

https://unix.stackexchange.com/questions/14010/the-merits-of-a-partitionless-filesystem (last post)

http://v-reality.info/2010/06/working-with-linux-volumes-n-vsphere/

I could manually copy/move things about. Does anyone have any suggestions?

Answer 1

If it is possible to use a whole disk as PV I would go for that. This would allow using different LVs for different mountpoints even without partitions.

As for the installer - install your system into a partitioned VM and then clone it into the raw disk of another vm. Be sure to change /boot/grub/device.map, /etc/fstab, /boot/grub/menu.lst to /dev/sda from /dev/sdaN.

You will possibly have to reinstall grub, using a rescue cd as well.

Answer 2

Over the last few months I've worked out a (set of) answers.

First, I worked out a method for a partionless install. I've ended up with a (to my mind) better approach, so the explanation is incomplete:

1. install on a one partion (no swap) virtual disk
2. create another raw disk
3. format the disk directly (mkfs -text2 /dev/WHATEVER)
4. Muck about with grub to convince it to boot. The details are somewhat hazy now (it's been a while since I worked it out) but basically it's a) booting from a rescue image (I used a gparted CD for the appropriate architecture) b) running grub from that image with force install parameters.

There were several issues with this approach. Live resizing works to point, but none of the "reread partion table" commands (kpartx and the like) work. This makes some sense, as there is no partition to read. There has to be a reboot for the resize to be recognized. But as I indicated:

THE BETTER APPROACH

This was non-intuitive to me. It does require two reboots, but that's the extent of the downtime.

1. Create a single partition install (It can work with swap, but it's cleaner without).
2. resize with VM management tool
3. rewrite the partition table with fdisk. Yep, scary, but actually is much safer then it sounds: details
   1. Create a snapshot as a safety precaution
   2. reboot or do a live rescan.
   3. print the partition table out as a precaution
   4. delete the partition table (only one partition makes this easier)
   5. recreate the partition. The default values are almost certainly correct, but that's why you save a copy.
   6. make sure to flag the partion as bootable!
   7. write it out.
   8. reboot (cross your fingers, but it will work).
   9. resize2fs

This has minimal downtime and will work with stock installs. It's considerably simpler then LVM approaches. It can be retroactively applied to almost any install (multiple partitions just make the recreation more complicated). It's much much quicker (and I'd counter-intuitively argue safer) then the gparted approach.