On Tue, Aug 17, 2010 at 7:07 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Tue, Aug 17, 2010 at 1:19 AM, Jasper Hartline
> That is a way to use dmsetup and kpartx (device mapper)
> to actually make the loop device have partitions which we are more
> used to using.
>
> I think my offset into the original file is off in the second loop device setup.
I checked out the link and it obviously uses a lot of shell commands.
I think at some point a shell script would be better than a bunch of
subprocess calls, however, I think much of it could be mitigated by
using modules that allow us to get the same result without the
subprocess calls. I haven't had time to check it out, but I saw a
reference to pyparted which might allow us to do the 'partitioning' of
the lodev natively.
Yeah. Pretty much I'll just use what I have as a skeleton I suppose.
pyparted. I was just thinking how many Python modules.. I could use.
Is it worth doing completely in Python using a few modules?
So far I've come to the conclusion livecd-iso-to-disk needs large bits
hacked on it
or.. I could duplicate some of what livecd-iso-to-disk does in the
mkbiarch.py script.
Here's the problem with using livecd-iso-to-disk:
It thinks you have a real block device
It tries to add "1" to "dev" so "sda" becomes
"sda1" for example.
It doesn't like using device mapper mapped devices.. found that out last night.
(/dev/dm-1 for example which is /dev/mapper/loop0p1)
The existing bug in livecd-iso-to-disk where checkFilesystem() is after
a specific section in the code, makes it always default to mkfs.vfat
regardless of partition type.
I think some other reasons why I will probably write mkbiarch.py to
just do what it needs
bypassing livecd-iso-to-disk.