Installer should not list removable media in /etc/fstab

Bug #150872 reported by Adrian Wilkins on 2007-10-09
80
This bug affects 3 people
Affects Status Importance Assigned to Milestone
usb-creator
Invalid
Undecided
Unassigned
partman-target (Ubuntu)
High
Ubuntu Installer Team
Intrepid
High
Ubuntu Installer Team
ubiquity (Ubuntu)
High
Unassigned
Intrepid
High
Unassigned

Bug Description

Binary package hint: ubiquity

When installing Ubuntu from a USB CDROM drive (common on small laptops), the drive is given a line in /etc/fstab. After installation, the drive is removed. The same device number is then subsequently assigned to the first flash drive inserted into the system. The OS attempts to mount the drive as cdfs without attempting automatic detection, which fails. This confuses non-technical users, leading to a negative user experience. Although this is easily fixed by a sudoer familiar with /etc/fstab, it could be confusing and crippling for other users.

Suggested solutions :

a) Since optical media are automatically mounted in a typical install, do not place a line in /etc/fstab for the drive.
b) Detect removable drives during install process and omit lines for them in /etc/fstab
   - corollary ; if I install on a system with a flash drive in a USB port, does that drive gain it's own permanent fstab entry?
c) If b) impossible, and a) undesirable, prompt the user during install process to confirm which (if any) drives represent removable units.
d) Assign device numbers more intelligently

Evan (ev) on 2007-12-12
Changed in ubiquity:
status: New → Invalid
era (era) wrote :

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.

era (era) wrote :

Retitled with stronger wording, as per above

Corey Burger (corey.burger) wrote :

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

sam tygier (samtygier) wrote :

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?

Changed in partman-target:
status: New → Confirmed
ek (schlicht-lmu) wrote :

"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

Adrian Wilkins (adrian-wilkins) wrote :

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.

Peter Halasz (member) wrote :

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.

Philip Van Hoof (pvanhoof) wrote :

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.

Changed in partman-target:
assignee: nobody → ubuntu-installer
Nick Barcet (nijaba) wrote :

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.

Changed in partman-target:
importance: Undecided → Medium
Colin Watson (cjwatson) wrote :

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.)

Pete Goodall (pgoodall) wrote :

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.

Evan (ev) wrote :

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

Evan (ev) wrote :

Forgot to account for UDF.

Changed in partman-target:
importance: Medium → High
status: Confirmed → In Progress
Evan (ev) wrote :

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.

Changed in usb-creator:
status: New → Invalid
Colin Watson (cjwatson) wrote :

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).

Colin Watson (cjwatson) wrote :

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 (ev) on 2008-10-16
Changed in ubiquity:
importance: Undecided → High
milestone: none → ubuntu-8.10
status: Invalid → Fix Committed
Tormod Volden (tormodvolden) wrote :

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")

Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in partman-target:
status: In Progress → Fix Released
David Favor (davidfavor) wrote :

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.

x (xyzx-deactivatedaccount) wrote :

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.

x (xyzx-deactivatedaccount) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.