NTFS partitions and gparted

I was installing a new operating system in one of my PCs recently and remembered the saga I had to face a couple of months ago during an attempt to manipulate NTFS partitions with gparted.

I had used gparted (gui of parted) for resizing FAT32 partitions of a dual boot XP-linux PC earlier, when I wanted to increase the size of the “C” partition of XP by reducing the adjacent partition. gparted had worked excellently. With the use of Windows XP commands fixmbr and fixboot, there was no problem in booting XP. Based on the confidence thus gained, I attempted to resize and move NTFS partitions of another dual boot XP-linux PC with the aim of ultimately increasing the size of the linux partitions. I was so confident that I did not take any backup, which proved catastrophic.

The system had many NTFS volumes with Windows XP installed in the first primary NTFS partition. It had an extended partition having three NTFS volumes and two other primary partitions for /boot and LVM. I booted the system in Fedora 12 and ran the batch in gparted to reduce and move the three NTFS subpartitions. However, after reducing the first subpartition, an error that “Current NTFS volume size is bigger than the device size” came and further operations did not occur. By searching the net, I became aware of this bug and also how to overcome it (http://gparted-forum.surf4.info/viewtopic.php?id=13937). I followed the advice and could recover the partition. However, Windows refused to boot. I learnt from the net that scandisk (or chkdsk, I do not clearly remember now) in Windows will correct all the problems. My confidence increased further and I ran the gparted batch again to complete the jobs as originally planned. Alas, moving and shrinking did not get corrected by the method this time, as start and end of the partition and its size as indicated by parted were consistent. I am not sure if the method works for moving an NTFS partition. In an attempt to recover data, I ran Windows XP scandisk, which ran for quite some time, but still could not boot Windows. As far as I remember, the partition having Windows system was not touched at all by gparted. On booting with Fedora 12 and mounting the Windows system partition, I noticed that I lost about 10% of my data randomly. Moved NTFS partition was not accessible at all.

gparted site (http://gparted-forum.surf4.info/viewtopic.php?id=13777) indicates that its newer versions (and some older with patch) do not have this bug, although I do not have this experience. I had used gparted obtained from Fedora repos, which might not have released the patch (around August 2010) in updates. Moral of the story is that one should always back up data while resizing partitions.

New P4 motherboard and Linux on AGP card with onboard display

After about eight years of working properly, P4 motherboard of my desktop computer gave way. The operating systems (both Windows XP Home SP3 and Fedora 12) would not boot properly and if booted somehow would crash all of a sudden. The motherboard was of HIS (Maxtone) make, ATX sized, Intel 845 chipset based with three SDRAM slots, two USB1 ports and six PCI slots (and without onboard display adaptor). I had put Intel P4 2.0 GHZ processor, nVidia GeForce FX5500 with 256MB RAM in the AGP slot, 2×512MB + 256 MB RAM, an ethernet PCI card, a USB2 PCI card, a Firewire PCI card and a SATA hard disk through a SATA-to-IDE-and-IDE-to-SATA converter. After considerable thinking, I realized that except for occasional raw video playing, the computing power of the system is still sufficient for my work.

The market survey revealed that new P4 motherboards with socket 478 (which would take P4 processor upto 2.4 GHz speed) are available in market with one year warranty. These motherboards have one floppy port, two IDE ports, two SATA ports, two USB2 ports (and probably two additional front USB2 ports), one ethernet (LAN) port, onboard intel 845 display chip with 128MB VRAM, two PCI slots and one AGP slot (8×), and are of microATX size. However, these support only DDR1 RAM (two sticks). Also, it did not have support for cabinet fan, which I was not using even in my earlier motherboard. Except for the firewire card, other PCI cards used in my earlier motherboard were not required in this motherboard. The price of this motherboard was Rs 1600/- in July 2010 including delivery charges. I obtained 2×512MB DDR1 RAM from a friend, who recently bought a new computer. I felt procuring the motherboard at this juncture would be the best bargain; I would upgrade to Intel Core i5, when its prices come down further in two years or so.

The motherboard was marketed by SRM Distribution Pvt. Ltd., Mumbai ("SRM: Technology Beyond Limits") (manufactured by Lord Electronics Co., Ltd). It came in impressive factory sealed packing. I removed the processor fan and the processor from the old motherboard and mounted both on the new motherboard and made other connections. Alas, no display. However, the motherboard, the harddisk and the keyboard was getting powered on. I felt sorry for my decision of continuing with P4. Later, I realized that the problem was that the processor was loose; it was coming out of its socket even when its lever was locked. I was pretty sure that I am putting the processor in the correct manner as it was getting properly locked in the old motherboard. I fired the retailer and made him replace the motherboard with a new one (instead of going to the service centre). However, in this motherboard too, the processor was coming out of its socket. After searching in the net, I realized that the processor is to be slightly pressed in a new socket while its lever is being locked. I mounted the processor in the correct way and the computer started normally. I apologized the poor retailer, who fortunately did not mind.

Although the BIOS supported booting from a USB drive, I could never boot the system using it. Never mind, as it was true for the earlier motherboard as well.

However, I faced a peculiar problem in Linux. If I used onboard display, then the linux (Fedora 12 and 13) booted normally. But xorg.conf generated while using the onboard display had showed both the display adaptors as Intel and placing the monitor on the AGP card after boot did not show any displaay.

If I used nVidia card fitted to the AGP slot, the system gave errors ending with “Fixing recursive fault but reboot is needed”. Rebooting gave the same fault again. Log files did not record these boot attempts. I could load the proprietary nVidia driver from RPM Fusion site while using onboard display. Then I connected the monitor to the nVidia card and rebooted the system (with BIOS display sequence being the onboard display first). The monitor remained blank initially, but became “on” when the X started and then it behaved more or less normally. However, xorg.conf file had both the displays as nVidia and correcting one to Intel did not have any effect on rebooting; it returned to nVidia. Studying nVidia driver documentation indicated that the problem is with agpgart of latest kernels; nvidia agp can handle intel adaptor. You have to pass “agp=off” command to the kernel during boot (by correcting the bootloader configuration file). This has resulted in the computer booting from AGP card (display sequence in BIOS being AGP first) right from the beginning and showing no problem in starting X. I have not tried using two monitors (one each on the AGP card and the onboard display), but I hope it should work by correcting the xorg.conf. If necessary, identify the two display adaptors by their BusID.

For passing “agp=off” to kernel only once, press any key during the grub screen, go to the desired OS (for example, Fedora) using up and down arrows and then press “E”. Go to the line beginning with kernel and add “agp=off” without the quotes at the end of this line. Press return and press “B” to boot. If it works, then edit your grub.conf file to add these words at the end of the desired kernel line.

I noticed that "agp=off" command is to be passed to the kernel in Fedora 13, Fedora 14, Fedora 15 and Fedora 17 as well. I did not try Fedora 16.

Using the method mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=745202#c94, I have been able to obtain Gnome Shell (normal mode of Gnome 3) in Fedora 17, but it is definitely sluggish; Gnome Fallback mode or Xfce provides reasonable speed. Another problem I notice in Fedora 17 is that the voice has interruptions in totem movie player, although rhythmbox and amarok work properly in this PC.

Seagate firmware upgrade and grub error 18

I use Pentium 4 (2.0 GHz) PC having Intel 845 chipset based motherboard. The computer has 1.2GiB 133 MHz SDRAM and originally had one Samsung-make 60GB IDE hard-disk with Windows XP and an old linux operating system.

The motherboard had one spare IDE port and supported Ultra ATA100 IDE hard-disk. As the IDE hard disks are fast becoming obsolete, I decided to procure a SATA hard-disk alongwith a converter that converts SATA/ SATA2 to Ultra ATA133 hard disk or vice versa. [This converter costed about Rs 300 (Indian)]. I knew that Ultra ATA133 is backward compatible with Ultra ATA100.

I procured Seagate make 500 GB SATA hard disk (Barracuda 7200.11, ST3500820AS) and installed it on the PC using the converter. BIOS recognized the hard disk after I used the hard disk's jumper required to limit its speed. The hard disk was partitioned: first 118 GB NTFS partition, next 210 MB ext4 linux (Fedora 12) boot partition, then 354 GB extended partition (containing three secondary 118 GB NTFS partitions) and finally 28 GB ext4 LVM2 volume. Grub was loaded on MBR of the new hard disk with options to boot linux from this drive or Windows or linux from the older drive.

The PC worked perfectly for quite some time. Then, I started getting following grub error intermittently on booting Fedora 12 (linux from the new Seagate disk) :

Error 18: Selected Cylinder exceeds maximum supported by BIOS

Many a times (though not always), the error went off after rebooting if the PC was first booted using an OS of the first disk. fscking (using liveCD) the boot partition of Fedora 12 never showed any error. Self-tests on the disk carried out using Palimpsest Disk Utility were always automatically aborted.

I was managing this way. However, once there occurred a superblock on the LVM2 partition, which was impossible to remove using any options with fsck. It was not possible to boot Fedora 12. Stopping X (with Alt-Ctrl-Bkspce) used to give long message with DRDY ERR on the Seagate drive. The data of the partition, however, was accessible using ext2explore for Windows (with Windows being booted from the Samsung drive). NTFS partitions of the Seagate drive were also accessible using Windows. Sooner, the BIOS intermittently stopped recognizing the Seagate drive. I procured a new SATA to IDE and IDE to SATA converter, but there was no improvement. I decided to replace the hard disk and went to Seagate site to check if any warranty was available and I learnt about the firmware upgrade being available for the disk. The firmware originally installed on the disk was SD25 and the recommended one was SD1A. According to the site, without the upgrade, the hard disk may lock itself and may not be recognized by the BIOS. Attempts to upgrade the firmware through Windows did not succeed, thus I downloaded the firmware upgrade boot ISO, burnt it on a CD and booted the PC and upgraded the firmware.

The firware upgrade did not immediately led to the booting of Fedora 12. However, the site repeatedly warns that 20% of the hard disks returned during warranty do not really have any problem and advises to use Seatools software (available on the Seagate site) for diagnosis. One has to burn Seatools for DOS ISO (available from Seagate site) on a CD and boot the PC through it. Seatools found errors with the disk and repaired them all.

Fedora 12 boots normally now and I have never got the grub 18 error since then. Palimpsest Disk Utility still cannot complete the self-test on this disk, but the disk works normally otherwise.

I am not fully sure if there is a connection between the firmware upgrade and intermittent grub 18 error, which did not appear to have a logical pattern. However, if you are using a Seagate disk and get this error, you may consider visiting Seagate site; many disks are affected due to old firmwares.