Mount error

[Gianlucode]

Hi guys,
i'm trying to create an image bootable from scratch, but i fell in error right at the beginning .
I've created an image filled by zero with

[Gianlucode]

How we are used to hear in computer science, Divide et impera!
I divided my deb.iso in 3 pices using dd. Remebering the partitions table

[szatox]

maybe a bit of necro-bump, but I'm just making some VM images, and here's a really neat trick that might be helpfull for others:

Creating big, sparse files quickly: dd if=/dev/null of=raw_disk.img bs=10GB seek=1 <-- create 10 GB disk image. Instantly.
mkfs.ext2 -E offset=1M raw_disk.img
mount -o offset=1M raw_disk.img target_directory <-- no need to create additional loops, mount will manage

[steveL]

Neat trick szatox.

Could you expand a bit more on how you'd go on to use that in VM creation, and in particular how you finish it off and seal the image, such that it can be used, please?

[szatox]

Well, the rest is pretty straight-forward (and a bit off topic), but perhaps describing it step by step will give me a kick to finaly script it... some day

The purpose of the following procedure is getting: "small image", "hosting a single application", "quickly". You can of course install whateer you want, but nothing you take for granted in case of regular installation is there by default. If you want dev or maintenance tools, you install them.

So, here it goes:

1) Create new, empty disk image (500MB in my case)
dd if=/dev/null of=raw_disk.img bs=500M seek=1
fdisk raw_disk.img <<< "o
n



w" # Well, I don't really need partitions, I just need bootable to make it parttable... or something
mkfs.ext2 -E offset=1M raw_disk.img

2) Prepare build environment:
mkdir build_root
cd build_root
tar xpf ../stage3.tbz
mount --bind /proc proc
mkdir usr/portage
mount --bind /usr/portage usr/portage
mount --bind /dev dev # <-- optional some packages throw errors if this is missing
mount --bind /usr/src usr/src # <-- also optional, same reason
mkdir target
mount ../raw_disk -o offset=1M target
chroot ./

3) change portage default opts (e.g. parallelism), masks, and USE flags to match your needs for this particular image
4) build things you want to include in the VM image - and the more important part: build time dependencies
emerge -abk <application>

5) Emerge base system. Yes, I know "build" flag is marked as "do not use it yourself", I still find it handy.
USE="build" emerge -bk --root=target --root-deps=rdeps baselayout
USE="make-symlinks" emerge -bk --root=target --root-deps=rdeps busybox
emerge -bk --root=target --root-deps=rdeps glibc
emerge -bk --root=target --root-deps=rdeps <application>
emerge -bk --root=target --root-deps=rdeps <your bootloader of choise>

6) Deal with missing config files!
chroot ./target
ln -s /proc/mounts /etc/mtab
6a) create new user/reset root password etc.
6b) create /etc/inittab allowing you access without login. Carefull: if you followed exacly, you're using busybox as init at this point, it has slightly different format thatn sysvinit
Create bootloader's config file, tell it you want to boot /boot/kernel root=/dev/sda1 with initrd /boot/initrd
Ceate your init script under /etc/init.d/rcS. Almost always it will contain at least those 3 lines, however you might want to add your application, eth0, sshd, hostname etc as well:
#! /bin/sh
ifconfig lo up
mount -o remount,rw /
Bad news is busybox offers vi instead of nano. Good news is we can exit second chroot and use nano from stage3.

7) copy kernel and initramfs
Exit chroot completly, it won't be needed anymore.
Copy kernel to boot directory. I'm lazy so I copy kernel and initramfs from my host. THat initramfs will take a lot of time during boot, but screw that, I'm too lazy to build kernel tuned for qemu
Oh, and create ./target/dev/null and ./target/dev/console. Or simply cp -a /dev/null /dev/console ./target/dev/

funny part now, system is ready, we should launch it, but it's still not bootable yet. We have to fix it! I'm pretty sure there is a better way to do that, but I don't feel like hunting it right now. Qemu however has other neat feature we can use: direct linux boot.
Before we proceed, we want to make sure we don't break filesystem before we even start. It would be best to umount /target at this point, but since it's still a draft and something might be missing, I decided to flush buffers with sync instead. Make sure you don't change anything while qemu is running:
qemu-system-x86_64 -kernel <path to your kernel file on host machine> -append root=/dev/sda1 -initrd <path to initramfs on host machine> -hda raw_disk.img
And.... once it boots, install bootloader from within your VM.
I'm used to grub1, so all it takes is:
grub-install /dev/sda (or something like that.... or interactively: grub -> root (hd0,0) -> setup (hd0) -> quit )
shutdown vm and try boot it from image this time:
qemu-system-x86_64 -hda raw_disk.img



Yeah... That's it. When you see it boot from image and greet you with command line, shut it down again and umount everything. If it doesn't... that's when you're relieved you haven't cleaned up your mountpoints yet.
Gotta stuff it into some script, make that init smarter and install bootloader without reboot (And without looping it over iSCSI it feels such an overkill) and some day it might even get usable

Short explanation about that 2 step process: it is possible to build target system directly from host, and it is possible to simply convert stage 3 into target system. Using it as a build environment and only as a build environment provides the advantage of isolating build host from VM system.
We can have different profiles on build host and on VM, different masks, different everything as long as build host can run VM's binaries. At the same time, we don't emerge things we don't need inside the VM signifficantly reducing final size of our image.

Notice that I'm using binary packages whenever possible. Building packages for the first time might take hours, but then they will install to target in a few minutes. And since they are stored in shared /usr/portage on host, you can reuse some of them in other VMs. A notable example is glibc, which takes ages to build and will be used every single time you need anything not included in busybox.

[steveL]

Thanks szatox, that's a great write-up. :-)

I've only skim-read it atm, I need some sleep before I try and take it in properly.

I'm going to play with the installer again soon, as I need to do some cross-compile stuff; this is going to come in handy.

So, thanks again.