[Qemu-devel] Re: coping with fdisk mutation (was Re: replies)

[Qemu-devel] Re: coping with fdisk mutation (was Re: replies)

[Bob Barry]

Jim -

On Sun, 27 Jun 2004 22:23, you wrote (to Damien Mascord):
> > Because it is possible that 
> > a new version of fdisk will change it's screen output and "wreck" 
> > lomount...
> 
> That's the problem that we have here.

Consider sfdisk - it's intended for non-interactive (script) use.
It is in the util-linux package (though some high-handed
distributions omit it).  See file "sfdisk.examples" in the tarball.

Bob

[Qemu-devel] Re: coping with fdisk mutation (was Re: replies)

[Jim C. Brown]

On Tue, Jun 29, 2004 at 07:51:52PM +0200, Bob Barry wrote:
> Jim -
> 
> On Sun, 27 Jun 2004 22:23, you wrote (to Damien Mascord):
> > > Because it is possible that 
> > > a new version of fdisk will change it's screen output and "wreck" 
> > > lomount...
> > 
> > That's the problem that we have here.
> 
> Consider sfdisk - it's intended for non-interactive (script) use.
> It is in the util-linux package (though some high-handed
> distributions omit it).  See file "sfdisk.examples" in the tarball.
> 
> Bob

It would still have the same problem: the screen output of sfdisk -l
could change and lomount would no longer work. Futhermore, there is the
problem that fdisk/sfdisk will output junk like:

                start: (c,h,s) expected (0,1,1) found (0,0,3)
                end: (c,h,s) expected (53,9,2) found (1,26,2)

which we otherwise don't care about, but which messes up the format of output.

However someone else submitted to me a program which can read the necessary
information from the disk image itself. I have merged this into lomount,
so the latest bleeding-edge version of lomount (not yet released) will work
w/o any dependences on the version of fdisk that you have.

Obviously, lomount still requires a version of mount that supports using loop
(as well as losetup) but just about everyone has that.

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: coping with fdisk mutation (was Re: replies)

[Herbert Poetzl]

On Tue, Jun 29, 2004 at 03:54:39PM -0400, Jim C. Brown wrote:
> On Tue, Jun 29, 2004 at 07:51:52PM +0200, Bob Barry wrote:
> > Jim -
> > 
> > On Sun, 27 Jun 2004 22:23, you wrote (to Damien Mascord):
> > > > Because it is possible that 
> > > > a new version of fdisk will change it's screen output and "wreck" 
> > > > lomount...
> > > 
> > > That's the problem that we have here.
> > 
> > Consider sfdisk - it's intended for non-interactive (script) use.
> > It is in the util-linux package (though some high-handed
> > distributions omit it).  See file "sfdisk.examples" in the tarball.
> > 
> > Bob
> 
> It would still have the same problem: the screen output of sfdisk -l
> could change and lomount would no longer work. Futhermore, there is the
> problem that fdisk/sfdisk will output junk like:
> 
>                 start: (c,h,s) expected (0,1,1) found (0,0,3)
>                 end: (c,h,s) expected (53,9,2) found (1,26,2)
> 
> which we otherwise don't care about, but which messes up the format of output.
> 
> However someone else submitted to me a program which can read the necessary
> information from the disk image itself. I have merged this into lomount,
> so the latest bleeding-edge version of lomount (not yet released) will work
> w/o any dependences on the version of fdisk that you have.

# sfdisk -d /store/QEMU/IMGs/TEST_32M.img
# partition table of /store/QEMU/IMGs/TEST_32M.img
unit: sectors

/store/QEMU/IMGs/TEST_32M.img1 : start=       63, size=   65457, Id=83
/store/QEMU/IMGs/TEST_32M.img2 : start=        0, size=       0, Id= 0
/store/QEMU/IMGs/TEST_32M.img3 : start=        0, size=       0, Id= 0
/store/QEMU/IMGs/TEST_32M.img4 : start=        0, size=       0, Id= 0

this is standartized ... and as it is a 'dump' format
for later usage, it will not change without any good
reason ... 

best,
Herbert

> Obviously, lomount still requires a version of mount that supports using loop
> (as well as losetup) but just about everyone has that.
> 
> -- 
> Infinite complexity begets infinite beauty.
> Infinite precision begets infinite perfection.
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel