On Mon, 21 Dec 2009, Rogério Brito wrote:
> Hi, Christian.
Rogério,
> Great. I wonder if ID_MODEL is guaranteed to contain no spaces in the
> name.
Looks like that. Needs to be confirmed.
> That would also make things more comfortable.
Yes, it would.
> I guess that the only thing that we could count on (and I'm not even
> sure if we could really count on that) is the serial number.
Yes, I came to the same conclusion.
> > 3. the next thing is the mounted device is (for example) /dev/sdc instead
> > of the expected /dev/sdc1:
> >
> > $ cat /proc/mounts
> > /dev/sdc /media/usb0 vfat
> > rw,nodev,noexec,noatime,nodiratime,gid=25,fmask=0117,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=utf8,errors=remount-ro
> > 0 0
> (...)
>
> I had not seen this before.
Neither did I. Still, that's the way it seems to be. fdisk reports:
Disk /dev/sdc: 2 GB, 2015193600 bytes
255 heads, 63 sectors/track, 245 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 1 246 1975963 83 Linux
Warning: Partition 1 does not end on cylinder boundary.
sfdisk:
Disk /dev/sdc: 1010 cylinders, 63 heads, 62 sectors/track
Units = cylinders of 1999872 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End #cyls #blocks Id System
/dev/sdc1 ? 199215+ 491460- 292246- 570754815+ 72 Unknown
start: (c,h,s) expected (1023,62,62) found (357,116,40)
end: (c,h,s) expected (1023,62,62) found (357,32,45)
/dev/sdc2 ? 43187+ 538842- 495655- 968014120 65 Novell Netware 386
start: (c,h,s) expected (1023,62,62) found (288,115,43)
end: (c,h,s) expected (1023,62,62) found (367,114,50)
/dev/sdc3 ? 478720+ 974375- 495655- 968014096 79 Unknown
start: (c,h,s) expected (1023,62,62) found (366,32,33)
end: (c,h,s) expected (1023,62,62) found (357,32,43)
/dev/sdc4 ? 0 931189- 931190- 1818613248 d Unknown
start: (c,h,s) expected (0,0,1) found (372,97,50)
end: (c,h,s) expected (1023,62,62) found (0,10,0)
gdisk:
GPT fdisk (gdisk) version 0.5.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format.
THIS OPERATON IS POTENTIALLY DESTRUCTIVE! Exit by typing 'q' if
you don't want to convert your MBR partitions to GPT format!
***************************************************************
Exact type match not found for type code 7200; assigning type code for
'Linux/Windows data'
Exact type match not found for type code 6500; assigning type code for
'Linux/Windows data'
Exact type match not found for type code 7900; assigning type code for
'Linux/Windows data'
Exact type match not found for type code 0D00; assigning type code for
'Linux/Windows data'
Warning! Secondary partition table overlaps the last partition by
3801962674 blocks
You will need to delete this partition or resize it in another utility.
Disk /dev/sdc: 3947016 sectors, 1.9 GiB
Disk identifier (GUID): 59F43890-2F6F-2938-FB0E-2279B180142B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 3946982
Total free space is 0 sectors (0 bytes)
Number Start (sector) End (sector) Size Code Name
1 778135908 1919645538 544.3 GiB 0700 Linux/Windows data
2 168689522 2104717761 923.2 GiB 0700 Linux/Windows data
3 1869881465 3805909656 923.2 GiB 0700 Linux/Windows data
> I do have one stick that is mounted as /dev/sdc, but it doesn't have a
> partition table.
Right. This is, IMO, cdrom behaviour. Not ok. Log an error and exit.
What do you think?
> > * fsck reports:
> >
> > # fsck.vfat /dev/sdd
> > dosfsck 3.0.6, 04 Oct 2009, FAT32, LFN
> > /dev/sdd: 1 files, 2606/61664 clusters
> >
> > now, this could be a problem with udev, the kernel, or elsewhere.
>
> (Just for the record, you meant /dev/sdc here, right?
Yes. Typo.
> In the other places, you used /dev/sdc and here you used /dev/sdd---just
> trying to check if you're not seeing different devices).
I own 2 identical sticks. They show up as /dev/sdc and /dev/sdd.
> That being said, I don't know about the ramification of these problems.
> Do you have any "real" problems with that? I mean, like data written on
> the wrong place?
Didn't get that far. Do you know _how_ to create such a beast, in the
first place?
> > 4. the created symlinks under /var/run/usbmount for the two sticks are
> > identical (/var/run/usbmount/Ut165_USB_Flash_Disk), at least with my
> > modified scripts, and that leeds to confusion
> >
> > I guess the easiest way to reproduce this is to 'dd' one stick to the
> > other, but I didn't test that.
> >
> > May be so that using ID_SERIAL_SHORT would be a partial workaround, but I
> > didn't try that either, yet.
>
> Yes, that could be a solution. I don't really use the /var/run/ symlinks
> myself,
I do. And I dare saying, doing that is one of the main points with
usbmount.
> but updating them is prone to introducing all sorts of race
> conditions.
Right.
> Anyway, I'm thinking of releasing the new version of usbmount as-is from
> the SVN repository, since it contains a versioned dependency on udev
> that is necessary so that we don't break things (IOW, this must be
> pushed as soon as possible).
Just go ahead. Still, it should be followed by one or more bugfix
releases.
> If you have any small patch, please let me know.
Other patches can wait.
> I'm a little bit short on time and, if you would like, you could be a
> co-maintainer of the package.
As I already said, I'd be glad to.
Cheers,
--
Cristian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
