On a remote Ubuntu server, I performed a series of upgrades/changes to go from a desktop-install Ubuntu 10.10 Maverick to a server-install of 12.04 LTS Precise

This all went well except a few hiccups I got around, all the while without physical access -so far-. The next goal is to create a XEN server using LVM as backend storage. The system didn't have LVM on it, which I added once I got to 12.04 LTS. I know how to create a XEN machine of it remotely, done it before. But I have an issue trying to boot into the new configuration.

The original person that installed this box didn't pay attention to the partitioning; the machine was used as a server but installed as desktop (this I fixed), but left me with this kind of partitioning scheme:

Disk /dev/sda: 500.0 GB, 499999834112 bytes
Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1       58558   470361088   83  Linux
/dev/sda2           58558       60789    17916929    5  Extended
/dev/sda5           58558       60789    17916928   82  Linux swap / Solaris

So I took the huge 17G swap partition and reorganised it a bit into a fresh boot (now /dev/sda2), a small swap partition(/dev/sda3) and a new root (lvs). I got the diskusage down to about 3GB which is small enough and I copied that to a new root, which I created under LVM.

Currently we have

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   940724223   470361088   83  Linux
/dev/sda2   *   940724224   941748223      512000   83  Linux
/dev/sda3       941748224   943845375     1048576   82  Linux swap / Solaris
/dev/sda4       943845376   976562175    16358400   8e  Linux LVM

/dev/sda1 is the old boot partition and I want the machine to boot from /dev/sda2. The difference now is that I now want a separate /boot and / partition. The root partition is known under LVM as :

# lvscan
ACTIVE            '/dev/server20/root' [10.00 GiB] inherit

The ultimate goal is that I want to bring /dev/sda1 under LVM control, but I have to boot the system in a way that it's not used. From there on, LVM will work.

In addition to the whole filesystem changes above, I did:

created logical volume:

pvcreate /dev/sda4 
vgcreate server20 /dev/sda4
lvcreate -L 10G -n root server20
mkfs.ext4 /dev/server20/root

mounted it:

mount /dev/server20/root /mnt/root/
mount /dev/sda2 /mnt/root/boot/
(cd / ; find . -xdev -print0 | rsync -xavz . /mnt/root/)
for i in /dev /run /dev/pts /proc /sys; do sudo mount -B $i /mnt/root$i; done

update grub:

chroot /mnt/root
echo "dm-mod" >> /etc/initramfs-tools/modules
echo "dm-mod" >> /etc/modules
grub-mkconfig (verified config file visually)
update-grub (no errors/warnings)

Reviewed the created /boot/grub/grub.cfg I see most looks correct, especially stuff like:

insmod lvm
set root='(server20-root)'
search --no-floppy --fs-uuid --set=root 0bb92c24-8c02-4fa3-8f75-970076261b2f

menuentry 'Ubuntu, with Linux 3.2.0-38-generic' --class ubuntu --class gnu-linux --class gnu --class os {
    gfxmode $linux_gfx_mode
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='(hd0,msdos2)'
    search --no-floppy --fs-uuid --set=root 891b3eaa-fb43-4a42-9789-a91c2a5ffb13
    linux   /vmlinuz-3.2.0-38-generic root=/dev/mapper/server20-root ro quiet
    initrd  /initrd.img-3.2.0-38-generic

Then, checking blkid's:

/dev/sda2: UUID="891b3eaa-fb43-4a42-9789-a91c2a5ffb13" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda4: UUID="IyDrfU-TOYT-rFXO-JknG-rwEK-Sm2A-mfKcIe" TYPE="LVM2_member"
/dev/mapper/server20-root: UUID="0bb92c24-8c02-4fa3-8f75-970076261b2f" TYPE="ext4"
/dev/sda1: UUID="888c061a-1d51-4516-aced-4bb21042d2f4" TYPE="ext4"
/dev/sda3: UUID="19efc041-eccd-42c9-94aa-5b6c88ffd5bb" TYPE="swap"

So, I understand from this is: my boot partition will be msdos2, that would be /dev/sda2 . Also referenced in the search line by uuid, even though it says root, I compared it to other installs and that is meant as the boot uuid (correct assumption?) in case of a split root/boot.

I really assumed this would work to reboot using the additional disk layout, but it didn't. I set both /dev/sda1 and /dev/sda2 bootable flag active using fdisk. It booted the same old way as before, without a hiccup luckily.

My deeper questions are probably sparked in misunderstanding using chroot + update-grub. I actually am not sure what I need to do on the root/boot /dev/sda1 . Do I have to copy the grub.cfg from the chrooted version to the /boot subdir or not ?

Steps I took after the reboot now

switched off bootable flag on /dev/sda1
remounted everything again and performed all steps again plus an additional
grub-install /dev/sda  (from the chroot)

Will this be enough to disregard /dev/sda1 ? I read about everything on grub I could find but I fail to get answers on how the boot process goes in case of 2 boot partitions on the same disk. (lots of other cases). Can someone visualize the grub flow in regards to using a chroot vs using something alike grub-install --boot-directory=/mnt/boot . How is this internally treated?

Feel free to suggest better titles for this question, I'm very bad at that.

Additionally , here's the MBR

dd if=/dev/sda of=mbr.bin bs=512 count=1
root@server20:/# file mbr.bin 
mbr.bin: x86 boot sector; 
partition 1: ID=0x83, starthead 32, startsector 2048, 940722176 sectors; 
partition 2: ID=0x83, active, starthead 95, startsector 940724224, 1024000 sectors; 
partition 3: ID=0x82, starthead 29, startsector 941748224, 2097152 sectors; 
partition 4: ID=0x8e, starthead 167, startsector 943845376, 32716800 sectors, code offset 0x63

1 Answer 1


I tried one more reboot, it seems that the last 3 steps I did fixed the problem:

using fdisk to switch off bootable flag for /dev/sda1
partprobe so the kernel knows about changes
remounted everything again on top of root at /mnt/root and performed:
grub-install /dev/sda  (from the chroot)

the MBR dump made me believe it worked this time. and I've booted up using the lvm root. It seems the boot partition mount failed, but the system did go through. I'll have to change it again with a smaller /dev/sda1 and do the same procedure.

You must log in to answer this question.

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