accessing loopback filesystem+partitions on a file

accessing loopback filesystem+partitions on a file

[Luke Kenneth Casson Leighton]

[if you are happy to reply at all, please reply cc'd thank you.]

hi,

i'm really sorry to be bothering people on this list but i genuinely
don't what phrases to google for what i am looking for without getting
swamped by useless pages, which you will understand why when you see
the question, below.

background:

	i'm sort-of helping test a xen install project where a
	block device is presented as the DRIVE - not, i repeat
	not, the partitions on the drive which is the quotes
	normal quotes way of doing xen installes

	(yes there are good reasons for doing this).

	the thing is that the install is failing, and we'd duh
	like to analyse what's going on (access the log files -
	no, sshd hasn't been installed yet) after terminating
	the xen session [because afaik in xen guest sessions
	there's no way i know of to access virtual consoles 2-6]

the question is, therefore:

	* how the hell do you loopback mount (or lvm mount
	  or _anything_! something!)  partitions that have
	  been created in a loopback'd file!!!!

	  [aside from booting up a second pre-installed xen
	  guest domain and making the filesystem-in-a-file
	  available as /dev/hdb of course.]

answers of the form "work out where the partitions are, then use
hexedit to remove the first few blocks" will win no prizes here.

l.

Re: accessing loopback filesystem+partitions on a file

[Anthony Liguori]

Luke Kenneth Casson Leighton wrote:

>[if you are happy to reply at all, please reply cc'd thank you.]
>
>hi,
>  
>
Hi Luke,

>the question is, therefore:
>
>	* how the hell do you loopback mount (or lvm mount
>	  or _anything_! something!)  partitions that have
>	  been created in a loopback'd file!!!!
>  
>
See http://lists.samba.org/archive/linux/2004-December/012627.html

In summary, if you have a single partition then you can use the 
following command:

mount -o loop,offset=32256 loop.img /mnt

There's mention of a replacement loopback driver that supports 
partitions but a quick google'ing didn't turn anything up.

Regards,

Anthony Liguori

Re: accessing loopback filesystem+partitions on a file

[Mark Williamson]

> 	i'm sort-of helping test a xen install project where a
> 	block device is presented as the DRIVE - not, i repeat
> 	not, the partitions on the drive which is the quotes
> 	normal quotes way of doing xen installes
>
> 	(yes there are good reasons for doing this).

That's fine.  It's something that (is supposed to) works.

> 	* how the hell do you loopback mount (or lvm mount
> 	  or _anything_! something!)  partitions that have
> 	  been created in a loopback'd file!!!!


You could work out where the partitions are, then use hexedit... woops!  just 
kidding ;-)

This has come up before but it's easier to find the list entries when you 
remember what you're looking for ;-)

There's a patch by NASA (of all people!) that enables the Linux loopback 
driver to support partitions:
ftp://ftp.hq.nasa.gov/pub/ig/ccd/enhanced_loopback/readme.txt

There's also the "lomount" utility from QEmu:
http://www.dad-answers.com/qemu/utilities/QEMU-HD-Mounter/lomount/
Which works out where partitions are and mounts them (no kernel mods needed).

Apparently kpartx (from the multipath tools - 
http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=Home) can use the 
device mapper to create block devices for each partition.

I think I'd go with lomount, as it looks easiest.

Cheers,
Mark

> 	  [aside from booting up a second pre-installed xen
> 	  guest domain and making the filesystem-in-a-file
> 	  available as /dev/hdb of course.]
>
> answers of the form "work out where the partitions are, then use
> hexedit to remove the first few blocks" will win no prizes here.
>
> l.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: [Xen-devel] accessing loopback filesystem+partitions on a file

[Luke Kenneth Casson Leighton]

EXCELLENT.  thank you.

On Wed, Jun 29, 2005 at 02:33:05AM +0100, Mark Williamson wrote:
> > 	i'm sort-of helping test a xen install project where a
> > 	block device is presented as the DRIVE - not, i repeat
> > 	not, the partitions on the drive which is the quotes
> > 	normal quotes way of doing xen installes
> >
> > 	(yes there are good reasons for doing this).
> 
> That's fine.  It's something that (is supposed to) works.
 
 yep.  it does.

> > 	* how the hell do you loopback mount (or lvm mount
> > 	  or _anything_! something!)  partitions that have
> > 	  been created in a loopback'd file!!!!
> 
> 
> You could work out where the partitions are, then use hexedit... woops!  just 
> kidding ;-)
> 
> This has come up before but it's easier to find the list entries when you 
> remember what you're looking for ;-)
> 
> There's a patch by NASA (of all people!) that enables the Linux loopback 
> driver to support partitions:
> ftp://ftp.hq.nasa.gov/pub/ig/ccd/enhanced_loopback/readme.txt

 *curious* - why haven't these mods been merged back yet?

> There's also the "lomount" utility from QEmu:
> http://www.dad-answers.com/qemu/utilities/QEMU-HD-Mounter/lomount/
> Which works out where partitions are and mounts them (no kernel mods needed).

 _great_.

> Apparently kpartx (from the multipath tools - 
> http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=Home) can use the 
> device mapper to create block devices for each partition.
> 
> I think I'd go with lomount, as it looks easiest.

 
 okay.

 question for you.

 would there be any reason (e.g. performance increase)
 which could justify providing the block device remapping
 facility at the linux device driver level instead of in
 xen's fun-and-games?

 the non-technical (but aesthetic) justification is that
 xen provides the facility to represent block devices
 (major+minor) for use as generic block devices _anyway_ -
 just in a rather roundabout (and exclusionary i.e.
 "unfair!! i wanna play!!") manner.

 l.

 p.s. mark, what the hell are _you_ doing up at 3am??? :)

Re: accessing loopback filesystem+partitions on a file

[Luke Kenneth Casson Leighton]

EXCELLENT.  thank you.

On Wed, Jun 29, 2005 at 02:33:05AM +0100, Mark Williamson wrote:
> > 	i'm sort-of helping test a xen install project where a
> > 	block device is presented as the DRIVE - not, i repeat
> > 	not, the partitions on the drive which is the quotes
> > 	normal quotes way of doing xen installes
> >
> > 	(yes there are good reasons for doing this).
> 
> That's fine.  It's something that (is supposed to) works.
 
 yep.  it does.

> > 	* how the hell do you loopback mount (or lvm mount
> > 	  or _anything_! something!)  partitions that have
> > 	  been created in a loopback'd file!!!!
> 
> 
> You could work out where the partitions are, then use hexedit... woops!  just 
> kidding ;-)
> 
> This has come up before but it's easier to find the list entries when you 
> remember what you're looking for ;-)
> 
> There's a patch by NASA (of all people!) that enables the Linux loopback 
> driver to support partitions:
> ftp://ftp.hq.nasa.gov/pub/ig/ccd/enhanced_loopback/readme.txt

 *curious* - why haven't these mods been merged back yet?

> There's also the "lomount" utility from QEmu:
> http://www.dad-answers.com/qemu/utilities/QEMU-HD-Mounter/lomount/
> Which works out where partitions are and mounts them (no kernel mods needed).

 _great_.

> Apparently kpartx (from the multipath tools - 
> http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=Home) can use the 
> device mapper to create block devices for each partition.
> 
> I think I'd go with lomount, as it looks easiest.

 
 okay.

 question for you.

 would there be any reason (e.g. performance increase)
 which could justify providing the block device remapping
 facility at the linux device driver level instead of in
 xen's fun-and-games?

 the non-technical (but aesthetic) justification is that
 xen provides the facility to represent block devices
 (major+minor) for use as generic block devices _anyway_ -
 just in a rather roundabout (and exclusionary i.e.
 "unfair!! i wanna play!!") manner.

 l.

 p.s. mark, what the hell are _you_ doing up at 3am??? :)

Re: accessing loopback filesystem+partitions on a file

[Luke Kenneth Casson Leighton]

On Wed, Jun 29, 2005 at 02:33:05AM +0100, Mark Williamson wrote:

> Apparently kpartx (from the multipath tools - 
> http://christophe.varoqui.free.fr/wiki/wakka.php?wiki=Home) can use the 
> device mapper to create block devices for each partition.

 ah HA.

 well, given that phil has modified his d-i xen stuff to utilise lvm
 partitions (as the disk(!)) because i told him how abominably slow
 loopback is, this might actually turn out to be the best way to go.

 muhahahah.

 l.

 p.s. http://hands.com/d-i.  not officially announced.  don't blame me if
 it all goes horribly wrong.  search for "xen0".  another way to install
 xen guest OSes that does NOT involve using debootstrap.

Re: accessing loopback filesystem+partitions on a file

[Luke Kenneth Casson Leighton]

On Tue, Jun 28, 2005 at 07:30:58PM -0500, Anthony Liguori wrote:
> Luke Kenneth Casson Leighton wrote:
> 
> >[if you are happy to reply at all, please reply cc'd thank you.]
> >
> >hi,
> > 
> >
> Hi Luke,
> 
> >the question is, therefore:
> >
> >	* how the hell do you loopback mount (or lvm mount
> >	  or _anything_! something!)  partitions that have
> >	  been created in a loopback'd file!!!!
> > 
> >
> See http://lists.samba.org/archive/linux/2004-December/012627.html
> 
> In summary, if you have a single partition then you can use the 
> following command:
> 
> mount -o loop,offset=32256 loop.img /mnt
> 
> There's mention of a replacement loopback driver that supports 
> partitions but a quick google'ing didn't turn anything up.
 
 yeh, i know - pain, innit - hence my question!

 you'd have to know in advance that someone worked on this
 already such that they picked a suitable keyword e.g. "extended
 loopback" or "enhanced loopback".

 the latter gives this:

	 http://unix.freshmeat.net/projects/enloop/

 fortunately the knowledge is stored in a number of people's heads,
 namely ian and mark's, and they've kindly responded and pointed me in
 a suitable direction.

 lomount.c, a 259-line-program which cannot be found anywhere
 but in source code form, actually analyses the first block
 and performs above-suggested suitable mount commands on your behalf.

 l.