Re: Problem with usb-storage and /dev/sd?

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:

>     I'm not using hotplug currently so... how can I make the USB
> subsystem to assign always the same /dev/sd? entry to my USB Mass
> storage devices? [...]

You cannot. Just mount by label or something... Better yet, install
something like Fedora Core 4, which uses HAL, and forget about it.
The fstab-sync takes care of the rest.

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:
> >     I'm not using hotplug currently so... how can I make the USB
> > subsystem to assign always the same /dev/sd? entry to my USB Mass
> > storage devices? [...]
> You cannot. Just mount by label or something...

    Mounting by label won't work, the problem is the /dev entry,
which changes every time.

> Better yet, install something like Fedora Core 4, which uses HAL,
> and forget about it. The fstab-sync takes care of the rest.

    Oh no, thanks, I've already used Fedora and it only reinforced my
feeling about distros: I prefer my do-it-yourself box ;)

    Thanks :)))

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Horst von Brand]

DervishD <lkml@dervishd.net> wrote:
>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:
> > >     I'm not using hotplug currently so... how can I make the USB
> > > subsystem to assign always the same /dev/sd? entry to my USB Mass
> > > storage devices? [...]
> > You cannot. Just mount by label or something...

>     Mounting by label won't work, the problem is the /dev entry,
> which changes every time.

That's why you should mount by label...

> > Better yet, install something like Fedora Core 4, which uses HAL,
> > and forget about it. The fstab-sync takes care of the rest.
> 
>     Oh no, thanks, I've already used Fedora and it only reinforced my
> feeling about distros: I prefer my do-it-yourself box ;)

In Fedora rawhide it just works. I can't see how the knot you are tying
yourself into by diy is any better...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: Problem with usb-storage and /dev/sd?

[Bodo Eggert]

Horst von Brand <vonbrand@inf.utfsm.cl> wrote:
> DervishD <lkml@dervishd.net> wrote:
>>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
>> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <lkml@dervishd.net> wrote:

>> > >     I'm not using hotplug currently so... how can I make the USB
>> > > subsystem to assign always the same /dev/sd? entry to my USB Mass
>> > > storage devices? [...]
>> > You cannot. Just mount by label or something...
> 
>>     Mounting by label won't work, the problem is the /dev entry,
>> which changes every time.
> 
> That's why you should mount by label...

Which label will a random USB stick have?
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:

> Which label will a random USB stick have?

GUID, I presume. Ask Andries Brouwer, he hacked on that, IIRC.
Actually msdos has on-disk format for user-settable labels in
the way analoguous to tune2fs -L label. I just do not know if
our implementation recognizes them.

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > Which label will a random USB stick have?
> GUID, I presume. Ask Andries Brouwer, he hacked on that, IIRC.
> Actually msdos has on-disk format for user-settable labels in
> the way analoguous to tune2fs -L label. I just do not know if
> our implementation recognizes them.

    My vfat's in my MP3 player and the USB stick doesn't have a
label, at least not one usable by 'mount' (which only uses ext2/3
labels and xfs labels AFAIK).

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Bodo Eggert]

On Fri, 12 Aug 2005, Pete Zaitcev wrote:

> On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> 
> > Which label will a random USB stick have?
> 
> GUID, I presume.

A global unique ID won't work out to make all USB mass storage devices
appear under a common mountpoint, especially if it is recreated while
"formating" it.

-- 
The enemy diversion you have been ignoring will be the main attack. 

Re: Problem with usb-storage and /dev/sd?

[Pete Zaitcev]

On Sat, 13 Aug 2005 12:06:16 +0200 (CEST), Bodo Eggert <7eggert@gmx.de> wrote:
> On Fri, 12 Aug 2005, Pete Zaitcev wrote:
> > On Fri, 12 Aug 2005 12:49:28 +0200, Bodo Eggert <harvested.in.lkml@7eggert.dyndns.org> wrote:
> > 
> > > Which label will a random USB stick have?
> > 
> > GUID, I presume.
> 
> A global unique ID won't work out to make all USB mass storage devices
> appear under a common mountpoint, especially if it is recreated while
> "formating" it.

That is correct, but not what Dervish wanted. He wanted to mount them
on separate pre-assigned mount points. If you want all of them to mount
on the same place, just use /dev/sda1!

-- Pete

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Pete :)

 * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > A global unique ID won't work out to make all USB mass storage devices
> > appear under a common mountpoint, especially if it is recreated while
> > "formating" it.
> That is correct, but not what Dervish wanted. He wanted to mount them
> on separate pre-assigned mount points. If you want all of them to mount
> on the same place, just use /dev/sda1!

    That's not possible. sd_mod will assign different devices for
different USB gadgets, and that's my problem in the first case!. If I
plug my USB-whatever, it gets assigned /dev/sda1 (for the first
partition, I mean). If I unplug it and, after that, I plug any other
USB device, it gets assigned /dev/sdb1, etc. Don't know if the
culprit is usb-storage or sd_mod :? The problem is that I cannot know
about which device was assigned (at least in 2.4.x) so I can modify
fstab or even mount it.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Willy Tarreau]

Hi Raul,

On Sun, Aug 14, 2005 at 09:32:57AM +0200, DervishD wrote:
>     Hi Pete :)
> 
>  * Pete Zaitcev <zaitcev@redhat.com> dixit:
> > > A global unique ID won't work out to make all USB mass storage devices
> > > appear under a common mountpoint, especially if it is recreated while
> > > "formating" it.
> > That is correct, but not what Dervish wanted. He wanted to mount them
> > on separate pre-assigned mount points. If you want all of them to mount
> > on the same place, just use /dev/sda1!
> 
>     That's not possible. sd_mod will assign different devices for
> different USB gadgets, and that's my problem in the first case!. If I
> plug my USB-whatever, it gets assigned /dev/sda1 (for the first
> partition, I mean). If I unplug it and, after that, I plug any other
> USB device, it gets assigned /dev/sdb1, etc. Don't know if the
> culprit is usb-storage or sd_mod :? The problem is that I cannot know
> about which device was assigned (at least in 2.4.x) so I can modify
> fstab or even mount it.

I've been suffering from the same problem for a long time until I found
a patch from Erik Andersen which automatically unregisters the sd device
once you unplug the USB device. It has changed my life :-)

Here it is for 2.4. I even wonder why we would not put this into mainline,
since having orphan devices brings nothing but confusion.

Regards,
Willy

----

This patch has been in use locally for quite some time now and
makes working with USB and 1394 mass-storage devices in 2.4.x a
much less painful experience.  When devices are plugged in, they
are automagically connected up to the scsi subsystem without the
need to rescan all scsi busses or echo things into
/proc/scsi/scsi.  When devices are unplugged, they are
automagically removed from the scsi subsystem, instead of hanging
around registered but with no media actually present.

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Signed-off-by: Erik Andersen <andersen@codepoet.org>

--- orig/drivers/usb/storage/usb.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/usb/storage/usb.c	Fri Sep 17 15:34:38 2004
@@ -744,6 +744,11 @@
 		/* unlock the device pointers */
 		up(&(ss->dev_semaphore));
 
+		/* Try to re-connect ourselves to the SCSI subsystem */
+		if (scsi_add_single_device(ss->host, 0, 0, 0))
+		    printk(KERN_WARNING "Unable to connect USB device to the SCSI subsystem\n");
+		else
+		    printk(KERN_WARNING "USB device connected to the SCSI subsystem\n");
 	} else { 
 		/* New device -- allocate memory and initialize */
 		US_DEBUGP("New GUID " GUID_FORMAT "\n", GUID_ARGS(guid));
@@ -1057,6 +1062,12 @@
 	/* lock access to the device data structure */
 	down(&(ss->dev_semaphore));
 
+	/* Try to un-hook ourselves from the SCSI subsystem */
+	if (scsi_remove_single_device(ss->host, 0, 0, 0))
+	    printk(KERN_WARNING "Unable to disconnect USB device from the SCSI subsystem\n");
+	else
+	    printk(KERN_WARNING "USB device disconnected from the SCSI subsystem\n");
+
 	/* release the IRQ, if we have one */
 	if (ss->irq_urb) {
 		US_DEBUGP("-- releasing irq URB\n");
--- orig/drivers/ieee1394/sbp2.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/ieee1394/sbp2.c	Fri Sep 17 15:34:38 2004
@@ -231,7 +231,7 @@
  * enable this define to make use of it. This provides better hotplug
  * support. The mentioned patch is not part of the kernel proper though,
  * because it is considered somewhat of a hack. */
-//#define SBP2_USE_SCSI_ADDREM_HACK
+#define SBP2_USE_SCSI_ADDREM_HACK
 
 
 /*
--- orig/drivers/scsi/scsi_syms.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/scsi_syms.c	Fri Sep 17 15:34:38 2004
@@ -104,3 +104,9 @@
 extern int scsi_delete_timer(Scsi_Cmnd *);
 EXPORT_SYMBOL(scsi_add_timer);
 EXPORT_SYMBOL(scsi_delete_timer);
+
+/* Support for hot plugging and unplugging devices -- safe for
+ * ieee1394 or USB devices, but probably not for normal SCSI... */
+EXPORT_SYMBOL(scsi_add_single_device);
+EXPORT_SYMBOL(scsi_remove_single_device);
+
--- orig/drivers/scsi/hosts.h	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/hosts.h	Fri Sep 17 15:34:38 2004
@@ -535,6 +535,13 @@
 int scsi_register_device(struct Scsi_Device_Template * sdpnt);
 void scsi_deregister_device(struct Scsi_Device_Template * tpnt);
 
+/* Support for hot plugging and unplugging devices -- safe for
+ * ieee1394 or USB devices, but probably not for normal SCSI... */
+extern int scsi_add_single_device(struct Scsi_Host *shpnt,
+	int channel, int id, int lun);
+extern int scsi_remove_single_device(struct Scsi_Host *shpnt,
+	int channel, int id, int lun);
+
 /* These are used by loadable modules */
 extern int scsi_register_module(int, void *);
 extern int scsi_unregister_module(int, void *);
--- orig/drivers/scsi/scsi.c	Fri Sep 17 15:34:38 2004
+++ linux-2.4.27/drivers/scsi/scsi.c	Fri Sep 17 15:34:38 2004
@@ -1554,6 +1554,156 @@
     }
 }
 
+
+static DECLARE_MUTEX(scsi_host_internals_lock);
+/*
+ * Function:    scsi_add_single_device()
+ *
+ * Purpose:     Support for hotplugging SCSI devices.  This function
+ *              implements the actual functionality for
+ *                  echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
+ *
+ * Arguments:   shpnt   - pointer to the SCSI host structure
+ *              channel - channel of the device to add
+ *              id      - id of the device to add
+ *              lun     - lun of the device to add
+ *
+ * Returns:     0 on success or an error code
+ *
+ * Lock status: None needed.
+ *
+ * Notes:       This feature is probably unsafe for standard SCSI devices,
+ *              but is perfectly normal for things like ieee1394 or USB
+ *              drives since these busses are designed for hotplugging.
+ *              Use at your own risk....
+ */
+int scsi_add_single_device(struct Scsi_Host *shpnt, int channel,
+	int id, int lun)
+{
+	Scsi_Device *scd;
+
+	/* Do a bit of sanity checking */
+	if (shpnt==NULL) {
+		return  -ENXIO;
+	}
+
+	/* We call functions that can sleep, so use a semaphore to
+	 * avoid racing with scsi_remove_single_device().  We probably
+	 * need to also apply this lock to scsi_register*(),
+	 * scsi_unregister*(), sd_open(), sd_release() and anything
+	 * else that might be messing with with the Scsi_Host or other
+	 * fundamental data structures.  */
+	down(&scsi_host_internals_lock);
+
+	/* Check if they asked us to add an already existing device.
+	 * If so, ignore their misguided efforts. */
+	for (scd = shpnt->host_queue; scd; scd = scd->next) {
+		if ((scd->channel == channel && scd->id == id && scd->lun == lun)) {
+			break;
+		}
+	}
+	if (scd) {
+		up(&scsi_host_internals_lock);
+		return -ENOSYS;
+	}
+
+	scan_scsis(shpnt, 1, channel, id, lun);
+	up(&scsi_host_internals_lock);
+	return 0;
+}
+
+/*
+ * Function:    scsi_remove_single_device()
+ *
+ * Purpose:     Support for hot-unplugging SCSI devices.  This function
+ *              implements the actual functionality for
+ *                  echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
+ *
+ * Arguments:   shpnt   - pointer to the SCSI host structure
+ *              channel - channel of the device to add
+ *              id      - id of the device to add
+ *              lun     - lun of the device to add
+ *
+ * Returns:     0 on success or an error code
+ *
+ * Lock status: None needed.
+ *
+ * Notes:       This feature is probably unsafe for standard SCSI devices,
+ *              but is perfectly normal for things like ieee1394 or USB
+ *              drives since these busses are designed for hotplugging.
+ *              Use at your own risk....
+ */
+int scsi_remove_single_device(struct Scsi_Host *shpnt, int channel,
+	int id, int lun)
+{
+	Scsi_Device *scd;
+	struct Scsi_Device_Template *SDTpnt;
+
+	/* Do a bit of sanity checking */
+	if (shpnt==NULL) {
+		return  -ENODEV;
+	}
+
+	/* We call functions that can sleep, so use a semaphore to
+	 * avoid racing with scsi_add_single_device().  We probably
+	 * need to also apply this lock to scsi_register*(),
+	 * scsi_unregister*(), sd_open(), sd_release() and anything
+	 * else that might be messing with with the Scsi_Host or other
+	 * fundamental data structures.  */
+	down(&scsi_host_internals_lock);
+
+	/* Make sure the specified device is in fact present */
+	for (scd = shpnt->host_queue; scd; scd = scd->next) {
+		if ((scd->channel == channel && scd->id == id && scd->lun == lun)) {
+			break;
+		}
+	}
+	if (scd==NULL) {
+		up(&scsi_host_internals_lock);
+		return -ENODEV;
+	}
+
+	/* See if the specified device is busy.  Doesn't this race with
+	 * sd_open(), sd_release() and similar?  Why don't they lock
+	 * things when they increment/decrement the access_count? */
+	if (scd->access_count) {
+		up(&scsi_host_internals_lock);
+		return -EBUSY;
+	}
+
+	SDTpnt = scsi_devicelist;
+	while (SDTpnt != NULL) {
+		if (SDTpnt->detach)
+			(*SDTpnt->detach) (scd);
+		SDTpnt = SDTpnt->next;
+	}
+
+	if (scd->attached == 0) {
+		/* Nobody is using this device, so we
+		 * can now free all command structures.  */
+		if (shpnt->hostt->revoke)
+			shpnt->hostt->revoke(scd);
+		devfs_unregister (scd->de);
+		scsi_release_commandblocks(scd);
+
+		/* Now we can remove the device structure */
+		if (scd->next != NULL)
+			scd->next->prev = scd->prev;
+
+		if (scd->prev != NULL)
+			scd->prev->next = scd->next;
+
+		if (shpnt->host_queue == scd) {
+			shpnt->host_queue = scd->next;
+		}
+		blk_cleanup_queue(&scd->request_queue);
+		kfree((char *) scd);
+	}
+
+	up(&scsi_host_internals_lock);
+	return 0;
+}
+
 #ifdef CONFIG_PROC_FS
 static int scsi_proc_info(char *buffer, char **start, off_t offset, int length)
 {
@@ -1606,8 +1756,6 @@
 static int proc_scsi_gen_write(struct file * file, const char * buf,
                               unsigned long length, void *data)
 {
-	struct Scsi_Device_Template *SDTpnt;
-	Scsi_Device *scd;
 	struct Scsi_Host *HBA_ptr;
 	char *p;
 	int host, channel, id, lun;
@@ -1722,13 +1870,12 @@
 	/*
 	 * Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
 	 * with  "0 1 2 3" replaced by your "Host Channel Id Lun".
-	 * Consider this feature BETA.
+	 *
+	 * Consider this feature pre-BETA.
+	 *
 	 *     CAUTION: This is not for hotplugging your peripherals. As
 	 *     SCSI was not designed for this you could damage your
-	 *     hardware !
-	 * However perhaps it is legal to switch on an
-	 * already connected device. It is perhaps not
-	 * guaranteed this device doesn't corrupt an ongoing data transfer.
+	 *     hardware and thoroughly confuse the SCSI subsystem.
 	 */
 	if (!strncmp("add-single-device", buffer + 5, 17)) {
 		p = buffer + 23;
@@ -1746,33 +1893,11 @@
 				break;
 			}
 		}
-		err = -ENXIO;
-		if (!HBA_ptr)
-			goto out;
-
-		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
-			if ((scd->channel == channel
-			     && scd->id == id
-			     && scd->lun == lun)) {
-				break;
-			}
-		}
-
-		err = -ENOSYS;
-		if (scd)
-			goto out;	/* We do not yet support unplugging */
-
-		scan_scsis(HBA_ptr, 1, channel, id, lun);
-
-		/* FIXME (DB) This assumes that the queue_depth routines can be used
-		   in this context as well, while they were all designed to be
-		   called only once after the detect routine. (DB) */
-		/* queue_depth routine moved to inside scan_scsis(,1,,,) so
-		   it is called before build_commandblocks() */
-
-		err = length;
+		if ((err=scsi_add_single_device(HBA_ptr, channel, id, lun))==0)
+		    err = length;
 		goto out;
 	}
+
 	/*
 	 * Usage: echo "scsi remove-single-device 0 1 2 3" >/proc/scsi/scsi
 	 * with  "0 1 2 3" replaced by your "Host Channel Id Lun".
@@ -1782,7 +1907,6 @@
 	 *     CAUTION: This is not for hotplugging your peripherals. As
 	 *     SCSI was not designed for this you could damage your
 	 *     hardware and thoroughly confuse the SCSI subsystem.
-	 *
 	 */
 	else if (!strncmp("remove-single-device", buffer + 5, 20)) {
 		p = buffer + 26;
@@ -1798,58 +1922,8 @@
 				break;
 			}
 		}
-		err = -ENODEV;
-		if (!HBA_ptr)
-			goto out;
-
-		for (scd = HBA_ptr->host_queue; scd; scd = scd->next) {
-			if ((scd->channel == channel
-			     && scd->id == id
-			     && scd->lun == lun)) {
-				break;
-			}
-		}
-
-		if (scd == NULL)
-			goto out;	/* there is no such device attached */
-
-		err = -EBUSY;
-		if (scd->access_count)
-			goto out;
-
-		SDTpnt = scsi_devicelist;
-		while (SDTpnt != NULL) {
-			if (SDTpnt->detach)
-				(*SDTpnt->detach) (scd);
-			SDTpnt = SDTpnt->next;
-		}
-
-		if (scd->attached == 0) {
-			/*
-			 * Nobody is using this device any more.
-			 * Free all of the command structures.
-			 */
-                        if (HBA_ptr->hostt->revoke)
-                                HBA_ptr->hostt->revoke(scd);
-			devfs_unregister (scd->de);
-			scsi_release_commandblocks(scd);
-
-			/* Now we can remove the device structure */
-			if (scd->next != NULL)
-				scd->next->prev = scd->prev;
-
-			if (scd->prev != NULL)
-				scd->prev->next = scd->next;
-
-			if (HBA_ptr->host_queue == scd) {
-				HBA_ptr->host_queue = scd->next;
-			}
-			blk_cleanup_queue(&scd->request_queue);
-			kfree((char *) scd);
-		} else {
-			goto out;
-		}
-		err = 0;
+		err=scsi_remove_single_device(HBA_ptr, channel, id, lun);
+		goto out;
 	}
 out:
 	
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


> 
>     Raúl Núñez de Arenas Coronado
> 
> -- 
> Linux Registered User 88736 | http://www.dervishd.net
> http://www.pleyades.net & http://www.gotesdelluna.net
> It's my PC and I'll cry if I want to...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Willy :)

 * Willy Tarreau <willy@w.ods.org> dixit:
> >     That's not possible. sd_mod will assign different devices for
> > different USB gadgets, and that's my problem in the first case!. If I
> > plug my USB-whatever, it gets assigned /dev/sda1 (for the first
> > partition, I mean). If I unplug it and, after that, I plug any other
> > USB device, it gets assigned /dev/sdb1, etc. Don't know if the
> > culprit is usb-storage or sd_mod :? The problem is that I cannot know
> > about which device was assigned (at least in 2.4.x) so I can modify
> > fstab or even mount it.
> I've been suffering from the same problem for a long time until I found
> a patch from Erik Andersen which automatically unregisters the sd device
> once you unplug the USB device. It has changed my life :-)

    Thanks! Unfortunately, it solves only half of my problem. If I
plug *two* USB storage devices, the second will fail (well, it won't
be assigned the correct device). The perfect solution is to always
use the same dev entry for the same USB device, but I need sysfs for
that (AFAIK), just like udev does.
 
> Here it is for 2.4. I even wonder why we would not put this into mainline,
> since having orphan devices brings nothing but confusion.

    Don't know :????

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Problem with usb-storage and /dev/sd?

[DervishD]

    Hi all :)

    If I plug my MP3 player (USB), the usb-storage module assigns it
device /dev/sda, which is right because I have it configured as such
in my /etc/fstab. Well, another day, another boot and I plug my USB
memory stick, and usb-storage assigns it device /dev/sda, quite cool
because I have it configured as such in my /etc/fstab, too.

    The problem is that if I plug my USB memory, unplug it and plug
my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
even greater if I plug my card reader, which has four LUN's...

    I'm not using hotplug currently so... how can I make the USB
subsystem to assign always the same /dev/sd? entry to my USB Mass
storage devices? For example, I will assign /dev/sda to my MP3
player, no matter if it is the first or the last USB gadget plugged,
etc. I would like fixed assignations, not the current way of 'first
item plugged gets /dev/sda and you have to remove the module if you
want the next item to be placed in /dev/sda'. I've googled a bit
without any success :(

    Thanks a lot in advance :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Tomasz Torcz]

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

On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
>     If I plug my MP3 player (USB), the usb-storage module assigns it
> device /dev/sda, which is right because I have it configured as such
> in my /etc/fstab. Well, another day, another boot and I plug my USB
> memory stick, and usb-storage assigns it device /dev/sda, quite cool
> because I have it configured as such in my /etc/fstab, too.
> 
>     The problem is that if I plug my USB memory, unplug it and plug
> my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> even greater if I plug my card reader, which has four LUN's...

 That's what udev is for. Example rule to give my memory stick
persistent name:

BUS="usb", SYSFS_serial="5B4B06010122", NAME="pendriveZDZ%n", GROUP="floppy", MODE="0662", RUN+= "/sbin/udev_run_hotplugd"

 Go figure how to udev-enable your distribution.

-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
zdzichu@irc.-nie.spam-.pl    wagon filled with backup tapes." -- Jim Gray


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

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Tomasz :)

 * Tomasz Torcz <zdzichu@irc.pl> dixit:
> On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
> >     The problem is that if I plug my USB memory, unplug it and plug
> > my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> > even greater if I plug my card reader, which has four LUN's...
>  That's what udev is for.

    I know, but I use a 2.4.x kernel (which I didn't mention in my
original message, sorry O:)), and udev needs a 2.6.x kernel, am I
wrong?

>  Go figure how to udev-enable your distribution.

    I have a do-it-yourself Linux box, so setting up udev is not much
of a problem as long as the kernel supports it. If udev doesn't use
any kernel magic (that is, it only uses /sbin/hotplug), how the heck
does it know which /dev/sd? the *kernel* assigned to my recently
plugged USB device? How can it influenciate which device is assigned
*by the kernel*? I assume that it needs some magic from the kernel
and so it only works for 2.6.x :???? In fact, if it uses sysfs, it
still needs a 2.6.x for that, am I wrong?

    I'll take a look anyway, thanks a lot for your message and help :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: Problem with usb-storage and /dev/sd?

[Greg KH]

On Thu, Aug 11, 2005 at 12:06:16AM +0200, DervishD wrote:
>     Hi Tomasz :)
> 
>  * Tomasz Torcz <zdzichu@irc.pl> dixit:
> > On Wed, Aug 10, 2005 at 09:22:43PM +0200, DervishD wrote:
> > >     The problem is that if I plug my USB memory, unplug it and plug
> > > my MP3 player, it gets /dev/sdb this time, not /dev/sda. The mess is
> > > even greater if I plug my card reader, which has four LUN's...
> >  That's what udev is for.
> 
>     I know, but I use a 2.4.x kernel (which I didn't mention in my
> original message, sorry O:)), and udev needs a 2.6.x kernel, am I
> wrong?

That is correct, udev needs 2.6.  So, with 2.4 you are on your own here,
sorry.

thanks,

greg k-h

Re: Problem with usb-storage and /dev/sd?

[DervishD]

    Hi Greg :)

 * Greg KH <greg@kroah.com> dixit:
> On Thu, Aug 11, 2005 at 12:06:16AM +0200, DervishD wrote:
> >  * Tomasz Torcz <zdzichu@irc.pl> dixit:
> > >  That's what udev is for.
> >     I know, but I use a 2.4.x kernel (which I didn't mention in my
> > original message, sorry O:)), and udev needs a 2.6.x kernel, am I
> > wrong?
> That is correct, udev needs 2.6.  So, with 2.4 you are on your own here,
> sorry.

    Any way of forcing usb-storage to assign a particular device to a
recently plugged USB gadget? Wait a minute: hotplug events *include*
the name of the assigned device, am I wrong? Then I can deal with the
issue...

    I'll post my solution to the list, if any ;)

    Thanks :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

fdisk: What do plus signs after "Blocks" mean?

[Konstantin Kudin]

 Hi there,

 Fdisk on my machine displays the output shown below. Many partitions
have pluses after "Blocks". The issue is that during installation on
the existing linux setup WinXP screwed up the partition table, and
these pluses were very difficult to recreate. Basically, if I remove
hda9, and then try to recreate it in fdisk, it loses the plus sign and
does not look as before. Also, sometimes fdisk creates a partition with
"+", and sometimes it does not.

 Since I did not want to take any chances, I used Knoppix to read a
similar partition table from /dev/hdb using "sfdisk -dx", and then
copied it to /dev/hda by using "sfdisk -fx". If I do not force sfdisk
by using "-f", it complains that there are some inconsistencies.

 Can anyone enlighten me what the pluses mean? Also, if a partition
loses pluses after "Blocks", would that destroy a RAID array?

 Thanks!
 Konstantin



#################
fdisk -l /dev/hda

Disk /dev/hda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1           3       24066    7  HPFS/NTFS
/dev/hda2               4       19457   156264255    5  Extended
/dev/hda5               4         264     2096451   82  Linux swap
/dev/hda6             265        2176    15358108+  fd  Linux raid
autodetect
/dev/hda7            2177        4088    15358108+   7  HPFS/NTFS
/dev/hda8            4089        7912    30716248+  fd  Linux raid
autodetect
/dev/hda9            7913       19457    92735212+  fd  Linux raid
autodetect



		
____________________________________________________
Sell on Yahoo! Auctions – no fees. Bid on great items.  
http://auctions.yahoo.com/

Re: fdisk: What do plus signs after "Blocks" mean?

[DervishD]

    Hi Konstantin :)

 * Konstantin Kudin <konstantin_kudin@yahoo.com> dixit:
>  Can anyone enlighten me what the pluses mean?

    It is commented in the README.fdisk file in util-linux
distribution: the '+' flag means that the partition has an odd number
of sectors. That means that you can waste a sector at the end of the
partition, and it's very common for the first partition in the disk
if it ends on a cylinder boundary and cylinders have an even number
of sectors, due to the MBR.

    Harmless.

> Also, if a partition loses pluses after "Blocks", would that
> destroy a RAID array?

    I don't have any idea :? To reproduce a '+' in a partition, you
probably have to specify partition size in sectors (or kilobytes,
whatever fits you better) and make it odd, honoring exactly the
number of sectors that partition had (before the parttable was
destroyed by our dear friend XP).

    It's a good idea to have a copy of the partition table around, if
it is not simple (the one you had is NOT simple).

    Hope that helps.

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: fdisk: What do plus signs after "Blocks" mean?

[Horst von Brand]

DervishD <lkml@dervishd.net> wrote:

[...]

>     It's a good idea to have a copy of the partition table around, if
> it is not simple (the one you had is NOT simple).

Be careful. What you'll get out of backing up the partition table is /only/
the primary partitions, the others are handled by a weird russian doll of
partitions-inside-partitions. AFAIR, the details were in the LILO docu.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: fdisk: What do plus signs after "Blocks" mean?

[Konstantin Kudin]

--- Horst von Brand <vonbrand@inf.utfsm.cl> wrote:

 Guys, thanks a lot for the explanations!

 Actually, it seems like one can backup information on ALL partitions
by using the command "sfdisk -dx /dev/hdX". Supposedly, it reads not
only primary but also extended partitions. "sfdisk -x /dev/hdX" should
be then able to write whatever is known back to the disk.

 Konstantin



> DervishD <lkml@dervishd.net> wrote:
> 
> [...]
> 
> >     It's a good idea to have a copy of the partition table around,
> if
> > it is not simple (the one you had is NOT simple).
> 
> Be careful. What you'll get out of backing up the partition table is
> /only/
> the primary partitions, the others are handled by a weird russian
> doll of
> partitions-inside-partitions. AFAIR, the details were in the LILO
> docu.
> -- 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: fdisk: What do plus signs after "Blocks" mean?

[Jan Engelhardt]

> Guys, thanks a lot for the explanations!
>
> Actually, it seems like one can backup information on ALL partitions
>by using the command "sfdisk -dx /dev/hdX". Supposedly, it reads not
>only primary but also extended partitions. "sfdisk -x /dev/hdX" should
>be then able to write whatever is known back to the disk.

MBR size is 448 bytes, the rest is "the partition table", with space for four 
entries. If one wants more, then s/he creates a [primary] partition, tagging 
it "extended", and the "extended partiton table" is within that primary 
partition. So yes, by dd'ing /dev/hdX, you get everything. Including "lost 
sectors" if you dd it back to a bigger HD.

Re: fdisk: What do plus signs after "Blocks" mean?

[kernel]

I always thought;

First 446 bytes are boot code and all
Next 64 bytes are for 4 partition records, 16 bytes each
Last 2 bytes are signature 

?

-fd


On Wed, 2005-07-13 at 06:24, Jan Engelhardt wrote:
> > Guys, thanks a lot for the explanations!
> >
> > Actually, it seems like one can backup information on ALL partitions
> >by using the command "sfdisk -dx /dev/hdX". Supposedly, it reads not
> >only primary but also extended partitions. "sfdisk -x /dev/hdX" should
> >be then able to write whatever is known back to the disk.
> 
> MBR size is 448 bytes, the rest is "the partition table", with space for four 
> entries. If one wants more, then s/he creates a [primary] partition, tagging 
> it "extended", and the "extended partiton table" is within that primary 
> partition. So yes, by dd'ing /dev/hdX, you get everything. Including "lost 
> sectors" if you dd it back to a bigger HD.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: fdisk: What do plus signs after "Blocks" mean?

[DervishD]

   Hi kernel.

 * kernel <kernel@crazytrain.com> dixit:
> First 446 bytes are boot code and all
> Next 64 bytes are for 4 partition records, 16 bytes each
> Last 2 bytes are signature 

    And that's right, but only for the MBR. If you set up an extended
partition in the MBR, the partition table for that extended partition
is on the boot record of the extended partition. If you just backup
the MBR, you only backup the *declaration* of the extended partition
(where it starts, where it ends, etc.) but NOT the partition table of
the extended partition (that is, the partitions within the extended
partition). For storing that you have to backup the first sector of
the extended partition itself. And you have to do it recursively if
you want to backup any partition setup, no matter how strange.

    I hope I've made this clear, is a bit difficult to explain
without a couple of diagrams O:)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: fdisk: What do plus signs after "Blocks" mean?

[Jan Engelhardt]

>I always thought;
>
>First 446 bytes are boot code and all

Right, of course. Otherwise it won't sum up to 512 bytes.



Jan Engelhardt
-- 

Re: fdisk: What do plus signs after "Blocks" mean?

[DervishD]

    Hi Konstantin :)

 * Konstantin Kudin <konstantin_kudin@yahoo.com> dixit:
>  Actually, it seems like one can backup information on ALL partitions
> by using the command "sfdisk -dx /dev/hdX". Supposedly, it reads not
> only primary but also extended partitions. "sfdisk -x /dev/hdX" should
> be then able to write whatever is known back to the disk.

    Cool! A long time has passed since I used sfdisk, but I used it
for manually re-reading partition tables and the like :)

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...

Re: fdisk: What do plus signs after "Blocks" mean?

[DervishD]

    Hi Horst :)

 * Horst von Brand <vonbrand@inf.utfsm.cl> dixit:
> DervishD <lkml@dervishd.net> wrote:
> >     It's a good idea to have a copy of the partition table around, if
> > it is not simple (the one you had is NOT simple).
> Be careful. What you'll get out of backing up the partition table is /only/
> the primary partitions, the others are handled by a weird russian doll of
> partitions-inside-partitions. AFAIR, the details were in the LILO docu.

    Note that I didn't suggest to backup or have a copy of the MBR,
but of the partition table, the FULL partition table (that includes
the secondary partitions and the like. Once a disk is fully
partitioned, a couple of 'dd' commands do the trick even for
extended partitions.

    It's a mess, anyway :( 

    Raúl Núñez de Arenas Coronado

-- 
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...