updfstab screws up

updfstab screws up

Post by dan » Fri, 07 Feb 2003 12:56:06



Anyone else have a problem with /usr/sbin/updfstab
screwing up /etc/fstab??

We've got a system with with 3 scsi devices

HD                   /dev/sda
dat tape             /dev/st0
optical drive        /dev/sdb
and
an USB zip drive     /dev/sdc

But /etc/fstab has the zip drive listed as
/dev/sdb4 instead of /dev/sdc4

This is RH7.3. I filed a bugsy wiht RH
but I was wondering if anyone else has seen this.

/dan

 
 
 

updfstab screws up

Post by Dr. Yuan Li » Fri, 07 Feb 2003 14:15:50



> Anyone else have a problem with /usr/sbin/updfstab
> screwing up /etc/fstab??

> We've got a system with with 3 scsi devices

> HD                   /dev/sda
> dat tape             /dev/st0
> optical drive        /dev/sdb
> and
> an USB zip drive     /dev/sdc

> But /etc/fstab has the zip drive listed as
> /dev/sdb4 instead of /dev/sdc4

> This is RH7.3. I filed a bugsy wiht RH
> but I was wondering if anyone else has seen this.

> /dan

I don't see a bug.  It is the user's responsibility to
configure/customize updfstab, is this right?  It hardly matters what
fstab calls a file system as long as it's mountable.

Yuan Liu

 
 
 

updfstab screws up

Post by dan » Sat, 08 Feb 2003 11:22:08




>> Anyone else have a problem with /usr/sbin/updfstab
>> screwing up /etc/fstab??

>> We've got a system with with 3 scsi devices

>> HD                   /dev/sda
>> dat tape             /dev/st0
>> optical drive        /dev/sdb
>> and
>> an USB zip drive     /dev/sdc

>> But /etc/fstab has the zip drive listed as
>> /dev/sdb4 instead of /dev/sdc4

>> This is RH7.3. I filed a bugsy wiht RH
>> but I was wondering if anyone else has seen this.

>> /dan

> I don't see a bug.  It is the user's responsibility to
> configure/customize updfstab, is this right?  It hardly matters what
> fstab calls a file system as long as it's mountable.

> Yuan Liu

No, it is a bug. updfstab probes the system for Zip drives, JAZZ,
cdroms, etc. It then enters the appropriate mount info into /etc/fstab.
There's no reason to modify updfstab configuration file for normal
things like ZIP drives etc.

It found the ZIP drive but this is what it put in fstab:

/dev/sdb4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

but /dev/sdb is the MO drive not the ZIP drive; the entry should be

/dev/sdc4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

/dan

 
 
 

updfstab screws up

Post by Dr. Yuan Li » Sat, 08 Feb 2003 13:39:48


[snip]

Quote:>>> This is RH7.3. I filed a bugsy wiht RH
>>> but I was wondering if anyone else has seen this.

>>> /dan

>> I don't see a bug.  It is the user's responsibility to
>> configure/customize updfstab, is this right?  It hardly matters what
>> fstab calls a file system as long as it's mountable.

>> Yuan Liu

> No, it is a bug. updfstab probes the system for Zip drives, JAZZ,
> cdroms, etc. It then enters the appropriate mount info into /etc/fstab.
> There's no reason to modify updfstab configuration file for normal
> things like ZIP drives etc.

> It found the ZIP drive but this is what it put in fstab:

> /dev/sdb4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

> but /dev/sdb is the MO drive not the ZIP drive; the entry should be

> /dev/sdc4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

Yes, I understand that this is a nuisance - and just that.  You can
still access your MO drive under the mount point /mnt/zip250.0, right?
Compare what dmesg says about your MO drive with entries in
updfstab.conf.default (preshipped updfstab.conf contains only one
include statement to refer to this default) and you'll see it's your MO
drive that told kernel modules something that confused updfstab.

I would like my CD-RW mounted at /mnt/cd-rw because I also have a DVD
drive (which I prefer to be called /mnt/dvdrom).  Having coexisting
/mnt/cdrom and /mnt/cdrom1 had been very frustrating at times.  Do you
consider this a bug, too? (Unlike the former Sun, HP, DEC, and IBM's own
hardware spaces, IMO it's impractical to have one vendor to ship a
default table that distinguishes all devices used in today's x86
architecture, even though they created the monster.  One thing RH can do
is perhaps be more restrictive in default updfstab.conf so untested
hardware won't appear and force users to configure themselves.  Sorta
defeated the purpose of kudzu but, hey, the*driver is there.)

Yuan Liu

- Show quoted text -

Quote:> /dan

 
 
 

updfstab screws up

Post by Daniel Gane » Sat, 08 Feb 2003 23:39:28




> [snip]
> >>> This is RH7.3. I filed a bugsy wiht RH
> >>> but I was wondering if anyone else has seen this.

> >>> /dan

> >> I don't see a bug.  It is the user's responsibility to
> >> configure/customize updfstab, is this right?  It hardly matters what
> >> fstab calls a file system as long as it's mountable.

> >> Yuan Liu

> > No, it is a bug. updfstab probes the system for Zip drives, JAZZ,
> > cdroms, etc. It then enters the appropriate mount info into /etc/fstab.
> > There's no reason to modify updfstab configuration file for normal
> > things like ZIP drives etc.

> > It found the ZIP drive but this is what it put in fstab:

> > /dev/sdb4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

> > but /dev/sdb is the MO drive not the ZIP drive; the entry should be

> > /dev/sdc4     /mnt/zip250.0 auto    noauto,owner,kudzu 0 0

> Yes, I understand that this is a nuisance - and just that.  You can
> still access your MO drive under the mount point /mnt/zip250.0, right?
> Compare what dmesg says about your MO drive with entries in
> updfstab.conf.default (preshipped updfstab.conf contains only one
> include statement to refer to this default) and you'll see it's your MO
> drive that told kernel modules something that confused updfstab.

Nothing that would/should confuse the kernel. The MO is an HP C1113J
(extremely common). Vendor ID:HP Desc:C1113J Type:Optical. Also there's
nothing in updfstab.conf (RH 7.3) that vaguely resembles an MO or the
desc string of the MO. (I would assume that the "J" in C1113J isn't confused
with "jaz") According the man page upsftab only recognizes three classes:
hd, cdrom and floppy.

So, I guess I'll have to modify updfstab.conf.  But, it's still a bug.
We sell turnkey system and I really hate to have to tweak things that
we didn't add or break.

- Show quoted text -

Quote:> I would like my CD-RW mounted at /mnt/cd-rw because I also have a DVD
> drive (which I prefer to be called /mnt/dvdrom).  Having coexisting
> /mnt/cdrom and /mnt/cdrom1 had been very frustrating at times.  Do you
> consider this a bug, too? (Unlike the former Sun, HP, DEC, and IBM's own
> hardware spaces, IMO it's impractical to have one vendor to ship a
> default table that distinguishes all devices used in today's x86
> architecture, even though they created the monster.  One thing RH can do
> is perhaps be more restrictive in default updfstab.conf so untested
> hardware won't appear and force users to configure themselves.  Sorta
> defeated the purpose of kudzu but, hey, the*driver is there.)

> Yuan Liu

> > /dan