[NEW FEATURE]Partitions on loop device for 2.6

[NEW FEATURE]Partitions on loop device for 2.6

[BlaisorBlade]

[-- Attachment #1: Type: text/plain, Size: 3915 bytes --]

NEED:
I have the need to loop mount files containing not plain filesystems, but 
whole disk images.

This is especially needed when using User-mode-linux, since to run any distro 
installer you must partition the virtual disks(and on the host, the backing 
file of the disk contains a partition table).

Currently this could be done by specifying a positive offset, but letting the 
kernel partition code handle this is better, isn't it? Would you ever accept 
this feature into stock kernel?

CC me on replies, as I'm not subscribed, please.

WHAT I DID:
The attached patch is not at all "cleaned up", nor meant for official 
inclusion yet; some problems are there, and I need allocating a new major; 
also, I'd like to use the new 32 bit dev_t, as for know I can have only 15 
partitions(instead of 63) and 16 devices. It is against stock 2.6.0 and nearby 
kernels; but it already contains the patch in "[PATCH] loop.c doesn't fail 
init gracefully" from me. I have the separate patch.

No change in the "real" loop code is done, so the patch is non-intrusive; the 
driver IO code just sees some more devices to handle, but the init routine 
map those more devices to a different major and call alloc_disk(16) rather 
than alloc_disk(1).
A HD_GETGEO ioctl is also added to make fdisk happy.

So, I've modified a bit loop.c to handle this on a new set of devices, 
/dev/ploop#p#. This because /dev/ploop1 can't have minor 1, but 16; by 
creating separate loop devices, I remove the need of recreating 
/dev/loop*(i.e. people trying to use /dev/loop1 and seeing that it's a 
partition of /dev/loop0).

Currently on major 60(to change soon, as this is experimental), and on minors 
from 0 onwards; 16 partitions per disk, so you do:
mknod /dev/ploop0 b 60 0
mknod /dev/ploop0p# b 60 #
(where # is a number from 1 to 15) and so on.

You use losetup on /dev/ploop0 normally, and can mount /dev/ploop0(if the file 
has no partition table) and SHOULD be able to mount /dev/ploop0p#. And you 
can do that and work well, but only after a BLKRRPART ioctl :-(...

ISSUES:
A) the partition table is scanned at the moment of calling add_disk, when 
there is no file attached.
So when calling losetup, the code must somehow rescan the partition. I tried 
various way, but either they don't work, I'm not sure of them, or they are 
just hacks, or all these things together. Has anyone a clue? I thought of 
calling del_gendisk and add_disk again, but I'm not sure if it's right.

 I tried these:
1)                 err = blkdev_ioctl(inode, file, BLKRRPART, 0);
which I tried but doesn't work(i.e. I get only a "unknown partition table" 
when it's called; moreover that function is not intended for such use nor is 
exported).
2) so I thought of calling ioctl, which is impossible as that needs an fd, so 
this isn't clean either.
3) none of blkdev_reread_part(even static) or rescan_partitions is exported, 
so calling them would be unclean, and calling them directly doesn't seem safe 
to me, for locking issues(i.e. rescan_partitions doesn't do any locking, 
blkdev_reread_part does it but it's static).
B) calling losetup(i.e. the ioctl's) on a partition device is the same thing 
as calling it on the whole disk, if that partition existed last time the 
partition table was read. Bug or useless feature? Avoiding this would be 
anyway difficult, I think.
C) I'm not sure the returned geometry(HD_GETGEO ioctl) is ok. What will fdisk 
do when a cylinder is not complete(i.e. cylinders*sectors*heads*512 != 
totalsize)? Or if there is less than one cylinder? Also, if the max. number 
of cylinders is 2^20(as fdisk says: is this true?), the maximum capacity is 
32Gb. If there is the need, this can be improved quite easily. Just suggest 
better geometries.

Thanks for your attention and bye!
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Kernel 2.4.21/2.6.0-test on an i686; Linux registered user n. 292729
EOSIGN





[-- Attachment #2: B-combo-Partitioned_loop_support.patch --]
[-- Type: text/x-diff, Size: 6676 bytes --]

--- ./drivers/block/loop.c.nofix	2003-12-11 19:37:08.000000000 +0100
+++ ./drivers/block/loop.c	2003-12-23 13:15:04.000000000 +0100
@@ -39,6 +39,9 @@
  * Support up to 256 loop devices
  * Heinz Mauelshagen <mge@sistina.com>, Feb 2002
  *
+ * Added partition support
+ * Paolo Giarrusso <blaisorblade_work@yahoo.it>, Dec 2003
+ * 
  * Still To Fix:
  * - Advisory locking is ignored here.
  * - Should use an own CAP_* category instead of CAP_SYS_ADMIN
@@ -65,10 +68,17 @@
 #include <linux/suspend.h>
 #include <linux/writeback.h>
 #include <linux/buffer_head.h>		/* for invalidate_bdev() */
+#include <linux/hdreg.h>
 
 #include <asm/uaccess.h>
 
-static int max_loop = 8;
+#define PLOOP_MAJOR 60 			/* FIXME: move to the right place */
+#define PARTN_BITS 4
+
+static int max_loop;
+static int max_part_loop = 8;
+static int max_nopart_loop = 8;		/* This is the number of normal loop devices
+					   (i.e. no partition support)*/
 static struct loop_device *loop_dev;
 static struct gendisk **disks;
 
@@ -607,7 +617,10 @@
 	struct loop_device *lo = data;
 	struct bio *bio;
 
-	daemonize("loop%d", lo->lo_number);
+	if (lo->lo_number < max_nopart_loop)
+	  daemonize("loop%d", lo->lo_number);
+	else
+	  daemonize("ploop%d", lo->lo_number - max_nopart_loop);
 
 	/*
 	 * loop can be used in an encrypted device,
@@ -1055,6 +1068,22 @@
 
 	return err;
 }
+static int loop_get_geo(struct loop_device *lo, struct hd_geometry *arg)
+{
+	long size;
+	struct hd_geometry geo;
+
+	size = get_capacity(disks[lo->lo_number]);
+	/* Maximum is 1 Mega cyls, so we get heads * sectors * 512 MiB as max size, i.e. 32GB; minimum is
+	 * heads * sector * 512, i.e. 32 KiB. Else no cylinders, but you just can't partition it.*/
+	geo.cylinders = (size & ~0x3f) >> 6;
+	geo.heads = 4;
+	geo.sectors = 16;
+	geo.start = 4;
+	if (copy_to_user(arg, &geo, sizeof(geo)))
+		return -EFAULT;
+	return 0;
+}
 
 static int lo_ioctl(struct inode * inode, struct file * file,
 	unsigned int cmd, unsigned long arg)
@@ -1066,6 +1095,11 @@
 	switch (cmd) {
 	case LOOP_SET_FD:
 		err = loop_set_fd(lo, file, inode->i_bdev, arg);
+		/* We need to reread the partition table. Do it here to avoid
+		 * passing the extra param down. But since this doesn't work,
+		 * comment it out for now.*/
+		/*if (!err && lo->lo_number >= max_nopart_loop)
+		  err = blkdev_ioctl(inode, file, BLKRRPART, 0); */
 		break;
 	case LOOP_CLR_FD:
 		err = loop_clr_fd(lo, inode->i_bdev);
@@ -1082,6 +1116,9 @@
 	case LOOP_GET_STATUS64:
 		err = loop_get_status64(lo, (struct loop_info64 *) arg);
 		break;
+	case HDIO_GETGEO:
+		err = loop_get_geo(lo, (struct hd_geometry *) arg);
+		break;
 	default:
 		err = lo->ioctl ? lo->ioctl(lo, cmd, arg) : -EINVAL;
 	}
@@ -1121,8 +1158,10 @@
 /*
  * And now the modules code and kernel interface.
  */
-MODULE_PARM(max_loop, "i");
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
+MODULE_PARM(max_nopart_loop, "i");
+MODULE_PARM_DESC(max_nopart_loop, "Maximum number of loop devices (1-256)");
+MODULE_PARM(max_part_loop, "i");
+MODULE_PARM_DESC(max_part_loop, "Maximum number of partitionable loop devices (1-256)");
 MODULE_LICENSE("GPL");
 
 int loop_register_transfer(struct loop_func_table *funcs)
@@ -1164,16 +1203,28 @@
 int __init loop_init(void)
 {
 	int	i;
+	int 	ret = -ENOMEM;
 
-	if (max_loop < 1 || max_loop > 256) {
-		printk(KERN_WARNING "loop: invalid max_loop (must be between"
+	if (max_nopart_loop < 1 || max_nopart_loop > 256) {
+		printk(KERN_WARNING "loop: invalid max_nopart_loop (must be between"
 				    " 1 and 256), using default (8)\n");
-		max_loop = 8;
+		max_nopart_loop = 8;
+	}
+	if (max_part_loop < 1 || max_part_loop > (256 >> PARTN_BITS)) {
+		printk(KERN_WARNING "loop: invalid max_part_loop (must be between"
+				    " 1 and %d), using default (8)\n", 256 >> PARTN_BITS);
+		max_part_loop = 8;
 	}
+	max_loop = max_nopart_loop + max_part_loop;
 
 	if (register_blkdev(LOOP_MAJOR, "loop"))
 		return -EIO;
 
+	if (register_blkdev(PLOOP_MAJOR, "ploop")) {
+		ret = -EIO;
+		goto out_noreg;
+	}
+
 	loop_dev = kmalloc(max_loop * sizeof(struct loop_device), GFP_KERNEL);
 	if (!loop_dev)
 		goto out_mem1;
@@ -1183,13 +1234,19 @@
 	if (!disks)
 		goto out_mem2;
 
-	for (i = 0; i < max_loop; i++) {
+	for (i = 0; i < max_nopart_loop; i++) {
 		disks[i] = alloc_disk(1);
 		if (!disks[i])
 			goto out_mem3;
 	}
+	for ( ; i < max_loop; i++) {
+		disks[i] = alloc_disk(1 << PARTN_BITS);
+		if (!disks[i])
+			goto out_mem3;
+	}
 
 	devfs_mk_dir("loop");
+	devfs_mk_dir("ploop");
 
 	for (i = 0; i < max_loop; i++) {
 		struct loop_device *lo = &loop_dev[i];
@@ -1205,21 +1262,36 @@
 		init_MUTEX_LOCKED(&lo->lo_bh_mutex);
 		lo->lo_number = i;
 		spin_lock_init(&lo->lo_lock);
-		disk->major = LOOP_MAJOR;
-		disk->first_minor = i;
 		disk->fops = &lo_fops;
-		sprintf(disk->disk_name, "loop%d", i);
-		sprintf(disk->devfs_name, "loop/%d", i);
+		if (i < max_nopart_loop) {
+			disk->major = LOOP_MAJOR;
+			disk->first_minor = i;
+			sprintf(disk->disk_name, "loop%d", i);
+			sprintf(disk->devfs_name, "loop/%d", i);
+		} else {
+			int idx = i - max_nopart_loop;
+			disk->major = PLOOP_MAJOR;
+			disk->first_minor = idx << PARTN_BITS;
+			sprintf(disk->disk_name, "ploop%d", idx);
+			sprintf(disk->devfs_name, "ploop/%d", idx);
+		}
+
 		disk->private_data = lo;
 		disk->queue = lo->lo_queue;
-		add_disk(disk);
 	}
-	printk(KERN_INFO "loop: loaded (max %d devices)\n", max_loop);
+
+	/* We cannot fail after we call this, so another loop!*/
+	for (i = 0; i < max_loop; i++)
+		add_disk(disks[i]);
+	printk(KERN_INFO "loop: loaded (max %d not partitioned devices "
+	    		 "and %d partitioned ones)\n", max_nopart_loop, max_part_loop);
 	return 0;
 
 out_mem4:
 	while (i--)
 		blk_put_queue(loop_dev[i].lo_queue);
+	devfs_remove("ploop");
+	devfs_remove("loop");
 	i = max_loop;
 out_mem3:
 	while (i--)
@@ -1228,9 +1300,12 @@
 out_mem2:
 	kfree(loop_dev);
 out_mem1:
+	unregister_blkdev(PLOOP_MAJOR, "ploop");
+out_noreg:
 	unregister_blkdev(LOOP_MAJOR, "loop");
-	printk(KERN_ERR "loop: ran out of memory\n");
-	return -ENOMEM;
+	if (ret == -ENOMEM) 
+		printk(KERN_ERR "loop: ran out of memory\n");
+	return ret;
 }
 
 void loop_exit(void)
@@ -1246,6 +1321,9 @@
 	if (unregister_blkdev(LOOP_MAJOR, "loop"))
 		printk(KERN_WARNING "loop: cannot unregister blkdev\n");
 
+	if (unregister_blkdev(PLOOP_MAJOR, "ploop"))
+		printk(KERN_WARNING "loop: cannot unregister blkdev #2\n");
+
 	kfree(disks);
 	kfree(loop_dev);
 }
@@ -1256,7 +1334,7 @@
 #ifndef MODULE
 static int __init max_loop_setup(char *str)
 {
-	max_loop = simple_strtol(str, NULL, 0);
+	max_part_loop = simple_strtol(str, NULL, 0);
 	return 1;
 }
 

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Sean Estabrooks]

On Wed, 24 Dec 2003 18:20:22 +0100
BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:

> NEED:
> I have the need to loop mount files containing not plain filesystems,
> but whole disk images.
> 

What does your proposed feature add to the kernel that can't be
accomplished with the "losetup" command and its offset parameter?

Sean

Re: [NEW FEATURE]Partitions on loop device for 2.6

[BlaisorBlade]

Answering to Sean Estabrooks:

1st, I asked to be CC'ed on replies, as I'm not subscribed. In fact I'm sorry 
your mail is not properly quoted, as I did this by hand.

On Wed, 24 Dec 2003 18:20:22 +0100
BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:
>> NEED:
>> I have the need to loop mount files containing not plain filesystems,
>> but whole disk images.
>> 
>
>What does your proposed feature
Note that I propose also beta-code(not actually ready due to the BLKRRPART 
problem).
> add to the kernel that can't be
>accomplished with the "losetup" command and its offset parameter?
If you read my mail, I already noted the existance of the offset parameter, 
but do you prefer:
1) to run fdisk, shoot some commands and get the offset and then put that 
offset into losetup or mount, saving some code but losing a lot of 
time(remember computers are all about saving time for humans); this could 
actually be scripted, and if you post a script to do this I could even use 
it.
2) or use existing code in the kernel to automate all this, with minimal 
intrusiveness?
I know that moving things to userspace is useful if it helps reduce kernel 
bloating(and this patch will not bloat anything); yet we could move partition 
handling to the userspace by adding an offset param for general mounts, but 
this doesn't happen.
However for this it's matter of taste.

Good bye and merry Christmas!
-- 
Paolo Giarrusso, aka Blaisorblade

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Sean Estabrooks]

[-- Attachment #1: Type: text/plain, Size: 306 bytes --]

On Wed, 24 Dec 2003 20:04:14 +0100
BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:

> this could  actually be scripted, and if you post a script to do this
> I could even use it.

The script attached works here to mount a given partition in a disk image
but it comes without a warranty ;o) 

Cheers,
Sean

[-- Attachment #2: disk.mount --]
[-- Type: application/octet-stream, Size: 352 bytes --]

#!/bin/sh
#  Usage:  disk.mount <image_filename> [mount_point [partition_#] 
FILE=$1 ; MNT=$2 ; PART=$3
UNITS=`fdisk -l "$FILE" 2>&1 | sed -ne 's#^[0-9]* heads, \([0-9]*\) sectors.*$#\1#p'`
CYL=`fdisk -l "$FILE" 2>&1 | sed -ne "s#^$FILE${PART:=1}[ *]*\([0-9]*\).*#\1#p"`
START=$((UNITS*CYL*512))
mount "$FILE" "${MNT:=/mnt/image}" -oloop,offset=$START

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Wed, 2003-12-24 16:03:32 -0500, Sean Estabrooks <seanlkml@rogers.com>
wrote in message <20031224160332.76db82a0.seanlkml@rogers.com>:
> On Wed, 24 Dec 2003 20:04:14 +0100
> BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:
> 
> > this could  actually be scripted, and if you post a script to do this
> > I could even use it.
> 
> The script attached works here to mount a given partition in a disk image
> but it comes without a warranty ;o) 

I'll try that with a SunOS formatted HDD image...

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
   ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Tomas Szepe]

On Dec-24 2003, Wed, 18:20 +0100
BlaisorBlade <blaisorblade_spam@yahoo.it> wrote:

Thanks for the patch.  Would you please inline it (instead
of attaching it) the next time you're sending one?

> 	if (register_blkdev(LOOP_MAJOR, "loop"))
> 		return -EIO;
> 
>+	if (register_blkdev(PLOOP_MAJOR, "ploop")) {
>+		ret = -EIO;
>+		goto out_noreg;
>+	}

Let's make these consistent.

>+	printk(KERN_INFO "loop: loaded (max %d not partitioned devices "
>+	    		 "and %d partitioned ones)\n", max_nopart_loop, max_part_loop);

... "%d regular loop devices and %d partitionable ones"

-- 
Tomas Szepe <szepe@pinerecords.com>

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Bill Davidsen]

BlaisorBlade wrote:
> NEED:
> I have the need to loop mount files containing not plain filesystems, but 
> whole disk images.
> 
> This is especially needed when using User-mode-linux, since to run any distro 
> installer you must partition the virtual disks(and on the host, the backing 
> file of the disk contains a partition table).
> 
> Currently this could be done by specifying a positive offset, but letting the 
> kernel partition code handle this is better, isn't it? Would you ever accept 
> this feature into stock kernel?

UML is on my list of things to learn (as opposed to "try casually and 
ignore") but have you considered using NBD?

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Maciej Zenczykowski]

> > NEED:
> > I have the need to loop mount files containing not plain filesystems, but 
> > whole disk images.

If I'm not mistaken this was asked for some time ago (a few months) on the
list and an 'enhanced loop-back device' patch was mentioned (with link)
which provides this and more - search the archives for it.

Cheers,
MaZe.

Re: [NEW FEATURE]Partitions on loop device for 2.6

[BlaisorBlade]

Alle 22:04, venerdì 2 gennaio 2004, Bill Davidsen ha scritto:
> BlaisorBlade wrote:
> > NEED:
> > I have the need to loop mount files containing not plain filesystems, but
> > whole disk images.
> >
> > This is especially needed when using User-mode-linux, since to run any
> > distro installer you must partition the virtual disks(and on the host,
> > the backing file of the disk contains a partition table).
> >
> > Currently this could be done by specifying a positive offset, but letting
> > the kernel partition code handle this is better, isn't it? Would you ever
> > accept this feature into stock kernel?
>
> UML is on my list of things to learn (as opposed to "try casually and
> ignore")
It is something a bit like VMWare. But instead of emulating hardware and 
running an OS inside that, you run a patched Linux kernel that runs as an 
userspace process on the host and provides a virtual machine, which must 
access a virtual disk, which is stored on a file.
See http://user-mode-linux.sourceforge.net/ for more info.
> but have you considered using NBD?
I didn't really know what it was, nor it seems useful for this "as is" (I've 
not really checked). Maybe that sentence means that the server program could 
do the partition parsing?
-- 
cat <<EOSIGN
Paolo Giarrusso, aka Blaisorblade
Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
EOSIGN

Re: [NEW FEATURE]Partitions on loop device for 2.6

[bill davidsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

In article <200401031905.42584.blaisorblade_spam@yahoo.it>,
BlaisorBlade  <blaisorblade_spam@yahoo.it> wrote:
| Alle 22:04, venerdì 2 gennaio 2004, Bill Davidsen ha scritto:
| > BlaisorBlade wrote:
| > > NEED:
| > > I have the need to loop mount files containing not plain filesystems, but
| > > whole disk images.
| > >
| > > This is especially needed when using User-mode-linux, since to run any
| > > distro installer you must partition the virtual disks(and on the host,
| > > the backing file of the disk contains a partition table).
| > >
| > > Currently this could be done by specifying a positive offset, but letting
| > > the kernel partition code handle this is better, isn't it? Would you ever
| > > accept this feature into stock kernel?
| >
| > UML is on my list of things to learn (as opposed to "try casually and
| > ignore")
| It is something a bit like VMWare. But instead of emulating hardware and 
| running an OS inside that, you run a patched Linux kernel that runs as an 
| userspace process on the host and provides a virtual machine, which must 
| access a virtual disk, which is stored on a file.
| See http://user-mode-linux.sourceforge.net/ for more info.

As noted, I tried it casually, got a kernel to boot and run, and decided
it wasn't a solution to problems I had at the time.

| > but have you considered using NBD?
| I didn't really know what it was, nor it seems useful for this "as is" (I've 
| not really checked). Maybe that sentence means that the server program could 
| do the partition parsing?

NBD = network block device

This allows a user-space program to publish a file which a kernel with
nbd enabled can mount as a device. So you should be able to run fdisk
and partition it, load stuff on it, and generally treat it like a drive.

Take a look at Documentation/nbd.txt, it may be exactly what you want to
provide a "block device" which can be on the same system using the
loopback interface.
-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [NEW FEATURE]Partitions on loop device for 2.6

[Bill Davidsen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 2269 bytes --]

On Mon, 29 Mar 2004, BlaisorBlade wrote:

> Alle 22:04, venerdì 2 gennaio 2004, Bill Davidsen ha scritto:
> > BlaisorBlade wrote:
> > > NEED:
> > > I have the need to loop mount files containing not plain filesystems, but
> > > whole disk images.
> > >
> > > This is especially needed when using User-mode-linux, since to run any
> > > distro installer you must partition the virtual disks(and on the host,
> > > the backing file of the disk contains a partition table).
> > >
> > > Currently this could be done by specifying a positive offset, but letting
> > > the kernel partition code handle this is better, isn't it? Would you ever
> > > accept this feature into stock kernel?
> >
> > UML is on my list of things to learn (as opposed to "try casually and
> > ignore")
> It is something a bit like VMWare. But instead of emulating hardware and 
> running an OS inside that, you run a patched Linux kernel that runs as an 
> userspace process on the host and provides a virtual machine, which must 
> access a virtual disk, which is stored on a file.
> See http://user-mode-linux.sourceforge.net/ for more info.
> > but have you considered using NBD?
> I didn't really know what it was, nor it seems useful for this "as is" (I've 
> not really checked). Maybe that sentence means that the server program could 
> do the partition parsing?
> -- 
> cat <<EOSIGN
> Paolo Giarrusso, aka Blaisorblade
> Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729
> EOSIGN

No, I had in mind that using NBD you might be able to do partitions on the
network device, depending on just how much it looks like a real block
device. And since it looks as if just about anything can be a backing
store for NBD I thought it might be useful to export the file or partition
being used as the pseudo-drive and letting the UML kernel then do
partitions on it as it will. While a loopback mount looks like a partition
more than a disk, I believe the NBD actually looks like a drive.

I played with NBD long ago when it was new stuff, but what I did would
have worked as well on a partition or a device, so I have nothing to offer
but the suggestion.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.