Deploy Arch on a small partition

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.

Hi,

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.

Blake

The Linode Backup Service needs to be able to mount the disk. It doesn't care if it's marked as RAW or anything else. If it contains a filesystem that the backup service VM can mount, it will back it up.

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.

-Chris

Hi,

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.

Blake

Yes, correct - but why not just create it 'ext4' via the Manager in the first place?

I get the raw or even raw+partitioning thing for non-Linux OSs, but not for straight Linux usage…

-Chris

Hi,

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.

Blake

OK, gotcha.

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?

-Chris

Hi,

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.

Blake

For what it's worth, Grub and Grub2 are pretty stubborn about installing to a whole disk filesystem. The first 512 bytes are available for the taking, so it is possible but those tools don't make it easy.

Lilo on the other hand, will gladly install.

apt-get install lilo

liloconfig

add or uncomment these lines in /etc/lilo.conf before the LILO per-image section

  append = "console=ttyS0,115200n8"
  serial = 0,11520

#

Then run:

update-lilo

Hi,

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

Blake

Hi,

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!

Blake

Hi,

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
Password:
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
[root@localhost ~]#

````

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.

Blake

```