Red Hat Bugzilla – Bug 6215
Upgrade to Redhat 6.1(updated images) still mounts ntfs partitions as ext2 !!
Last modified: 2015-01-07 18:39:01 EST
I tried the new images posted this evening to supposedly fix this problem. They actually crash the installation harder - this time you have to hard-boot out of the "searching for linux installations" message. Anaconda still tries to mount my partion /dev/hda6 as ext2 (which is really ntfs). My ext2 partition is on /dev/hda7. Another new problem with this update is it stalls much earlier at the point where it tries to run the "loader" on the cdrom. This happens after typing "linux updates", the kernel boots, then the installation tries to start up, and then it stalls, BUT only if the redhat 6.1 cd is in the drive at this time. Leaving the cd out of the drive allows the installation to start up and eventually get to graphics mode, where an "upgrade" fails again when it mounts the wrong partition. Why don't you look at the code for fdisk, and see how it determines the partition id??? Here's another idea... test the new images on a few machines with ntfs partitions that appear before any ext2 partitions, before releasing the fixes! ------- Additional Comments From 10/22/99 12:07 ------- Confirm the same problems on my upgrade. The install hangs if the CD is in the drive when it runs the loader. Once that problem has been bypassed, the install still crashes with the same error as before after the update disk has been run. hda1 is NTFS, hdb is ext2.
*** Bug 6247 has been marked as a duplicate of this bug. *** I am one of the unfortunate souls who has been bitten by the NTFS bug in the Red Hat 6.1 installer that bites when upgrading. This morning, I created new "boot" and "updates" floppies from the new image updates, and tried once again to upgrade my system. I used boot-RHEA-1999:044.img and updates-RHEA-1999:044.img. Failure. Here is the sequence of events: Boot from boot-RHEA-1999:044 boot disk, select English, US kbd, insert CD when requested, then inserted updates-RHEA-1999:044 floppy when requested. After the "Welcome!" screen, I selected "Upgrade Existing Installation". I got a window with "Error Mounting ext2 filesystem on hda1: Invalid Argument" After hitting OK, I got an "Exception Occured" window with the following python traceback: Traceback (inntermost last): File "/usr/bin/anaconda", line 225, in ? intf.run(todo, test = test) File "/tmp/updates/text.py", line 1009, in run rc = apply(step[1](), step[2]) File "/tmp/updates/text.py", line 222, in __call__ parts = todo.upgradeFindRoot() File "/tmp/updates/todo.py", line 1149, in upgradeFindRoot isys.umount('/mnt/sysimage') File "/usr/lib/python1.5/site-packages/isys.py", line 8, in umount return _isys.umount(what) SystemError: (22, 'Invalid Argument') My two disks are partitioned thustly: hda: Device Boot Start End Blocks Id System /dev/hda1 * 1 497 3992121 7 HPFS/NTFS (Win NT4) /dev/hda2 498 523 208845 6 FAT16 hdb: Device Boot Start End Blocks Id System /dev/hdb1 1 2 16033+ 83 Linux (/boot) /dev/hdb2 3 35 265072+ 82 Linux swap /dev/hdb3 36 243 1670760 83 Linux (scratch) /dev/hdb4 244 1229 7920045 83 Linux (Red Hat 6.0) The 'scratch' partition (hdb3) is used for trying out various Linux distributions as they hit the streets, and may or may not contain a valid Linux installation of some sort or another. I tried going to VC2 and mounting my / partition. it worked fine. You have mail in /var/spool/mail/mnelson
How are you creating the updates disk? If you are making them with rawrite, then this is your problem. Those updates disk are actually ext2 filesystems, which rawrite is not able to deal with. What ends up happening is the installer looks at the updates disk, sees no new code and continues to run the old code. Please reopen if you are still having problems.