Installer should not list removable media in /etc/fstab

I'm the submitter of duplicate bug #175165. I would respectfully like to nominate alternative (b) as the preferred fix, and put that in the title of this bug. If there are objections, please raise them here. Thanks.

Retitled with stronger wording, as per above

I just got bitten with this bug. I had an SD card in the internal card reader and fstab came up with the following entry after install:
# /dev/mmcblk0p1
UUID=6565-3236 /media/mmcblk0p1 vfat defaults,utf8,umask=007,gid=46 0 1

just too note, this is still true in hardy (see dupe Bug #218198). i am not sure what the importance should be. is USB install considered a highly experimental unsupported feature?

"Although this is easily fixed by a sudoer familiar with /etc/fstab,"

Could someone please give a brief instruction on that? I have not found it on the net.

Thanks

The problem is down to a bad entry in the master filesystem table

or

/etc/fstab

Go to a terminal and type

sudo gedit /etc/fstab

Find the line that refers to your thumbdrive ; it will be /dev/sdXN (where X is a letter and N is a number), where the filesystem has been set to one of the CDROM filesystems (cdfs, isofs, etc). It won't be one of the lines that has a big UUID in it. On a fresh install, it's usually the last line.

Delete this line, save, reboot (may be unnecessary). You should now be able to connect your thumbdrive and have it show up on the desktop.

Note ; be very careful about what you edit in /etc/fstab as it can render your machine unbootable.

This is still a bug in Hardy (8.04 final, x86).

When inserting a USB stick, you get the error:
"Cannot mount volume. Invalid mount option when attempting to mount the volume."

Just like you did in 7.10. Please fix it.

Confirming this bug:

This line got created during installation using a USBStick:

/dev/sdb1 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

When inserting a USBStick, it fails because of this dmesg:

  370.372792] scsi 8:0:0:0: Direct-Access USB Flash Memory 1.00 PQ: 0 ANSI: 2
[ 370.395982] sd 8:0:0:0: [sdb] 3953664 512-byte hardware sectors (2024 MB)
[ 370.396605] sd 8:0:0:0: [sdb] Write Protect is off
[ 370.396608] sd 8:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[ 370.396611] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[ 370.399222] sd 8:0:0:0: [sdb] 3953664 512-byte hardware sectors (2024 MB)
[ 370.399850] sd 8:0:0:0: [sdb] Write Protect is off
[ 370.399853] sd 8:0:0:0: [sdb] Mode Sense: 0b 00 00 08
[ 370.399855] sd 8:0:0:0: [sdb] Assuming drive cache: write through
[ 370.399859] sdb: sdb1
[ 370.456276] sd 8:0:0:0: [sdb] Attached SCSI removable disk
[ 370.456334] sd 8:0:0:0: Attached scsi generic sg1 type 0
[ 372.229924] UDF-fs: No VRS found
[ 372.274508] ISOFS: Unable to identify CD-ROM format.

Reason why I installed using a USBStick is because my Lenovo X61s doesn't come with a CDRom drive.

I consider installing using USBStick to be a normal use-case: increasingly are travel laptops not shipping with CDRom-drives.

This bug is still present in Intrepid. Installing a Netbook becoming more and more common, doing it from a USB stick being even simpler with usb-creator, I am raising the importance of this bug.

We can't do anything much about this until apt-cdrom can discover the CD drive dynamically. Until that, taking removable media out of /etc/fstab would break other things.

(I'm not excluding the possibility of minor hacks just for USB installs, and Evan is aware of this, but we can't fix it in a sweeping fashion.)

Just so I understand, it sounds to me like when I install Ubuntu from a USB cdrom drive it will add an entry to /etc/fstab for that removable drive. However, once you remove that drive from the system (as you may have only wanted to use it for the install) the drive is now invalid. Can you explain further why apt-cdrom needs an invalid entry in /etc/ftab?

Can the installer check the value of /sys/block/sr*/removable and not add the drive to /etc/fstab if the value is "1"? What is the effect on apt-cdrom? I suppose we need to file a bug against apt-cdrom to support installation from installation media that are not necessarily a CD-ROM (such as a USB key) or prompt the user to insert media, detect the insertion of a device and check that device for the installation media.

Ok, I'm sure that is not easy, but I'm just trying to give alternatives.

Proposed patch. This seems a little too obvious a change, so I suspect I am missing something.

Forgot to account for UDF.

No code in usb-creator touches /etc/fstab. It simply writes the contents of the installation medium to a disk. Marking as invalid for that task.

I think this will cause problems during pkgsel (or for certain kinds of ubiquity installs), because apt-cdrom won't be able to make use of packages on the CD.

Instead, in the USB install case I think we need to remove /cdrom from /etc/fstab at the end of the installation, in a finish-install script (for d-i) and in custom scripts/install.py code (for ubiquity).

Pete, my point was not that apt-cdrom needed an invalid entry after installation (clearly this is no use to it), but that it needs /cdrom to be valid *during* installation.

Evan, your partman patch seems wrong to me. The "cut" part leaves only the device name through, so it's too late to grep for fs type afterwards. You might want to do something like this (not tested):

CDDEV=$(grep " /cdrom \(iso9660\|udf\) " /proc/mounts | cut -d ' ' -f 1 | grep -v "^/dev/loop")

This bug was fixed in the package ubiquity - 1.10.7

---------------
ubiquity (1.10.7) intrepid; urgency=low

  [ Jonathan Riddell ]
  * Use Oxygen style in KDE UI

  [ Andreas Wenning ]
  * Edit ubiquity/frontend/kde_ui.py to correctly open the url for
    release notes.

  [ Evan Dandrea ]
  * Pack the table containing the partition bars in a scrolled window
    (LP: #272318).
  * Remove broken CD-ROM entries from fstab after install (LP: #150872).
  * Automatic update of included source packages: apt-setup
    1:0.37ubuntu6, base-installer 1.86ubuntu7, kboot-installer
    0.0.1ubuntu7, user-setup 1.20ubuntu10.

  [ Mario Limonciello ]
  * Add above broken CD-ROM entries to mythbuntu frontend too.
  * Properly pre-setup database on mythbuntu frontend. (LP: #276904)
  * Simplify the xorg.conf that is written out in apply-drivers. (LP: #181564)
    The ideal situation is to enable these via Jockey, but Jockey doesn't
    have a good interface for turning on during installation and turning
    on and off tv-out.

  [ Colin Watson ]
  * Fix excessive file-copy blacklisting, which had several problems
    (LP: #285238):
    - wasn't deciding which language packs to use before generating the
      blacklist;
    - was filtering out packages with prerms before doing ok-to-remove
      calculations;
    - needed to try recursively removing broken packages in order to get a
      fully-expanded list of reverse-dependencies out of apt;
    - was removing packages from the difference list too early so they
      stopped being considered as packages that were allowed to be removed.
    In an attempt to make this rather large change a little more reviewable,
    note that the code used to analyse removals while generating the
    blacklist is now the same as that used to remove unused packages later
    in the installation process.

 -- Evan Dandrea <email address hidden> Mon, 20 Oct 2008 04:19:30 -0400

This bug was fixed in the package partman-target - 55ubuntu5

---------------
partman-target (55ubuntu5) intrepid; urgency=low

  * Remove the cdrom mounpoint if the filesystem is not iso9660 or udf
    (LP: #150872).

 -- Evan Dandrea <email address hidden> Mon, 20 Oct 2008 11:38:26 -0400

This bug is now showing up in Karmic-Alpha5+.

I've installed the 2009-08-27 daily snapshot + updates (including 2.6.31-8-generic) and this problem persists.

Per the above, simply removing outdated lines from /etc/fstab fixes this problem.

And this will be an amazingly frustrating experience for a non-sudoer user.

It took me hours to pour through bug reports to figure this out.

See https://bugzilla.gnome.org/show_bug.cgi?id=599448 for an explanation about how this leads to a problem with USB sticks from the Sandisk Cruzer series.

The problem persists with the Karmic RC installer.

On Sat, Oct 24, 2009 at 10:03:17AM -0000, Alexander Gitter wrote:
> The problem persists with the Karmic RC installer.

Indeed. There does exist an APT branch which would make cdrom: URLs
discover CD devices dynamically; once that's merged (and I think it will
be in Lucid), we'll be able to drop this problematic code from the
installer.