I have been bitten by the same bug.
In my case the disk drive started life with the installation of Fedora
(although the the computer supplier had used some version of Windows on
the disk for testing, which was removed before the computer was supplied
to me). I had no problems using the disk with Fedora for several years.
Kubuntu looked interesting, so I decided to try it by installing it on a
second drive which I added to the computer.
Kubuntu installed and I have been using it (e.g. now) and working around
the inevitable bugs and inconsistencies...
A particularly annoying bug is the fact that udev fails to see my
original Fedora partition. This means that I can't use the LABEL or
UUID methods for that partition in fstab (udev deletes the entries in
/dev/disk and creates new ones each time it is restarted. "mount"
appears to use these entries). Ubuntu uses the new-fangled "upstart"
init scheme (which is annoying on two counts: how it works on Ubuntu
doesn't appear to be well documented, and it seems to be mostly set up
to emulate Sysv init anyway!). Having worked my way through this maze
(init and udev), I found that script /etc/udev/rules.d/65-persistent-
storage.rules appears to be one of the main culprits.
The udev script uses the "vol_id" program to fetch the information about the
LABEL and UUID of each disk device. (remark: the man page for vol_id omits
several of the options which vol_id accepts, including --help and --probe-all)
`vol_id --probe-all` reveals that it identifies two partition signatures on my
old Fedora partition: a vfat one and an ext3 one. For some reason (I haven't
yet been able to find an explanation in my googling) it is possible to have
both at the same time. The vfat signature is, it appears, always in the first
512 bytes. The ext3 ones start at byte 1024. Thus is would appear that it is
possible to have the two valid signatures at the same time by either of the
following: format a partition as a vfat drive first and then format it as ext3,
or (possibly) format it as vfat and then use it and then by chance have the
Windows FAT contain a valid ext3 signature (I don't know whether this is
possible but it almost certainly has a very low probability). A key question
here is: why didn't the program I used to format the partition as ext3 write
nulls over the first 512 bytes?
The solution for me was, as I found on the web, to do "dd if=/dev/zero
of=/dev/XXX bs=512 count=1" and hope I didn't mistype it.
However, this took quite a lot of time to track down and I know from my
web searching that the bug has troubled a number of people. It
certainly didn't make Ubuntu look very "user friendly". I believe that
the bug should be squashed (or beaten into submission) and that the
importance should be above "low".
Some ways to make the process work better:
1. It would appear to be fairly easy to detect the multiple signatures
("vol_id --probe-all") before udev sets up the /dev/disk entries for a
partition and then, if the relevant partition table entry id is not for an MS
file system, to offer to wipe the first 512 bytes for the user (with
appropriate warnings).
2. Do the same checks during the installation process for Ubuntu.
3. Do the same checks in programs such as the KDE "Disk & Filesystem
Configuration Tool"
4. An interesting alternative would be to modify the behaviour of "vol_id" to
always check for multiple signatures and then, if vfat and ext3 (or similar)
are found, to default to returning the information from the second signature
instead of the first (which it does now). This would appear to have a finite,
but low, probability of failure but this probability could be lowered by
comparing the relevant areas of the two copies of the MS FAT.
--
vol_id: detects vfat instead of ext3 UUID
https://bugs.launchpad.net/bugs/118292
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
