On Wed, Aug 18, 2010 at 5:14 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Wed, Aug 18, 2010 at 6:51 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
>> def blocks(block_size, size):
>> # Round up to nearest block
>> # Make sure floating math, not integer math or we don't get
remainders.
>> # Turn back into an integer for return statement.
>> return int(math.ceil(size / float(block_size)))
>>
>> I'm not sure why we would need this.
>> Any idea?
>
> I have some experience in this area as I'm now the discspan (check it
> out on freshmeat or sourceforge) maintainer. ISO 9660 also has 2k
> sectors so in order to properly estimate the size you have to round up
> to the nearest sector per file.
Hm.
we divide (x86size + x64size) by block_size -> 2048 to get count for
passing to dd.
The way I understand it, mkisofs pads the ISO up to the last 2048
divisible block.
There shouldn't be a reason why a ISO file made with mkisofs is not
divisible by 2048.
Ok, I guess I'm confused here. If mkisofs pads the data, why do we
have to calculate the number of 2048k blocks at all? If we do need to
know the number of 2048k blocks then we need floating point math since
integer math will drop the remainder.
Maybe once the code is flushed out more I'll see exactly what's going on.
>> def parse(x86, x64, multi):
>> for file in x86, x64, multi: # Do we expect that multi exists yet?
>> if os.path.exists(file): # Should we test for existance
>> or isfile?
>> pass
>> else:
>> parser.error("One of the images does not exist.")
>> setup(x86, x64, multi)
>>
>> multi is our end-result target file.
>> This begins with a temporary file, that is then partitioned and formatted.
>> Copied to, and closed up eventually, then shutil.move(tmpfile, multi)
>
> Ok, obviously the code isn't fully flushed out but it looks like
> currently the test for existence happens before it's created.
Yeah I noticed that. I want to set it, but not test for it and produce
an error or usage.
In that case we only need to test for existence of the two source
images which could be done in an if statement:
if os.path.exists(x86) and os.path.exists(x64):
...
>> Maybe both. if os.path.exixts() and if os.path.isfile()
>> Then again, there shouldn't be a reason we should disallow use of
>> hardlinked ISO image files or soft linked ones. Have any logic behind
>> preventing use of the files if they are links and not files?
>
> As long as they're usable/accessible I guess it shouldn't matter, but
> if a ISO is referenced we can feel pretty good that it's going to
> work, if it's something else, like the image mounted on /dev/sr0, does
> that change how we do anything? For one, the files will be already
> accessible unlike an ISO which we would have to mount first.
>
> I think depends on how far we want to get in the first "release". It
> would be OK with me to require the sources be ISO's at this point for
> simplicity sake...
Yeah right now we want to keep it simpler until we get the base case working.
2 ISO files, one target which is multiarch.
>> try: # Any reason this would fail?
>> parse(args[0], args[1], args[2])
>> except:
>> parser.error("Something failed. Better luck next time!")
>> sys.exit(1)
>>
>> Yes, when the files don't exist it will fail with an IndexError
>> on sys.argv[]
>
> Well I'm already testing that there are exactly 3 arguments during
> option parsing so parse() itself should never fail, now since it calls
> other functions that may fail it kinda make sense. I am concerned
> though that we're essentially wrapping the entire program in a 'try'
> statement, which I'm guessing is probably not a good programming
> practice. It could also mask problems we should be handling, right?
Yes, I did this on purpose, in the foresight to be run from cron or as
a nightly operation.
It probably works as a good bandaid for now, but we could probably
create a "check_requirements" or some other named function that would
make sure all the bash commands are available and the arguments as
passed are acceptable.
>> I think I might also do something different with the
syslinux.cfg stuff.
>> Instead of having the huge text data as a content "" and filled.
>> Instead read the ISOLINUX.CFG and use re.search and re.match
>> To find what we need, then concatenate using line indexes
>> from readlines().
>>
>> Can contents = fd.readlines() be written to?
>> Do you know? Is the content of contents static?
>
> I think so as it returns a list. I just made sure it doesn't return a generator.
Hm. Right. so no string replace operations on a list, bummer.
But, we could create a new list out of the old.
Read data we want from the old list,
create a new list, with the new inputs and write it to the file.
Either that or have a separate source file that we can substitute the
proper variables into before writing. I guess it depends if we want it
to be the same as one of the source cfg files except what we need to
be different or if we'd rather specify what it looks like.
As far as keeping it simpler for now, you can see I've done that
by saying we need to partition the lodevivce type 0x83
We can expand this later.
I guess I need clarification on what the objective is here. I can see
2 or 3 possible paths.
One would be a script that takes two live CD ready images (ISOs) and
creates a multiarch ISO out of it. This would not necessarily care
about partitioning since the live-cd-iso-to-disk should be able to
handle it.
Another would be a script that only cared about creating a bootable
partition (regardless of whether it's a hard disk or USB partition).
The third would be a script that would handle both situations natively
without relying on the livecd-iso-to-disk script.
What's your thoughts there?
Richard