KVM and booting direct from disk
I've successfully migrated my Linode's to KVM, all of which are using Linode's kernels. I wanted to see if I could boot directly from disk using Arch Linux. I created a new Linode, migrated to KVM, rebuilt, updated all packages, then proceeded to attempt to install syslinux. The automatic bios install failed, though I'm not sure if I needed to use that or UEFI installation. I edited /boot/syslinux/syslinux.cfg to include the proper root device, /dev/sda, and set the console to ttyS0 in the APPEND root line.
Naturally, booting failed direct from disk with an error indicating it couldn't boot from a disk without an MBR, so I then attempted to copy the MBR on the disk, which also failed. I also changed from paravirtualization to full virtualization before trying to boot directly from disk and after the first automatic bios install failed. Interestingly enough, on full virtualization, Arch Linux failed to respond to lish through ssh, or its own ssh daemon which was running. It was booting from a Linode kernel at that point, so I'm not quite certain why that would have failed.
Does anyone have any pointers? I could, of course, upload my own raw disk image with an MBR, kernel, and the Arch system set up and it would probably work, but that seems overly complicated when I ought to be able to do so directly from Linode's Arch Linux image. I could also use Grub, but I wanted to see if I could use syslinux. Besides, I like it better anyway.
Create a raw/unformatted disk on Linode dashboard
Make it available as /dev/sdc in the normal profile and boot as normal.
fdisk the raw disk and create a primary partition large enough to hold your Arch system
cp /dev/sda /dev/sdc1
mount /dev/sdc1 on /mnt
modify /mnt/etc/fstab so that the root partition is /dev/sda1 and comment the swap line
install grub on /dev/sdc using –boot-directory=/mnt/boot
The raw disk should be bootable using direct-to-disk if you create a profile for that
Tested with Debian but this is a hack. A living system should never be copied with "cp /dev/sda /dev/sdc1".
It would be better to use a rescue disk. Tried with finnix but grub-install from finnix is tricky.
If I do that, or even rebuild using a linux image, I'm not able to boot directly from disk, which is what I'm trying to achieve. It works using a Linode kernel in paravirtualization mode, not full virtualization. I'm attempting this with Arch Linux.
Direct disk requires an MBR be installed. Our templates via the normal "Deploy/Rebuild" facility don't do that, out of the box.
Grub can install the MBR onto the disk even when there's no partition table, I think it's called a VBR at that stage? But functionally identical?
Is installing an MBR onto a non-partitioned disk and booting failing, but works fine with the same steps but on a partitioned disk?
I'm not sure. I've only tried with syslinux and attempted manual install of the boot loader on the non-partitioned disk. I've not attempted a partitioned disk, but if I do, I'll post again.
Lilo on the other hand, will gladly install.
apt-get install lilo
add or uncomment these lines in /etc/lilo.conf before the LILO per-image section
append = "console=ttyS0,115200n8" serial = 0,11520
If I read that properly, then, if I partition a raw disk and put a boot loader on it to boot directly from disk, the backup service won't be able to back it up. If I make the raw partition a particular file system like ext4, for example, it could then be mounted and backed up.
I get the raw or even raw+partitioning thing for non-Linux OSs, but not for straight Linux usage…
I thought of something similar and using pacstrap to install all the packages on the formatted raw partition, then manually installing the syslinux boot loader in the MBR of the raw disk. That would work, too, I suppose. I'd have to test it.
I don't know if the Linode backup service will back up a raw disk image, though, so that's another thing to consider also. With KVM able to boot directly from disk, perhaps there should be some facilities made available to rebuild with the operating system that has use of a raw disk image, properly set up with a boot loader and running the system's own kernel, booting directly from disk for those that may want such a setup. There are ways to do it now, but it would be a little easier to deploy directly from the Linode control panel.
Disks that contain partition tables won't be mountable.
Also, partitioned disks won't be able to resize smaller. Disk resizes larger work, but only the underlying 'disk' is resized larger - it would be up to you to figure out how to partition or expand the stuff inside.
I'll just add that I see little to no value in partitioning the actual disk itself.
As I suspected, this worked. Syslinux doesn't appear to like installing on a device formatted as a file system when that device is mounted as the root partition, since there's no root device like /dev/sda and /dev/sda1 as the partition, and nothing mounted for /boot. For those interested, here's a few steps which should work with non arch systems as well, just modify the configuration file for syslinux appropriately, which I'll be posting below.
Resize disks if needed, or if starting from the beginning, don't worry about this step.
Make a new ext4 partition that's about 100MB in size to make room for any customized kernels, or other such information. Call it boot for simplicity, or whatever you like.
Deploy a new image with the rest of the disk space, excluding swap which will automatically take from the size of the deployment. If already deployed, skip this.
Edit the configuration profile so the boot image is on /dev/sdc.
Boot your system with the latest Linode kernel and log in as root.
If /boot isn't empty, move it to /boottmp, then make a new /boot directory. Mount /dev/sdc on /boot and move the content of /boottmp to /boot and remove /boot_tmp.
Update any packages and install a kernel is needed, the Arch Linux image comes with it installed already. Install syslinux and perform a bios install. Automatic install, if your distribution supports it, ought to work. Modify or change the files posted. I used cat to output their content, but pay that part no mind.
`# cat /etc/fstab # # /etc/fstab: static file system information # #` <dir> `<type><options><dump><pass>/dev/sdb / ext4 rw,relatime 0 1 /dev/sda /boot ext4 rw,relatime 0 1 /dev/sdc none swap defaults 0 0 # cat /boot/syslinux/syslinux.cfg # Config file for Syslinux - # /boot/syslinux/syslinux.cfg DEFAULT arch PROMPT 0 # Set to 1 if you always want to display the boot: prompt TIMEOUT 50 LABEL arch LINUX ../vmlinuz-linux APPEND root=/dev/sdb console=ttyS0 rw INITRD ../initramfs-linux.img LABEL archfallback LINUX ../vmlinuz-linux APPEND root=/dev/sdb console=ttyS0 rw INITRD ../initramfs-linux-fallback.img</pass></dump></options></type>` Modify the configuration profile as follows. Boot direct from disk. /dev/sda is boot, /dev/sdb is the main image, /dev/sdc is swap. Root device stays at /dev/sda. I left the distribution helper enabled, though it could likely be safely disabled at this point, I doubt it would effect anything. Interestingly enough, in addition to the Linode kernel using more ram, at least for Arch Linux, I also get another rather odd message when using it, which doesn't appear on the Arch Linux kernel.
localhost login: root
audit: type=1006 audit(1434937001.748:2): pid=2634 uid=0 old-auid=4294967295 auid=0 old-ses=4294967295 ses=1 res=1
audit: type=1006 audit(1434937001.778:3): pid=2651 uid=0 old-auid=4294967295 auid=0 old-ses=4294967295 ses=2 res=1
Last login: Mon Jun 22 01:35:00 on ttyS0
So far, I like the kernel on Arch Linux better than the Linode kernel, I may switch over to Arch Linux kernel on the other Linodes I have now that I've got this procedure down pat and working. I've not decided just yet.
After some doing, I got booting from direct disk with Arch Linux and syslinux to work. There are two ways to go about this, I believe, though I haven't actually tested both of them, only one.
First way, create an Arch Linux image as you would deploy, make the root disk about 2GB in size for updating space. Update packages and install arch-install-scripts. Make another raw image with the rest of the space, set as /dev/sdc in the configuration profile, boot the system, then use fdisk to format the disk with a single partition, then make the file system ext4. Others would probably work too. Mount /dev/sdc1 in a directory, I used /mnt, use pacstrap to install base and syslinux. Once the installation is completed, use genfstab to generate the fstab file, arch-chroot to chroot into the directory, and install and configure everything as normal with syslinux, fstab, and other files. Be sure to edit things so sda3 in the syslinux.cfg is /dev/sda1, and make sure /dev/sdc1 is /dev/sda1 in fstab. Alternatively, you could use genfstab with -U to use UUID of the disks. Enable dhcpcd@eth0 in systemd for preliminary network access if needed, install syslinux on the non chrooted system, the one originally booted from, then create a new configuration file booting direct from disk on the raw image and setting the Arch Linux image as /dev/sdc, then reboot before doing the automatic bios install for syslinux on the Arch Linux system. Reboot in the new configuration profile, then chroot into the Arch Linux disk after mounting and perform your automatic bios install. It will succeed with a warning that setting the boot flag is unneeded since it's a block device. That's fine.
The second way would be to create two Arch Linux images as you would deploy a system, one using most of the space and the other not. Make the root device in the configuration profile the smaller disk image and the larger one /dev/sdc. Boot, update packages, install the arch-install-scripts, then mount /dev/sdc and use arch-chroot to chroot into the mounted /dev/sdc in /mnt or wherever you've mounted it. Update all packages, install syslinux and perform the automatic bios install. I haven't tried this way of doing things, so one of two things will happen. It will succeed with a warning that setting the boot flag isn't needed because it's a block device. It will fail. If it fails, the Linode kernel isn't configured like the Arch Linux one, since it succeeded while the Linode was running the Arch Linux kernel with this method, or something else is configured so you can't install the syslinux boot loader on the active and currently used device. I've even attempted the manual install of the syslinux bootloader in the /dev/sda ext4 device while it was being used with dd, which failed. My first method that I briefly outlined succeeded and I was able to boot from disk on the Arch Linux image, though it's a rather roundabout and time consuming way of doing things.
If syslinux could be installed using Finux, I suppose you could boot into that and try installing it on the Arch Linux system in the chroot after configuring the configuration files, then booting into it from there.
An interesting note, it appears the Arch Linux kernel uses about 38MB less ram than the Linode kernel. I haven't figured out why yet, and may not.
Linode kernel: # free -m total used free shared buff/cache available Mem: 991 59 871 1 61 902 Swap: 255 0 255 Arch Linux kernel: # free -m total used free shared buff/cache available Mem: 997 21 916 0 59 888 Swap: 255 0 255
I have an update. The second option I posted about deploying two Arch Linux images and installing the boot loader on the first will work. However, resizing the disk on the first image after removing the second will fail after the MBR has been altered. Here is the error message.
Image appears to be partitioned, resize aborted
I don't know if this is a bug, a limitation, or what it may be, but be aware that, at the moment, anyone trying this will have to leave their image at the size that it is, resizing an image this way won't work. I suppose an alternative would be to create two images, one about 50MB or 100MB, then another that's almost the rest of the disk images, then a third as the swap partition and mount the first image as /boot and manually install the boot loader there. That's something to try next, which should work and should get rid of the resizing issue for the main image, and hopefully, get rid of the failure to install syslinux on the running system. Why I'd have to do any of this is beyond me and I don't know if it's a limitation of the software currently running, but nevertheless, I'm having fun with it!