From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 Description of problem: Once I click the Next button of the install screen where there is the checkbox "Customize packages to be upgraded" (or something like that), I get an error message window that says "One or more of the filesystems for your Linux system was not unmounted cleanly. Please boot your Linux installation, let the filesystems be checked, and shut down cleanly to upgrade." Once I click Ok, the installer shuts down for reboot. I have verified several times that there are no filesystems at that point that are uncleanly unmounted. This happens both in normal upgrade and expert mode upgrade. Version-Release number of selected component (if applicable): How reproducible: Always Additional info: I'm upgrading a Redhat 7.1 system. Disks and filesystems are Device Boot Start End Blocks Id System /dev/hda1 * 1 3824 30716248+ c Win95 FAT32 (LBA) /dev/hda2 3825 9728 47423880 f Win95 Ext'd (LBA) /dev/hdb1 * 1 17 136521 83 Linux /dev/hdb2 18 1770 14080972+ 83 Linux /dev/hdb3 1771 1821 409657+ 82 Linux swap /dev/hdb4 1822 1869 385560 83 Linux /dev/hdd1 1 1232 9896008+ 83 Linux All linux partitions have ext2 filesystem. hda1 has FAT. Maybe the fact hda2 is an extended partition but there are no logical partitions inside it confuses the installer?
I filled hda2's extended partition with a logical partition and created a FAT32 filesystem on it, but that didn't change the behaviour of the installer.
Can you attach the /etc/fstab file from your 7.1 system?
The /etc/fstab is: LABEL=/ / ext2 defaults 1 1 LABEL=/boot /boot ext2 defaults 1 2 /dev/fd0 /mnt/floppy auto noauto,owner 0 0 none /proc proc defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 /dev/hdb3 swap swap defaults 0 0 #/dev/hdb4 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom iso9660 noauto,owner,kudzu,ro 0 0 /dev/loop0 /mnt/loop0 iso9660 defaults,noauto 1 3 #nauris:/ /nauris nfs defaults,soft,rsize=8192,wsize=8192 0 0 //localhost/homes /home/skarkkai/nauris smb sockopt=TCP_NODELAY,sockopt=IPTOS_LOWDELAY,SO_SNDBUF=262144,SO_RCVBUF=262144,user,username=skarkkai,password=xxxxxxxx,port=13139 0 0 /dev/fd0 /mnt/dos/a msdos owner,defaults,noauto 0 0 /dev/hdd1 /data ext2 defaults,user 0 0 /dev/hda1 /mnt/dos/f vfat defaults,user,uid=500,umask=0002,utf8 0 0 #/dev/hda2 /mnt/dos/g vfat defaults,user,uid=500,umask=0002,utf8 0 0
Created attachment 34721 [details] file /etc/fstab from the RH 7.1 system being upgraded
Bugzilla wrapped the lines of my previous comment, so I also created an attachment containing the same data.
Created attachment 34765 [details] /etc/fstab file
Hmmm...I'm thinking that the installer is getting confused by your /etc/fstab file for some reason. Try this: back up your existing fstab file and then try the one I just attached instead. I just commented out some partitions that you won't need during the upgrade process. You can restore the original after the install. Does this help?
Yes, that fixed it. I narrowed it down to /dev/hdd1 /data ext2 defaults,user 0 0 Commenting out that line from the original fstab makes installation proceed past the point it stops at otherwise.
Very odd. Are you sure that partition was not unmounted cleanly? I can think of no other reason for the installer to fail on it...
At least the Redhat 7.1 system never complained about that filesystem. However when I did e2fsck in the shell console of Redhat 7.2 installation, e2fsck said that the filesystem is not unmounted cleanly, and started checking it. After that, the problem went away, and Redhat 7.2 installer no longer considers the filesystem not cleanly unmounted, even in subsequent installs. So from Anaconda's point of view, there apparently was no bug in Anaconda. It would seem to me, instead, that RH71 and RH72 ext2 code has a different idea of when a filesystem is clean. Or maybe RH71 did consider the filesystem unclean but never told about it.
Well, the partitioning and disk detection code did change between 7.1 and 7.2. We switched from libfdisk to GNU/parted, so that may account for the difference in behavior, although that seems unlikely. Anyway, I'm going to close this report now since things seem to be working now. Thanks for your report.