Bug 18662 - Can't mound file systems - previous major/minor #'s now incorrect
Summary: Can't mound file systems - previous major/minor #'s now incorrect
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mount
Version: 7.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-08 23:21 UTC by Roger Penn
Modified: 2007-04-18 16:29 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-10-30 14:06:49 UTC
Embargoed:


Attachments (Terms of Use)

Description Roger Penn 2000-10-08 23:21:01 UTC
I read the bug about not being able to mount floppys vfat (#18490). The 
suggested solution was to remove all vfat mounts from fstab. Did that, no 
luck. However, my problem is not confined to vfat. I cannot mount a 
floppy, no matter what file system, without the following error:

mount: /dev/hd0 has wrong major or minor number.

The major/minors for a floppy have always been 0/0 as far as I know, and 
worked just fine under 6.2. I upgrade to 7.0 and can no longer access my 
floppy (or windows partitions, but that's less critical). You posted a 
bugfix (anaconda-vfat-label-fix.img) that requires dd'ing an image to a 
floppy and booting with that. How the heck can I dd it to a floppy when I 
can't mount a floppy?!? Yes, I could do it on another working system, but 
that's not the point. What if I didn't have access to one?

Here's the bizarre part- I do not have this problem on my "desktop" 
system. I upgraded to 7.0 and the same old fstab entry mounts floppys just 
fine. This problem only occurs on my IBM ThinkPad 600X. Had no problem 
under 6.2, but now I can't use a floppy with 7.0. I am going to try to 
make and use that fix img, and see what happens. But I would still 
consider this a "bug" regardless. Whether or not it has any priority, of 
course, depends on whether or not it's confined to ThinkPad 600X's or 
affects lots of people.

Comment 1 Bernhard Rosenkraenzer 2000-10-09 09:29:40 UTC
I can't reproduce this (but then I don't have a thinkpad). Is the thinkpad doing
any oddities in floppy access (PCMCIA or USB floppy?)?

Comment 2 Roger Penn 2000-10-09 10:56:21 UTC
No, it's neither a USB or PCMCIA floppy, it's the OEM floppy connected to the 
floppy port. And no, it's not doing anything strange. It's always worked fine. 
I was able to format an ext2 floppy on my other machine and it mounted fine on 
the Thinkpad. So I saved my essential configuration files to floppy (which is 
why I needed it so) and then did a clean workstation install. The new install 
(with an identical fstab, I might add) works just fine. In fact I was very 
impressed that compared to installing 6.2 on the same laptop and all the hoop-
jumping and workarounds that had to be done, this was a snap and everything 
works great (except the sound card - never could make that work). So the 
problem appears to be only a result of an upgrade from 6.2. I don't think this 
one's worth the time and effort to fix on the off chance that someone, 
somewhere, might also do a default upgrade from 6.2 to 7.0 on a Thinkpad 600X 
and have this problem. Unless you do...

Comment 3 Need Real Name 2000-10-16 20:45:29 UTC
I have the problem mounting windows partitions that this user alluded to.  I get the same error about wrong major or minor number.  I am using an AST 
desktop system with an AMD 586 processor running at 133 Mhz.  The drives are set up like this

hda - Windows drive with a linux swap partition
hdb - CDRom drive
hdc - Linux drive

The swap partition works OK as far as I can tell.

Comment 4 Need Real Name 2000-10-27 16:37:05 UTC
I too am havin the same problem when I try to mount my cdrom on my HP Omnibook 
XE2 laptop - 'major or minor number incorrect'.

Comment 5 Need Real Name 2000-10-27 19:03:33 UTC
I figured out my problem.  When I created a boot disk I had the write protect on so I was booting my 7.0 system with a 6.1 vmlinuz.  I recreated the boot 
disk and then everything worked OK.


Comment 6 Need Real Name 2000-10-30 14:06:46 UTC
Judging by Jsusanj's response above, I think it may be due to the upgrade path 
- I noticed that I am booting with my old kernel, when I try a lilo -v I get a 
'geo_comp_addr:Cylinder number is too big' (1108 > 1023) error.

Comment 7 Bernhard Rosenkraenzer 2000-11-03 10:00:30 UTC
Can't work with old kernels because of internal changes.


Note You need to log in before you can comment on or make changes to this bug.