> From: John.Florian@dart.biz
>
> Is there any way I can get livecd-iso-to-disk to do its thing with
a
> target that is not a regular block-device?
>
> I spin images regularly throughout the work day and then have to
> transfer the image to a CF or SD card using this tool, then drop
> said card into a host for each test cycle. This is, of course,
> tedious. I'd like to shorten the process by using a VM as the
host
> and simply point this VM to a disk image file that I populate
> directly with livecd-iso-to-disk. Presently, the tool balks
at my
> attempt complaining with the error that, "test.img is not a block
device".
>
> I already have used the VM to run the ISO directly, but that is
> insufficient for my use case because I absolutely need the
> persistent storage that usually is possible via the remaining space
> of the CF/SD card. Yes, I could create a second virtual disk
for
> the persistent storage, but that would require lots of retooling of
> my various OS hooks and arguably be sufficiently different to the
> normal deployment that it would be a weak test at best.
After a bit of poking around in /usr/bin/livecd-iso-to-disk,
I see getdisk() and isdevloop() which hinted at me (where the docs did
not) to try the following:
# dd if=/dev/zero of=test.img bs=1G
count=2
# losetup --find --show test.img
/dev/loop0
# livecd-iso-to-disk --reset-mbr --noverify
my.iso /dev/loop0
After that completed I configured a
libvirt VM with an IDE disk whose source path was /dev/loop0 and storage
format was raw. The VM booted and behaved perfectly as I'd hoped.
I'll have to play with this for a while
to see if it can be made a bit less cumbersome. Another option I
toyed with was creating a logical volume to serve the same purpose as test.img
here. That was in fact how I wound looking at getdisk() because it
chokes on logical volume type block devices and probably all virtual block
devices from what I've seen. If I put together a patch to allow this,
would that be of interest to the livecd-tools project?
--
John Florian