9:28 a.m.
On Fri, Aug 20, 2010 at 6:05 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Thu, Aug 19, 2010 at 11:15 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> On Thu, Aug 19, 2010 at 3:20 PM, Jasper Hartline
> I'll keep workking with this and update you with the latest, as soon
> as I get more done.
>
Well. I have failed to decrypt the FileSystem class for pyparted.
It seems you create a format object
and then pass that to Partition, like this.. below
however, upon looking at the loop device and using hexdump, and dumpe2fs
and trying to mount it, etc. It seems it is corrupt or is not a valid
filesystem.
So I'm not sure what is going on.
Also, to get the size we can just use size divided by 512.
That gives us the maximum number of sectors minus 1 for the MBR.
#!/usr/bin/python
import os
import sys
import parted
size = os.stat("/tmp/file").st_size
sectors = size / 512 - 1
device = parted.Device(path="/dev/loop0")
disk = parted.freshDisk(device, 'msdos')
start = 2
end = sectors
new_geom = parted.Geometry(device=device,
start=start,
end=end)
format = parted.FileSystem(type="ext2", geometry=new_geom).create()
partition = parted.Partition(disk=disk,
fs=format,
type=82,
geometry=new_geom)
constraint = parted.Constraint(exactGeom=new_geom)
disk.addPartition(partition=partition,
constraint=constraint)
disk.commit()
So here attached is what I have so far, it is what I would like to
continue to work on and
fox the format routing when we figure out how to use pyparted properly.
So far I have it setting up correctly and the master boot record is proper.
/dev/loop0 on /tmp/tmprjsmh3 type ext3 (rw)
/dev/loop1 on /tmp/tmpKTCs75 type iso9660 (rw)
/dev/loop2 on /tmp/tmpLi76ER type iso9660 (rw)
[root@localhost tmp]# ls -l /tmp/tmprjsmh3
total 28
drwx------ 2 root root 16384 Aug 20 03:54 lost+found
drwxr-xr-x 2 root root 4096 Aug 20 03:54 syslinux
drwxr-xr-x 2 root root 4096 Aug 20 03:54 x64
drwxr-xr-x 2 root root 4096 Aug 20 03:54 x86
[root@localhost tmp]#
I'll keep banging away at it. I'm digging through the pyparted source.
Richard
10:05 a.m.
I'll keep banging away at it. I'm digging through the
pyparted source.
Richard
Here is what I have done, put a comment in stating we need to use
pyparted in the format() function.
It is starting to get ugly in setup() where it starts
on dirs = with the list, but I can migrate most of that to functions
before I go further.
http://autopsy.liveprojects.info/scripts/mkbiarch.py
3:30 p.m.
On Fri, Aug 20, 2010 at 10:05 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> I'll keep banging away at it. I'm digging through the
pyparted source.
>
> Richard
Here is what I have done, put a comment in stating we need to use
pyparted in the format() function.
It is starting to get ugly in setup() where it starts
on dirs = with the list, but I can migrate most of that to functions
before I go further.
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Ok, only some slight updates:
def partition(temp_image): # Found a way to get the sectors through pyparted
device = parted.getDevice(temp_image)
disk = freshDisk(device, 'msdos')
constraint = parted.Constraint(device=device)
geometry = parted.Geometry(device=device, start=1,
end=(constraint.maxSize-1))
partition = parted.Partition(disk=disk, type=82, geometry=geometry)
disk.addPartition(partition=partition, constraint=constraint)
disk.commit()
---
I got it to work typing everything in manually...
Let me know what you think.
Richard
4:51 p.m.
On Fri, Aug 20, 2010 at 3:30 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Fri, Aug 20, 2010 at 10:05 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
>> I'll keep banging away at it. I'm digging through the pyparted source.
>>
>> Richard
>
> Here is what I have done, put a comment in stating we need to use
> pyparted in the format() function.
>
> It is starting to get ugly in setup() where it starts
> on dirs = with the list, but I can migrate most of that to functions
> before I go further.
>
> http://autopsy.liveprojects.info/scripts/mkbiarch.py
Ok, only some slight updates:
def partition(temp_image): # Found a way to get the sectors through pyparted
device = parted.getDevice(temp_image)
disk = freshDisk(device, 'msdos')
constraint = parted.Constraint(device=device)
geometry = parted.Geometry(device=device, start=1,
end=(constraint.maxSize-1))
partition = parted.Partition(disk=disk, type=82, geometry=geometry)
disk.addPartition(partition=partition, constraint=constraint)
disk.commit()
Ok, doing math in the function call bothered me and I figured it could
be a little more descriptive...
def partition(temp_image):
"""Creates a single partition using all available space in the
given empty device."""
device = parted.getDevice(temp_image)
disk = freshDisk(device, 'msdos')
constraint = parted.Constraint(device=device)
start_sector = 1
end_sector = constraint.maxSize - 1
geometry = parted.Geometry(device=device, start=start_sector, end=end_sector)
partition = parted.Partition(disk=disk, type=82, geometry=geometry)
disk.addPartition(partition=partition, constraint=constraint)
disk.commit()
---
Richard
1:17 a.m.
On Fri, Aug 20, 2010 at 2:51 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
> Ok, only some slight updates:
>
> def partition(temp_image): # Found a way to get the sectors through pyparted
> device = parted.getDevice(temp_image)
> disk = freshDisk(device, 'msdos')
> constraint = parted.Constraint(device=device)
> geometry = parted.Geometry(device=device, start=1,
> end=(constraint.maxSize-1))
> partition = parted.Partition(disk=disk, type=82, geometry=geometry)
> disk.addPartition(partition=partition, constraint=constraint)
> disk.commit()
Ok. I've updated the partition function:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Including updating the copy function in case we pass it a file or a directory.
5 minutes ago I would have said what else I changed, which made sense..
Now I'm at a loss for words. I'll keep working on it.
7:15 p.m.
On Fri, Aug 20, 2010 at 11:17 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Fri, Aug 20, 2010 at 2:51 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
5 minutes ago I would have said what else I changed, which made sense..
Now I'm at a loss for words. I'll keep working on it.
Hey Richard.
I was wondering if you would like to test this script out:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Here are my qemu screenshots:
http://autopsy.liveprojects.info/external/extra/biarch-x86.png
http://autopsy.liveprojects.info/external/extra/biarch-x64.png
The resulting image should be able to be dd'd direct to a RAW disk
device, like /dev/sdb
I'll try testing it on real hardware later.
If you can provide feedback I would appreciate it!!
7:17 p.m.
On Mon, Aug 23, 2010 at 5:15 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Fri, Aug 20, 2010 at 11:17 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> On Fri, Aug 20, 2010 at 2:51 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> 5 minutes ago I would have said what else I changed, which made sense..
> Now I'm at a loss for words. I'll keep working on it.
>
Hey Richard.
I was wondering if you would like to test this script out:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Here are my qemu screenshots:
http://autopsy.liveprojects.info/external/extra/biarch-x86.png
http://autopsy.liveprojects.info/external/extra/biarch-x64.png
The resulting image should be able to be dd'd direct to a RAW disk
device, like /dev/sdb
I'll try testing it on real hardware later.
If you can provide feedback I would appreciate it!!
Bruno, do you think you could test this script too and tell me, what
you think about
getting it into livecd-tools? What needs to happen?
9:08 p.m.
On Mon, Aug 23, 2010 at 17:17:43 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
Bruno, do you think you could test this script too and tell me, what
you think about
getting it into livecd-tools? What needs to happen?
I don't think I am going to get a lot of to test this. If it is a new
script to get added to the package, I don't think the barrier is too high.
There should be some documentation. Preferably a man page, but a --help
option could do for now.
The script needs a bit of support in the Makefile and spec file. I think
some of autotools is used, so it may need to be the .in or .am file that
needs to be changed.
If you guys think it is ready, I'll make a real quick look at it and get
it committed to livecd-tools master?
9:19 p.m.
On Mon, Aug 23, 2010 at 7:08 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Mon, Aug 23, 2010 at 17:17:43 -0700,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
>
> Bruno, do you think you could test this script too and tell me, what
> you think about
> getting it into livecd-tools? What needs to happen?
I don't think I am going to get a lot of to test this. If it is a new
script to get added to the package, I don't think the barrier is too high.
Ok no big deal. Will wait for more feedback too then from Kratochvil
or Richard, or Pevac.
There should be some documentation. Preferably a man page, but a
--help
option could do for now.
Ok man page, --help for basic syntax use.
The script needs a bit of support in the Makefile and spec file. I
think
some of autotools is used, so it may need to be the .in or .am file that
needs to be changed.
If you guys think it is ready, I'll make a real quick look at it and get
it committed to livecd-tools master?
Let me throw a few more dents into it, like moving the unmount
procedures at the end to cleanup() and some other small ends.
I'll see if I can attach a few files or patches later in the week.
There are still a few loose ends which after I sort those out
I think we can commit it.
So man page, help usage.
Some loose ends internally and a few Makefile in and am patches
and a spec patch. Got it.
9:23 p.m.
On Mon, Aug 23, 2010 at 7:15 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Fri, Aug 20, 2010 at 11:17 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> On Fri, Aug 20, 2010 at 2:51 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> 5 minutes ago I would have said what else I changed, which made sense..
> Now I'm at a loss for words. I'll keep working on it.
>
Hey Richard.
I was wondering if you would like to test this script out:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Here are my qemu screenshots:
http://autopsy.liveprojects.info/external/extra/biarch-x86.png
http://autopsy.liveprojects.info/external/extra/biarch-x64.png
The resulting image should be able to be dd'd direct to a RAW disk
device, like /dev/sdb
I'll try testing it on real hardware later.
If you can provide feedback I would appreciate it!!
I'm downloading some liveCDs now, it will probably be tomorrow before
I can test it. I've only got 1.5Mbit DSL. One thing, I don't think we
need the second 'constraint' statement in the parted function. At
least I didn't when I was doing it manually, but I'll test to make
sure.
Richard
6:31 a.m.
On Mon, Aug 23, 2010 at 7:23 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
>
> If you can provide feedback I would appreciate it!!
I'm downloading some liveCDs now, it will probably be tomorrow before
I can test it. I've only got 1.5Mbit DSL. One thing, I don't think we
need the second 'constraint' statement in the parted function. At
least I didn't when I was doing it manually, but I'll test to make
sure.
Ok. Just a note.
I have the man page done.
I have also updated the script again, so get the latest before testing:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
I'm trying to figure out a way to get the Fedora-$release string
easily, without just
taking it from the ISO filename. This way we can use it in teh
exlinux/syslinux config files.
By the way it is set up to use Ext3/extlinux.
8:36 a.m.
On Tue, Aug 24, 2010 at 6:31 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Mon, Aug 23, 2010 at 7:23 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
>>
>> If you can provide feedback I would appreciate it!!
>
> I'm downloading some liveCDs now, it will probably be tomorrow before
> I can test it. I've only got 1.5Mbit DSL. One thing, I don't think we
> need the second 'constraint' statement in the parted function. At
> least I didn't when I was doing it manually, but I'll test to make
> sure.
Ok. Just a note.
I have the man page done.
I have also updated the script again, so get the latest before testing:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
I'm trying to figure out a way to get the Fedora-$release string
easily, without just
taking it from the ISO filename. This way we can use it in teh
exlinux/syslinux config files.
Do we need this info before or after the ISO's are mounted? There's
got to be a file within the ISO that would have the info we need.
By the way it is set up to use Ext3/extlinux.
I think the usage() function will work for now but if we start adding
additional options, like letting the user choose what file system
format to use, we'll need to move to the optparse module.
9:42 a.m.
On Tue, Aug 24, 2010 at 6:36 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
> I'm trying to figure out a way to get the Fedora-$release
string
> easily, without just
> taking it from the ISO filename. This way we can use it in teh
> exlinux/syslinux config files.
Do we need this info before or after the ISO's are mounted? There's
got to be a file within the ISO that would have the info we need.
Just by the time we get to syslinux() which writes the config file.
I suppose I could get it from isolinux.cfg in one of the ISO files
after they are mounted.
Probably at the same place we get the UUID. where uuid = getuuid()
> By the way it is set up to use Ext3/extlinux.
I think the usage() function will work for now but if we start adding
additional options, like letting the user choose what file system
format to use, we'll need to move to the optparse module.
Right.
I figure as a base case, working script it wasn't needed right now.
So yeah. I tried implementing the optparse thing and couldn't for some reason.
Probably I was not thinking we needed options.. but if people request
them, sure.
10:32 p.m.
On Tue, Aug 24, 2010 at 7:42 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
The subject for this mkbiarch.py is sort of wrong, it's
a Python script for creating a Multi Architecture Image file for
disks, not a LiveCD creation script.
Richard, I add you to the man page as contributor.
Here is teh man page attached, process with: groff -man -Tascii mkbiarch.8
Tell me if you think it needs something.
I haven't found any bugs yet to fix.
Hans DeGeode says libparted filesystem creation code may be removed.
Not sure why.. but this he says pyparted FileSystem.create() shouldn't
be relied upon.
I'm not sure how long or how soon that is supposed to be.
I did find out FileSystem.create() object is passed to parted.Partition(type=
fs=fs.object,
geometry=new_geom)
To create the FileSystem on the partition also.
I may change to using that, but keep the other subprocess for mke2fs
just commented out.
This allows for quick change if it becomes obsolete.
10:51 p.m.
On Tue, Aug 24, 2010 at 10:32 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 7:42 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
The subject for this mkbiarch.py is sort of wrong, it's
a Python script for creating a Multi Architecture Image file for
disks, not a LiveCD creation script.
Richard, I add you to the man page as contributor.
Here is teh man page attached, process with: groff -man -Tascii mkbiarch.8
Tell me if you think it needs something.
I haven't found any bugs yet to fix.
Hans DeGeode says libparted filesystem creation code may be removed.
Not sure why.. but this he says pyparted FileSystem.create() shouldn't
be relied upon.
I'm not sure how long or how soon that is supposed to be.
I did find out FileSystem.create() object is passed to parted.Partition(type=
fs=fs.object,
geometry=new_geom)
To create the FileSystem on the partition also.
I may change to using that, but keep the other subprocess for mke2fs
just commented out.
This allows for quick change if it becomes obsolete.
The man page looks pretty good. As far as the script goes I think we
need to add some status/diagnostic info so the user at least has a
clue where they are in the process especially if something goes wrong.
Another thing I was thinking about. Is there ANY way to keep from
having to run this as root? I know losetup needs it, but is there any
other command we're calling that needs it?
I tried booting the resulting image in VirtualBox and got some
interesting results. It did boot, but I did not see a boot menu unless
it was what I saw flash for only a fraction of a second. Then it went
through the normal text mode plymouth boot process but instead of
logging in it went strait to the install menu. Not sure what's going
on there. I'll have to mount the ISO and see if syslinux got messed up
somehow.
Richard
2:27 a.m.
On Tue, Aug 24, 2010 at 8:51 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
The man page looks pretty good. As far as the script goes I think we
need to add some status/diagnostic info so the user at least has a
clue where they are in the process especially if something goes wrong.
Right.. have any patches?
Another thing I was thinking about. Is there ANY way to keep from
having to run this as root? I know losetup needs it, but is there any
other command we're calling that needs it?
mount and extlinux since it will need to read /dev/loop0 when used
with --install to overwrite the MBR.
I tried booting the resulting image in VirtualBox and got some
interesting results. It did boot, but I did not see a boot menu unless
it was what I saw flash for only a fraction of a second. Then it went
through the normal text mode plymouth boot process but instead of
logging in it went strait to the install menu. Not sure what's going
on there. I'll have to mount the ISO and see if syslinux got messed up
somehow.
It may be possible there will be bugs that show up, when
users use thier own livecd-creator made ISO images, but..
if these were the normal F13 LiveCD ISO files it should have worked.
I know some problems exist with livecd-tools' livecd-creator and some
packages in F14 Alpha.
Also udev older than 161-1 I believe might have a problem in
VirtualBox. I know Qemu suffers.
Which LiveCD ISOs were you using, which versions?
8:28 a.m.
On Wed, Aug 25, 2010 at 2:27 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Tue, Aug 24, 2010 at 8:51 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> The man page looks pretty good. As far as the script goes I think we
> need to add some status/diagnostic info so the user at least has a
> clue where they are in the process especially if something goes wrong.
Right.. have any patches?
I'll see what I can do. Didn't have time last night as I teach at a
local community college two nights a week...
> Another thing I was thinking about. Is there ANY way to keep
from
> having to run this as root? I know losetup needs it, but is there any
> other command we're calling that needs it?
mount and extlinux since it will need to read /dev/loop0 when used
with --install to overwrite the MBR.
Ok, in that case we may want to have add a check for the user the
script is being run under and stop the script from running if not
running under root. I found a python module 'getpass' which has a
function 'getuser()'. The only problem is that unless you're really
logged in as root, it still returns the normal username. In other
words running under sudo or su does not work. It has to be root from
initial login or 'su -l'.
I'll see if I can find another way.
> I tried booting the resulting image in VirtualBox and got some
> interesting results. It did boot, but I did not see a boot menu unless
> it was what I saw flash for only a fraction of a second. Then it went
> through the normal text mode plymouth boot process but instead of
> logging in it went strait to the install menu. Not sure what's going
> on there. I'll have to mount the ISO and see if syslinux got messed up
> somehow.
It may be possible there will be bugs that show up, when
users use thier own livecd-creator made ISO images, but..
if these were the normal F13 LiveCD ISO files it should have worked.
I know some problems exist with livecd-tools' livecd-creator and some
packages in F14 Alpha.
Also udev older than 161-1 I believe might have a problem in
VirtualBox. I know Qemu suffers.
Which LiveCD ISOs were you using, which versions?
I think I found the problem after I sent the email. It looks like my
download stalled at nearly 100% in Chrome. The script didn't complain
though and I think it was still able to mount the ISO but there may
have been a few bytes missing. I'm redownloading from the bittorrent.
I'll recreate the image and let you know if the problem persists. I'm
using F13 live cds.
Richard
9:39 a.m.
On Wed, Aug 25, 2010 at 6:28 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
I think I found the problem after I sent the email. It looks like my
download stalled at nearly 100% in Chrome. The script didn't complain
though and I think it was still able to mount the ISO but there may
have been a few bytes missing.
live.py in python-imgcreate has a implantisomd5 function which
is supposed to implant a checksum into the ISO9660 filesystem
if it is available at build time.
10:23 p.m.
On Wed, Aug 25, 2010 at 9:39 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Wed, Aug 25, 2010 at 6:28 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> I think I found the problem after I sent the email. It looks like my
> download stalled at nearly 100% in Chrome. The script didn't complain
> though and I think it was still able to mount the ISO but there may
> have been a few bytes missing.
live.py in python-imgcreate has a implantisomd5 function which
is supposed to implant a checksum into the ISO9660 filesystem
if it is available at build time.
Redownloading did not help, it actually boots into the installer for
the i686 image even though that's the one I suspected was wrong.
Here's the command I used:
# ../Projects/mkbiarch/mkbiarch.py
./Fedora-13-i686-Live/Fedora-13-i686-Live.iso
Fedora-13-x86_64-Live.iso Fedora-13-biarch-Live.iso
Also, after figuring out I have to add the offset=512 option to mount
in order to mount the volume I see all the files seem to be there for
both arch's. Is it possible that isolinux.cfg is being used instead of
extlinux.cfg? It's still there and could be removed I think.
Also, I've started documenting the functions, (well one anyway so far!
:) ) and added some more status info when the script is running. I've
attached the patch.
Richard
11:09 p.m.
On Thu, Aug 26, 2010 at 3:23 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Redownloading did not help, it actually boots into the installer for
the i686 image even though that's the one I suspected was wrong.
Not sure what to make of that.
You're saying it loads up Anaconda?
Also, after figuring out I have to add the offset=512 option to
mount
in order to mount the volume I see all the files seem to be there for
both arch's. Is it possible that isolinux.cfg is being used instead of
extlinux.cfg? It's still there and could be removed I think.
Yeah we can remove that directory if we want.
If we decide to make the script do multiple architecture, disk images and ISO
for DVD media we would want to use it.
I don't think isolinux is being used though.
Is there a possibility you can upload the resulting ISO file made
so I can look at it?
Also, I've started documenting the functions, (well one anyway so
far!
:) ) and added some more status info when the script is running. I've
attached the patch.
8:16 a.m.
On Thu, Aug 26, 2010 at 11:09 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Thu, Aug 26, 2010 at 3:23 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> Redownloading did not help, it actually boots into the installer for
> the i686 image even though that's the one I suspected was wrong.
Not sure what to make of that.
You're saying it loads up Anaconda?
I thought so at first but after I proceeded to the next screen I
realized it was Firstboot, which is still odd because I thought the
liveCDs were supposed to have a "liveuser" or something already setup.
> Also, after figuring out I have to add the offset=512 option to
mount
> in order to mount the volume I see all the files seem to be there for
> both arch's. Is it possible that isolinux.cfg is being used instead of
> extlinux.cfg? It's still there and could be removed I think.
Yeah we can remove that directory if we want.
If we decide to make the script do multiple architecture, disk images and ISO
for DVD media we would want to use it.
I don't think isolinux is being used though.
Is there a possibility you can upload the resulting ISO file made
so I can look at it?
I could try but I have a pretty pitiful upload speed on my DSL. What
about if we start with a dump of the file names and go from there?
Richard
10:02 a.m.
On Fri, Aug 27, 2010 at 1:16 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
> Not sure what to make of that.
> You're saying it loads up Anaconda?
I thought so at first but after I proceeded to the next screen I
realized it was Firstboot, which is still odd because I thought the
liveCDs were supposed to have a "liveuser" or something already setup.
Ok. Log into that system after clicking through firstboot.
As root.
T hen just provide the output of: blkid && mount
Also if one exists, the /root/anaconda.ks file.
> I don't think isolinux is being used though.
> Is there a possibility you can upload the resulting ISO file made
> so I can look at it?
I could try but I have a pretty pitiful upload speed on my DSL. What
about if we start with a dump of the file names and go from there?
Ok.
8:28 p.m.
On Fri, Aug 27, 2010 at 10:02 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Fri, Aug 27, 2010 at 1:16 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
>> Not sure what to make of that.
>> You're saying it loads up Anaconda?
>
> I thought so at first but after I proceeded to the next screen I
> realized it was Firstboot, which is still odd because I thought the
> liveCDs were supposed to have a "liveuser" or something already setup.
Ok. Log into that system after clicking through firstboot.
As root.
T hen just provide the output of: blkid && mount
Also if one exists, the /root/anaconda.ks file.
Never mind, I thought it was booting up the image but as it turns out
I had a virtual disk connected that I must have used to do a test
install but never booted it since installation. I can't get it to boot
to the image as a CD/DVD image... Am I supposed to be using it as a
disk instead?
Richard
9:06 p.m.
On Sat, Aug 28, 2010 at 1:28 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
On Fri, Aug 27, 2010 at 10:02 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> On Fri, Aug 27, 2010 at 1:16 PM, Richard Shaw
Never mind, I thought it was booting up the image but as it turns out
I had a virtual disk connected that I must have used to do a test
install but never booted it since installation. I can't get it to boot
to the image as a CD/DVD image... Am I supposed to be using it as a
disk instead?
Yes.
9:43 p.m.
On Fri, Aug 27, 2010 at 9:06 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Sat, Aug 28, 2010 at 1:28 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> On Fri, Aug 27, 2010 at 10:02 AM, Jasper Hartline
> <jasper.hartline(a)gmail.com> wrote:
>> On Fri, Aug 27, 2010 at 1:16 PM, Richard Shaw
> Never mind, I thought it was booting up the image but as it turns out
> I had a virtual disk connected that I must have used to do a test
> install but never booted it since installation. I can't get it to boot
> to the image as a CD/DVD image... Am I supposed to be using it as a
> disk instead?
Yes.
Ok, I had to convert the raw image to a .vdi for VirtualBox but now
when it boots it just stalls and pegs the CPU at 100%. I looked at the
log but there's no useful information.
Richard
3:49 a.m.
On Sat, Aug 28, 2010 at 2:43 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Ok, I had to convert the raw image to a .vdi for VirtualBox but now
when it boots it just stalls and pegs the CPU at 100%. I looked at the
log but there's no useful information.
That is interesting.
Can you try to boot the original disk image file with qemu -hda file.img
See if you get a similar result.
3:50 p.m.
Here is another one I've started work on:
http://autopsy.liveprojects.info/scripts/mkbackup.py
It's purpose is to create a LiveDVD out of the running system.
This LiveDVD in conjunction with Anaconda's liveinst method of doing a
direct copy
of sr0 to sda or similar lays the basis for using this as a possible
installable, backup solution.
Also has LiveCD/DVD capability, which is ok.
If you come up with anything we can do on that one too I would be glad to know.
I looked at the patch you sent for mkbiarch.py and the directory part isn't
a good thing, we don't want to make it so non-dynamic.
If we create /x86 and /x64 we could even create /x86/{kde,gnome}
/x64/{kde,gnome} which would in thoery, be able to create USB disk
image fitting all 4 ISO discs, two for x86 and two for x64.
Also adding Live.ISO capability, we want to keep extlinux and isolinux dirs.
mkbiarch.py still needs checkisomd5() though.
It is apparently only available in Anaconda, but I can't find where.
I am pretty sure it implants a MD5SUM file somewhere hidden on the
ISO,m which can be checked against
the ISO files to make sure they are not corrupt. This was really
something that could be useful.. and thank you for bringing it, up.
5:02 p.m.
On Sat, Aug 28, 2010 at 4:50 PM, Jasper Hartline
<jasper.hartline(a)gmail.com>wrote:
Here is another one I've started work on:
http://autopsy.liveprojects.info/scripts/mkbackup.py
It's purpose is to create a LiveDVD out of the running system.
This LiveDVD in conjunction with Anaconda's liveinst method of doing a
direct copy
of sr0 to sda or similar lays the basis for using this as a possible
installable, backup solution.
Also has LiveCD/DVD capability, which is ok.
If you come up with anything we can do on that one too I would be glad to
know.
See https://bugzilla.redhat.com/show_bug.cgi?id=448030 , in particular, the
edit-livecd and edit-liveos attachments. This posting has some more
background,
http://lists.fedoraproject.org/pipermail/livecd/2010-August/006098.html .
It's good to see someone else working on this goal.
--Fred
I looked at the patch you sent for mkbiarch.py and the directory part
isn't
a good thing, we don't want to make it so non-dynamic.
If we create /x86 and /x64 we could even create /x86/{kde,gnome}
/x64/{kde,gnome} which would in thoery, be able to create USB disk
image fitting all 4 ISO discs, two for x86 and two for x64.
Also adding Live.ISO capability, we want to keep extlinux and isolinux
dirs.
mkbiarch.py still needs checkisomd5() though.
It is apparently only available in Anaconda, but I can't find where.
I am pretty sure it implants a MD5SUM file somewhere hidden on the
ISO,m which can be checked against
the ISO files to make sure they are not corrupt. This was really
something that could be useful.. and thank you for bringing it, up.
5:19 p.m.
On Sat, Aug 28, 2010 at 10:02 PM, Frederick Grose <fgrose(a)gmail.com> wrote:
On Sat, Aug 28, 2010 at 4:50 PM, Jasper Hartline
<jasper.hartline(a)gmail.com>
wrote:
>
> Here is another one I've started work on:
> http://autopsy.liveprojects.info/scripts/mkbackup.py
>
> It's purpose is to create a LiveDVD out of the running system.
> This LiveDVD in conjunction with Anaconda's liveinst method of doing a
> direct copy
> of sr0 to sda or similar lays the basis for using this as a possible
> installable, backup solution.
> Also has LiveCD/DVD capability, which is ok.
See https://bugzilla.redhat.com/show_bug.cgi?id=448030 , in
particular, the
edit-livecd and edit-liveos attachments. This posting has some more
background, http://lists.fedoraproject.org/pipermail/livecd/2010-August/0....
It's good to see someone else working on this goal.
Well. These are similar but not the same.
mkbackup.py would create a LiveCD/LiveDVD out of a running system.
I don't know what edit-liveos does or edit-livecd but to my knowledge
they are only for inserting packages into an already built LiveCD ISO.
The mkbackup.py script does not do that, it simply would create a
LiveCD/DVD out of the current installed system as a means for a Live
bootable backup image, which with Anaconda, can be reinstalled to a
machine in case of disk failure or other problems.
5:34 p.m.
On Sat, Aug 28, 2010 at 6:19 PM, Jasper Hartline
<jasper.hartline(a)gmail.com>wrote:
On Sat, Aug 28, 2010 at 10:02 PM, Frederick Grose
<fgrose(a)gmail.com>
wrote:
> On Sat, Aug 28, 2010 at 4:50 PM, Jasper Hartline <
jasper.hartline(a)gmail.com>
> wrote:
>>
>> Here is another one I've started work on:
>> http://autopsy.liveprojects.info/scripts/mkbackup.py
>>
>> It's purpose is to create a LiveDVD out of the running system.
>> This LiveDVD in conjunction with Anaconda's liveinst method of doing a
>> direct copy
>> of sr0 to sda or similar lays the basis for using this as a possible
>> installable, backup solution.
>> Also has LiveCD/DVD capability, which is ok.
> See https://bugzilla.redhat.com/show_bug.cgi?id=448030 , in particular,
the
> edit-livecd and edit-liveos attachments. This posting has some more
> background,
http://lists.fedoraproject.org/pipermail/livecd/2010-August/006098.html .
> It's good to see someone else working on this goal.
Well. These are similar but not the same.
mkbackup.py would create a LiveCD/LiveDVD out of a running system.
Yes, and as the running system may have been modified, it is much like an
intentional
customization (if the dump procedure does not exclude changes).
I don't know what edit-liveos does or edit-livecd but to my knowledge
they are only for inserting packages into an already built LiveCD
ISO.
edit-livecd is for inserting packages or files; edit-liveos is proposed as a
new version to accommodate customization and branding.
The mkbackup.py script does not do that, it simply would create a
LiveCD/DVD out of the current installed system as a means for a Live
bootable backup image, which with Anaconda, can be reinstalled to a
machine in case of disk failure or other problems.
Not being familiar with dump, I found this thread interesting,
http://lists.samba.org/archive/linux/2005-April/013361.html .
--Fred
5:35 p.m.
On Sat, Aug 28, 2010 at 3:50 PM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
If you come up with anything we can do on that one too I would be
glad to know.
I looked at the patch you sent for mkbiarch.py and the directory part isn't
a good thing, we don't want to make it so non-dynamic.
Well I'm not really sure what you mean by non-dynamic, but since I
reconfigured the script to use the os.makedirs() then wouldn't it be
best to just pass the internal mkdir() the complete directory
structure you need and let it figure out if it needs to create any
intermediate directories?
Richard
6:04 p.m.
On Sat, Aug 28, 2010 at 22:19:04 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
The mkbackup.py script does not do that, it simply would create a
LiveCD/DVD out of the current installed system as a means for a Live
bootable backup image, which with Anaconda, can be reinstalled to a
machine in case of disk failure or other problems.
That's a pretty neat feature. It even gives you a good way to test that
your backups work. You'd still want to have some incremental backups to
save space.
This might be worth calling a feature for F15.
9:28 p.m.
On Sat, Aug 28, 2010 at 11:04 PM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sat, Aug 28, 2010 at 22:19:04 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
>
> The mkbackup.py script does not do that, it simply would create a
> LiveCD/DVD out of the current installed system as a means for a Live
> bootable backup image, which with Anaconda, can be reinstalled to a
> machine in case of disk failure or other problems.
That's a pretty neat feature. It even gives you a good way to test that
your backups work. You'd still want to have some incremental backups to
save space.
This might be worth calling a feature for F15.
Ok. I thought it was pretty neat too, you really have some range of
motion in your backups
when and if you can do it this way, instead of you know, the random
disk-backup image file laying around on CD.
The only really limitation I see it has, is the fact, a DVD is 4.7GB.
This means, if we
squash the root filesystem of any given system, files there must not
be larger than the maximum of what will
fit squashed in 4.7GB. Smaller of course is not an issue, but until
Blueray is more popular..
I think this Live backup media limitation would need to be limited to
a single DVD size.
There may be ways around this, maybe not. I will be at least working on getting
some base level functionality working with it here in the coming days
and would be glad to hear suggestions.
9:35 p.m.
On Sat, Aug 28, 2010 at 10:34 PM, Frederick Grose <fgrose(a)gmail.com> wrote:
Yes, and as the running system may have been modified, it is much
like an
intentional
customization (if the dump procedure does not exclude changes).
>
> I don't know what edit-liveos does or edit-livecd but to my knowledge
> they are only for inserting packages into an already built LiveCD ISO.
edit-livecd is for inserting packages or files; edit-liveos is proposed as a
new version to accommodate customization and branding.
Hm. I'm not sure I follow yet, but maybe I'm just not understanding.
What I want to work on with mkbackup.py is creating a LiveCD/LiveDVD
out of the running system, not a LiveCD system created with livecd-creator.
mkbackup.py will take the root filesystem of any given host and squash it up
and create a Live media out of it, essentially making an exact backup
of the machine's
drive, which has the ability to run as a Live operating system, but
also is installable with Anaconda's
liveinst method.
11:32 p.m.
Bruno, here are the patches to put mkbiarch into the trees for git
master and fedpkg.
Do you have any disagreement with committing these so that the larger
of the community can have access
to it. This will enable the larger community to participate in helping
improve it.
The first is the git branch upstream patch, it has mkbiarch.py
mkbiarch.8 manual page and
the Makefile patch needed to enable it.
The second file is a patch to the fedpkg tree to modify the spec file
to include mkbiarch as a file
in the %files section.
There is no version bump, no changelog entry and I think that is left
up to the committer, or if not
please advise.
11:33 p.m.
On Sun, Aug 29, 2010 at 4:32 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
Bruno, here are the patches to put mkbiarch into the trees for git
master and fedpkg.
Do you have any disagreement with committing these so that the larger
of the community can have access
to it. This will enable the larger community to participate in helping
improve it.
The first is the git branch upstream patch, it has mkbiarch.py
mkbiarch.8 manual page and
the Makefile patch needed to enable it.
The second file is a patch to the fedpkg tree to modify the spec file
to include mkbiarch as a file
in the %files section.
There is no version bump, no changelog entry and I think that is left
up to the committer, or if not
please advise.
Ok let me actually attach both of the files, since that would be nice right.
Sorry about that, here they are.
Bruno please disregard the previous message, here is the real attached files.
2:52 a.m.
On Sun, Aug 29, 2010 at 02:28:25 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
The only really limitation I see it has, is the fact, a DVD is 4.7GB.
This means, if we
squash the root filesystem of any given system, files there must not
be larger than the maximum of what will
fit squashed in 4.7GB. Smaller of course is not an issue, but until
It wouldn't be unreasonable to use a few flash drives as backup media.
That raises the limit to something that is probably usable for desktops
without a lot of media files.
2:59 a.m.
On Sun, Aug 29, 2010 at 04:33:36 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
On Sun, Aug 29, 2010 at 4:32 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
> Bruno, here are the patches to put mkbiarch into the trees for git
> master and fedpkg.
> Do you have any disagreement with committing these so that the larger
> of the community can have access
> to it. This will enable the larger community to participate in helping
> improve it.
Since these are new I don't see a problem with getting them out there
as long as they are in a testable state.
I'll try to take care of these in the next day or two. I want to see if I
can other pending patches upstream soon as well. We really should get
what we can get in over the next week, so we have another week to make
adjustments before the beta freeze.
3:12 a.m.
On Sun, Aug 29, 2010 at 7:59 AM, Bruno Wolff III <bruno(a)wolff.to> wrote:
On Sun, Aug 29, 2010 at 04:33:36 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
> On Sun, Aug 29, 2010 at 4:32 AM, Jasper Hartline
> <jasper.hartline(a)gmail.com> wrote:
> > Bruno, here are the patches to put mkbiarch into the trees for git
> > master and fedpkg.
> > Do you have any disagreement with committing these so that the larger
> > of the community can have access
> > to it. This will enable the larger community to participate in helping
> > improve it.
Since these are new I don't see a problem with getting them out there
as long as they are in a testable state.
I'll try to take care of these in the next day or two. I want to see if I
can other pending patches upstream soon as well. We really should get
what we can get in over the next week, so we have another week to make
adjustments before the beta freeze.
Ok. The mkbiarch is in a testable state.
All you must do is download Fedora Live i686 and Fedora Live x86_64
Then run it: mkbiarch.py Fedora x86 ISO Fedora x86_64 ISO Fedora
Target Disk image file.
About patches, do you have any in particular you're looking at?
Most of any of them that were not submitted by Frederick Grose were
updated by myself, to apply against git, but it is up to your
discretion if you want to apply
and test any of them. The only two I wish we could really apply soon
soon, like when you do it
is these two:
1)
https://bugzilla.redhat.com/attachment.cgi?id=436736&action=diff&...
2) https://bugzilla.redhat.com/attachment.cgi?id=424664
1) Fix bug with vfat only disks, including adding support for Ext4
2) Fix script to work on netinstaller ISO
3:19 a.m.
On Sun, Aug 29, 2010 at 08:12:57 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
About patches, do you have any in particular you're looking at?
The only one in particular had to do with --skipcopy, as I needed to
suggest an alternate version of the last one I saw. I wanted to review
what you guys had pending and the links you provided will speed that
process up. Thanks!
2:01 p.m.
On Sat, Aug 28, 2010 at 3:49 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Sat, Aug 28, 2010 at 2:43 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> Ok, I had to convert the raw image to a .vdi for VirtualBox but now
> when it boots it just stalls and pegs the CPU at 100%. I looked at the
> log but there's no useful information.
That is interesting.
Can you try to boot the original disk image file with qemu -hda file.img
See if you get a similar result.
Yup, same result. Pegs the CPU and does nothing.
Richard
3:28 a.m.
On Sun, Aug 29, 2010 at 7:01 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Yup, same result. Pegs the CPU and does nothing.
Ok. I tracked it down to the second constraint assignment in the
partition() function.
I remember removing it playing with pyparted, but it is in fact neccessary.
Here is the script, try it once again:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
If you look here the two contraint assignments are neccessary.
One sets the contraint for the device end sector, but the next one
sets the filesystem constraint.
Adding the secondary contraint fixes the issue in my testing.
I'll resumbit the patches to put this into git.
Please test though.
def partition(device):
dev = parted.Device(path=device)
disk = parted.freshDisk(dev, 'msdos')
constraint = parted.Constraint(device=dev)
new_geom = parted.Geometry(device=dev,
start=1,
end=(constraint.maxSize - 1))
filesystem = parted.FileSystem(type="ext2",
geometry=new_geom)
partition = parted.Partition(disk=disk,
fs=filesystem,
type=parted.PARTITION_NORMAL,
geometry=new_geom)
constraint = parted.Constraint(exactGeom=new_geom)
partition.setFlag(parted.PARTITION_BOOT)
disk.addPartition(partition=partition,
constraint=constraint)
disk.commit()
3:38 a.m.
On Mon, Aug 30, 2010 at 8:28 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Sun, Aug 29, 2010 at 7:01 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> Yup, same result. Pegs the CPU and does nothing.
Ok. I tracked it down to the second constraint assignment in the
partition() function.
I remember removing it playing with pyparted, but it is in fact neccessary.
Here is the script, try it once again:
http://autopsy.liveprojects.info/scripts/mkbiarch.py
Bruno, can you please make sure that the previous patches are
re-updated with these:
These are the ones which should go into git instead and I won't make
any changes until we get it into git
so as not to confuse anyone:
The patches are attached and the files can be found below:
http://autopsy.liveprojects.info/scripts/mkbiarch-git-master-initial.patch
http://autopsy.liveprojects.info/scripts/mkbiarch-fedpkg-srpm.patch
These two are also attached to this message
and for completeness, I've added the previous ones we talked about briefly:
1)
https://bugzilla.redhat.com/attachment.cgi?id=436736&action=diff&...
2) https://bugzilla.redhat.com/attachment.cgi?id=424664
1) Fix bug with vfat only disks, including adding support for Ext4
2) Fix script to work on netinstaller ISO
3) http://autopsy.liveprojects.info/scripts/mkbiarch-git-master-initial.patch
4) http://autopsy.liveprojects.info/scripts/mkbiarch-fedpkg-srpm.patch
3) mkbiarch git master initial
4) mkbiarch fedpkg srpm spec file patch
7:14 p.m.
On Mon, Aug 30, 2010 at 3:28 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Sun, Aug 29, 2010 at 7:01 PM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
If you look here the two contraint assignments are neccessary.
One sets the contraint for the device end sector, but the next one
sets the filesystem constraint.
Adding the secondary contraint fixes the issue in my testing.
I'll resumbit the patches to put this into git.
Please test though.
Ok, still a no-go in VirtualBox but QEMU worked, at least until the
vmmouse detect or whatever it was.
Screenshot:
http://picasaweb.google.com/lh/photo/jcn4g2Th6KPTFpZhEmSjFziZeUNZ9CRg4aqM...
One thing I noticed, it seems the GRUB menu options are backwards for
64bit vs. 32bit.
Richard
1:43 a.m.
On Tue, Aug 31, 2010 at 12:14 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Ok, still a no-go in VirtualBox but QEMU worked, at least until the
vmmouse detect or whatever it was.
Screenshot:
http://picasaweb.google.com/lh/photo/jcn4g2Th6KPTFpZhEmSjFziZeUNZ9CRg4aqM...
One thing I noticed, it seems the GRUB menu options are backwards for
64bit vs. 32bit.
I'm not sure what you mean about them being backwards. Care
you elaborate?
As far as vmmouse you see on the screen, that means
xorg-x11-drv-vmmmouse is not installed.
This is not an issue with mkbiarch.py though.
Does it fail to boot any further for you from this point or?
7:33 a.m.
On Tue, Aug 31, 2010 at 1:43 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Tue, Aug 31, 2010 at 12:14 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
> Ok, still a no-go in VirtualBox but QEMU worked, at least until the
> vmmouse detect or whatever it was.
>
> Screenshot:
http://picasaweb.google.com/lh/photo/jcn4g2Th6KPTFpZhEmSjFziZeUNZ9CRg4aqM...
>
> One thing I noticed, it seems the GRUB menu options are backwards for
> 64bit vs. 32bit.
I'm not sure what you mean about them being backwards. Care you elaborate?
When I selected the 32bit menu option I got a complaint that I was
trying to run a 64bit kernel on 32bit hardware (qemu, my actual
hardware/Fedora is x86_64). Now that I think about it, does the script
do any checking on the order the ISO's are supplied? If not we may
need to add some logic. I'll look at my bash history, I may have
specified them in the wrong order...
As far as vmmouse you see on the screen, that means
xorg-x11-drv-vmmmouse is not installed.
This is not an issue with mkbiarch.py though.
Does it fail to boot any further for you from this point or?
Yup, get's that far and stops.
Richard
10:33 a.m.
On Tue, Aug 31, 2010 at 5:33 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
>> One thing I noticed, it seems the GRUB menu options are
backwards for
>> 64bit vs. 32bit.
> I'm not sure what you mean about them being backwards. Care you elaborate?
When I selected the 32bit menu option I got a complaint that I was
trying to run a 64bit kernel on 32bit hardware (qemu, my actual
hardware/Fedora is x86_64). Now that I think about it, does the script
do any checking on the order the ISO's are supplied? If not we may
need to add some logic. I'll look at my bash history, I may have
specified them in the wrong order...
Yeah it doesn't check. I'm not sure how to go about checking them
right off either
or how to make it better, but I would need more time to look at it.
Of course this is why we're doing testing so I'll keep it in mind that
this is an issue.
If you have any ideas let me know.
> As far as vmmouse you see on the screen, that means
> xorg-x11-drv-vmmmouse is not installed.
> This is not an issue with mkbiarch.py though.
>
> Does it fail to boot any further for you from this point or?
Yup, get's that far and stops.
Ok can you test it on real hardware with a real USB stick too?
I did testing in Qemu and it doesn't fail.
I also did testing on real hardware and it also does not fail on
either x86 32 or x86 64.
10:17 p.m.
On Tue, Aug 31, 2010 at 10:33 AM, Jasper Hartline
<jasper.hartline(a)gmail.com> wrote:
On Tue, Aug 31, 2010 at 5:33 AM, Richard Shaw
<hobbes1069(a)gmail.com> wrote:
>>> One thing I noticed, it seems the GRUB menu options are backwards for
>>> 64bit vs. 32bit.
>> I'm not sure what you mean about them being backwards. Care you elaborate?
>
> When I selected the 32bit menu option I got a complaint that I was
> trying to run a 64bit kernel on 32bit hardware (qemu, my actual
> hardware/Fedora is x86_64). Now that I think about it, does the script
> do any checking on the order the ISO's are supplied? If not we may
> need to add some logic. I'll look at my bash history, I may have
> specified them in the wrong order...
Yeah it doesn't check. I'm not sure how to go about checking them
right off either
or how to make it better, but I would need more time to look at it.
Of course this is why we're doing testing so I'll keep it in mind that
this is an issue.
If you have any ideas let me know.
The only thing I can come up with without mounting both the squashfs
images is to do a regex search through isolinux.cfg and do something
like:
def arch(file):
"""Accepts a text file object to search through and returns system
architecture as a flag."""
x32_reg = re.compile("i[3-6]86")
x64_reg = re.compile("x86_64")
for line in <isolinux file object>:
if x32_reg.search(line): return '32BIT'
elif x64_reg.search(line): return '64BIT'
Then of course whatever function calls this function will have to do
something with that information. We'll need some logic to make sure we
have exactly one positive return for each arch type.
>> As far as vmmouse you see on the screen, that means
>> xorg-x11-drv-vmmmouse is not installed.
>> This is not an issue with mkbiarch.py though.
>>
>> Does it fail to boot any further for you from this point or?
>
> Yup, get's that far and stops.
Ok can you test it on real hardware with a real USB stick too?
I did testing in Qemu and it doesn't fail.
I also did testing on real hardware and it also does not fail on
either x86 32 or x86 64.
I don't think I have a USB stick handy that's over 1GB...
Richard
midnight
On Tue, Aug 31, 2010 at 8:17 PM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
>> need to add some logic. I'll look at my bash history, I
may have
>> specified them in the wrong order...
The only thing I can come up with without mounting both the squashfs
images is to do a regex search through isolinux.cfg and do something
like:
def arch(file):
"""Accepts a text file object to search through and returns system
architecture as a flag."""
x32_reg = re.compile("i[3-6]86")
x64_reg = re.compile("x86_64")
for line in <isolinux file object>:
if x32_reg.search(line): return '32BIT'
elif x64_reg.search(line): return '64BIT'
Then of course whatever function calls this function will have to do
something with that information. We'll need some logic to make sure we
have exactly one positive return for each arch type.
That would probably work.
10:05 p.m.
On Mon, Aug 30, 2010 at 08:38:20 +0000,
Jasper Hartline <jasper.hartline(a)gmail.com> wrote:
http://autopsy.liveprojects.info/scripts/mkbiarch-git-master-initial.patch
http://autopsy.liveprojects.info/scripts/mkbiarch-fedpkg-srpm.patch
I updated the previous mkbiarch with the current ones.
These two are also attached to this message
and for completeness, I've added the previous ones we talked about briefly:
1)
https://bugzilla.redhat.com/attachment.cgi?id=436736&action=diff&...
2) https://bugzilla.redhat.com/attachment.cgi?id=424664
I committed modified versions of those two.
7:37 a.m.
Jasper,
I picked up some 4GB memory sticks this weekend so I can test booting
the image. Is there an updated script that I should try or should the
last image I created work?
Thanks,
Richard
7:57 p.m.
On Mon, Sep 13, 2010 at 5:37 AM, Richard Shaw <hobbes1069(a)gmail.com> wrote:
Jasper,
I picked up some 4GB memory sticks this weekend so I can test booting
the image. Is there an updated script that I should try or should the
last image I created work?
This is the most recent, it should be what is currently
in git for
people to use if they need. The only bug right now is in which order
the ISO files are specified to the script. The only order that works
correctly is x86 ISO then x86 64 bit ISO currently, and the IMAGE file
as last argumnt..
http://autopsy.liveprojects.info/scripts/mkbiarch.py
4978
days inactive
5003
days old
livecd@lists.fedoraproject.org
51 comments
4 participants
participants (4)
-
Bruno Wolff III -
Frederick Grose -
Jasper Hartline -
Richard Shaw