1

Topic: Still resizing after more than 9 days

I started Gparted on three tasks:
1. Delete ~55 GB NTFS partition on a 500 GB drive.
2. Resize the existing ~410 GB ext3 partition on the drive to include the partition that was deleted in step 1 (ext 3 partition is prior to the deleted partition in the partition table).
3. Resize ext3 partition on 160 GB drive from 17.5 GB to ~33 GB (ext 3 partition is prior to the empty partition).

Gparted has now been stuck on "1 of 3 operations completed" for more than 9 days. The following has happened according to the log during step 2.
- Check (ok symbol after 6:57 min.)
- Grow partition from 410.50 GB to 465.76 GB (ok symbol after 0:04 min.)
- Check (forbidden symbol after 7:08 min.)
- Grow filesystem to fill the partition (running symbol)

Is this normal? Is it safe to shut down the computer, or do I risk data loss? The hard drive light flashes maybe once every 2 seconds. Does the forbidden symbol indicate something?

2

Re: Still resizing after more than 9 days

Hi!

When GParted is running, usually the Hard drive LED is lit permanently (permanent hard drive access - which is useful to get things done as fast as possible).
Your flashing every two seconds could indicate a problem with either youe hard drive, you IDE/SATA controller, with your cabling, or with the IDE/SATA driver used by GParted.
You could try to open a terminal and dump the kernel messages using the dmesg command... and please post them here! If there's something wrong witrrh your storage subsystem, these messages will tell us.

3

Re: Still resizing after more than 9 days

Here is the dmesg output:

, try "pci=routeirq".  If it helps, post a report
NET: Registered protocol family 8
NET: Registered protocol family 20
Time: tsc clocksource has been installed.
system 00:00: iomem range 0xd1800-0xd3fff has been reserved
system 00:00: iomem range 0xf0000-0xf7fff could not be reserved
system 00:00: iomem range 0xf8000-0xfbfff could not be reserved
system 00:00: iomem range 0xfc000-0xfffff could not be reserved
system 00:00: iomem range 0x3fff0000-0x3fffffff could not be reserved
system 00:00: iomem range 0xffff0000-0xffffffff could not be reserved
system 00:00: iomem range 0x0-0x9ffff could not be reserved
system 00:00: iomem range 0x100000-0x3ffeffff could not be reserved
system 00:00: iomem range 0xfee00000-0xfee00fff has been reserved
system 00:02: ioport range 0x4d0-0x4d1 has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: ec000000-edffffff
  PREFETCH window: e0000000-e7ffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
checking if image is initramfs... it is
Switched to high resolution mode on CPU 0
Freeing initrd memory: 5986k freed
audit: initializing netlink socket (disabled)
audit(1228572998.228:1): initialized
Total HugeTLB memory allocated, 0
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Applying VIA southbridge workaround.
PCI: VIA PCI bridge detected. Disabling DAC.
PCI: Disabling Via external APIC routing
Boot video device is 0000:01:00.0
vesafb: framebuffer at 0xe0000000, mapped to 0xf8880000, using 1875k, total 32768k
vesafb: mode is 800x600x16, linelength=1600, pages=3
vesafb: protected mode interface info at c000:0a15
vesafb: pmi: set display start = c00c0a4e, set palette = c00c0ac4
vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da 
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 100x37
fb0: VESA VGA frame buffer device
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
EISA: Probing bus 0 at eisa.0
Cannot allocate resource for EISA slot 4
Cannot allocate resource for EISA slot 5
Cannot allocate resource for EISA slot 6
EISA: Detected 0 cards.
cpuidle: using governor ladder
cpuidle: using governor menu
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
registered taskstats version 1
Freeing unused kernel memory: 324k freed
input: AT Translated Set 2 keyboard as /class/input/input0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 10, io base 0x0000c400
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
libata version 3.00 loaded.
ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:07.3: UHCI Host Controller
uhci_hcd 0000:00:07.3: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:07.3: irq 10, io base 0x0000c800
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
uhci_hcd 0000:00:08.0: UHCI Host Controller
uhci_hcd 0000:00:08.0: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:08.0: irq 10, io base 0x0000cc00
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:08.1[b] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
uhci_hcd 0000:00:08.1: UHCI Host Controller
uhci_hcd 0000:00:08.1: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:08.1: irq 11, io base 0x0000d000
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
PCI: setting IRQ 5 as level-triggered
ACPI: PCI Interrupt 0000:00:08.2[C] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
ehci_hcd 0000:00:08.2: EHCI Host Controller
ehci_hcd 0000:00:08.2: new USB bus registered, assigned bus number 5
ehci_hcd 0000:00:08.2: irq 5, io mem 0xef021000
ehci_hcd 0000:00:08.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 4 ports detected
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKD] -> GSI 10 (level, low) -> IRQ 10
3c59x: Donald Becker and others.
0000:00:0b.0: 3Com PCI 3c905C Tornado at f882e000.
sata_promise 0000:00:0d.0: version 2.11
ACPI: PCI Interrupt 0000:00:0d.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
scsi3 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0xef022000 port 0xef022380 irq 11
ata2: SATA max UDMA/133 mmio m4096@0xef022000 port 0xef022280 irq 11
ata3: SATA max UDMA/133 mmio m4096@0xef022000 port 0xef022200 irq 11
ata4: SATA max UDMA/133 mmio m4096@0xef022000 port 0xef022300 irq 11
ata1: SATA link down (SStatus 0 SControl 300)
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: ATA-8: WDC WD5000AAKS-00YGA0, 12.01C02, max UDMA/133
ata2.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata2.00: configured for UDMA/133
ata3: SATA link down (SStatus 0 SControl 300)
ata4: SATA link down (SStatus 0 SControl 300)
scsi 1:0:0:0: Direct-Access     ATA      WDC WD5000AAKS-0 12.0 PQ: 0 ANSI: 5
VP_IDE: IDE controller (0x1106:0x0571 rev 0x06) at  PCI slot 0000:00:07.1
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
Driver 'sd' needs updating - please use bus_type methods
sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda3
sd 1:0:0:0: [sda] Attached SCSI disk
hda: WDC WD1600JB-00GVA0, ATA DISK drive
hda: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hda: UDMA/100 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: LITEON DVD-ROM LTD163, ATAPI CD/DVD-ROM drive
hdc: host max PIO5 wanted PIO255(auto-tune) selected PIO4
hdc: UDMA/33 mode selected
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 512KiB
hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63
hda: cache flushes supported
 hda: hda1 < hda5 hda6 > hda2
hdc: ATAPI 40X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.20
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
ISO 9660 Extensions: Microsoft Joliet Level 3
ISO 9660 Extensions: RRIP_1991A
aufs 20080128
loop: module loaded
squashfs: version 3.3 (2007/10/31) Phillip Lougher
aufs test_add:387:mount[879]: uid/gid/perm //filesystem.squashfs 0/0/0755, 0/0/01777
Linux agpgart interface v0.102
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 64M @ 0xe8000000
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
parport_pc: VIA parallel port: io=0x378, irq=7
gameport: EMU10K1 is pci0000:00:09.1/gameport0, io 0xdc00, speed 1242kHz
Real Time Clock Driver v1.12ac
input: PC Speaker as /class/input/input1
fuse init (API version 7.9)
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
JFS: nTxBlock = 7081, nTxLock = 56649
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.12.0-ioctl (2007-10-02) initialised: dm-devel@redhat.com
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
end_request: I/O error, dev fd0, sector 0
Buffer I/O error on device fd0, logical block 0
end_request: I/O error, dev fd0, sector 0
Buffer I/O error on device fd0, logical block 0
usb 1-2: new low speed USB device using uhci_hcd and address 2
usb 1-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver hiddev
input: Logitech USB Receiver as /class/input/input2
input,hidraw0: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:07.2-2
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
usb 1-2: USB disconnect, address 2
usb 1-2: new low speed USB device using uhci_hcd and address 3
usb 1-2: configuration #1 chosen from 1 choice
input: Logitech USB Receiver as /class/input/input3
input,hidraw0: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:07.2-2
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
ata2.00: port_status 0x20080000
ata2.00: cmd 25/00:fe:11:09:8c/00:00:1e:00:00/e0 tag 0 dma 130048 in
         res 50/00:00:0e:0a:8c/00:00:1e:00:00/e0 Emask 0x2 (HSM violation)
ata2.00: status: { DRDY }
ata2: soft resetting link
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
sd 1:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
BUG: unable to handle kernel paging request at virtual address 00004000
printing eip: c014cc60 *pde = 00000000 
Oops: 0000 [#1] 
Modules linked in: usbhid hid dm_mod jfs xfs fuse pcspkr rtc firmware_class emu10k1_gp gameport crc_itu_t i2c_viapro i2c_core via686a shpchp via_agp parport_pc pci_hotplug agpgart parport evdev squashfs loop aufs nls_iso8859_1 isofs zlib_inflate ext3 jbd ide_cd cdrom ide_disk generic sd_mod via82cxxx ide_core floppy sata_promise 3c59x mii ata_generic ehci_hcd uhci_hcd libata usbcore scsi_mod

Pid: 2960, comm: e2fsck Not tainted (2.6.24-1-486 #1)
EIP: 0060:[<c014cc60>] EFLAGS: 00010093 CPU: 0
EIP is at find_get_pages+0x2f/0x58
EAX: 00000000 EBX: 0000000e ECX: 0000000b EDX: 00004000
ESI: f7fb1f00 EDI: 0000000e EBP: 061c8133 ESP: f7fb1eb8
 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
Process e2fsck (pid: 2960, ti=f7fb0000 task=f7453890 task.ti=f7fb0000)
Stack: 0000000e 061c8133 f7fb1ef8 c015143f f7fb1f00 c131b7e0 061c8132 c0151a54 
       0000000e f782c180 c014b45b 00000000 00000000 f782c180 00000000 ffffffff 
       00000000 00000000 c131c800 c131c820 c131c840 c131c860 c131c880 c131c8a0 
Call Trace:
 [<c015143f>] pagevec_lookup+0x1c/0x22
 [<c0151a54>] truncate_inode_pages_range+0x122/0x2c4
 [<c014b45b>] wait_on_page_writeback_range+0xac/0xef
 [<c0151c0d>] truncate_inode_pages+0x17/0x1a
 [<c0183361>] __blkdev_put+0x3f/0xf4
 [<c0166597>] __fput+0x93/0x140
 [<c0163e93>] filp_close+0x51/0x58
 [<c0164ff2>] sys_close+0x54/0x83
 [<c0103c72>] syscall_call+0x7/0xb
 =======================
Code: 83 ec 04 8b 74 24 10 fa 8d 04 05 00 00 00 00 90 90 83 c3 04 89 0c 24 89 d8 89 d1 89 f2 e8 4e 5c 08 00 31 c9 89 c3 eb 18 8b 14 8e <8b> 02 25 00 40 02 00 3d 00 40 02 00 75 03 8b 52 0c ff 42 04 41 
EIP: [<c014cc60>] find_get_pages+0x2f/0x58 SS:ESP 0068:f7fb1eb8
---[ end trace 2470eae5551efcac ]---

Any signs of what the problem is?

4

Re: Still resizing after more than 9 days

Hi,

see the line

BUG: unable to handle kernel paging request at virtual address 00004000

? This is the point where the trouble starts. It seems your system has some problems with memory management - and as far as I can see, the e2fsck command (which is used to check ext2/ext3 file systems for errors and fix them, which is done by GParted before actually modifyoing any ext2/ext3 partition) is directly hit by this problem. As a result, e2fsck does not work properly... or not at all.
I think the "forbidden" symbol you were writing about looks like a red "x" - right? This would mean the this step (checking the file system) failed; youe dmesg log says in principle the same. As a result, GParted does now maybe try to resize an unclean file system (I'm not that deep intop GParted to tell this for sure - maybe one of the developers can give mor reliable information here).
If GParted really tries to resize an unclean file system, this could easily result in 100% data loss. However, if GParted only says it is resizing the file system, but not actually performing any operations on this partition, it should be safe to interrupt the process.

5

Re: Still resizing after more than 9 days

I believe stormhead is on the right track.  Following are the steps that normally occur when resizing a file system.  Note that there are two resize operations.  The first one will grow (or shrink) the file system to the appropriate size.  The last one is part of a check to ensure that the file system did indeed grow (or shrink).  Normally this last step reports that there is nothing to do since the file system is already the correct size for the partition.

In the situation you describe, it would appear that a virtual memory error was encountered when checking the file system and this might be the cause for the resize operation taking forever to complete.

My suspicion is that it might never complete, and if it were me, I would halt the operation and hope for the best.

It would be good to run some tests to check the system memory, and also to check the hard drive for problems.  Of course it is best if you make backups of your valuable data before running checks on the hard drive that may overwrite data.


GParted 0.4.1

Libparted 1.8.8
Grow /dev/sdb15 from 509.84 MB to 517.69 MB  00:00:08    ( SUCCESS )
         
calibrate /dev/sdb15  00:00:01    ( SUCCESS )
         
path: /dev/sdb15
start: 202884948
end: 203929109
size: 1044162 (509.84 MB)
calculate new size and position of /dev/sdb15  00:00:01    ( SUCCESS )
         
requested start: 202884948
requested end: 203945174
requested size: 1060227 (517.69 MB)
new start: 202884948
new end: 203945174
new size: 1060227 (517.69 MB)
check file system on /dev/sdb15 for errors and (if possible) fix them  00:00:01    ( SUCCESS )
         
e2fsck -f -y -v /dev/sdb15
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

11 inodes used (0.01%)
1 non-contiguous inode (9.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
27020 blocks used (5.18%)
0 bad blocks
0 large files

0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2 files
e2fsck 1.40.8 (13-Mar-2008)
grow partition from 509.84 MB to 517.69 MB  00:00:02    ( SUCCESS )
         
old start: 202884948
old end: 203929109
old size: 1044162 (509.84 MB)
new start: 202884948
new end: 203945174
new size: 1060227 (517.69 MB)
check file system on /dev/sdb15 for errors and (if possible) fix them  00:00:02    ( SUCCESS )
         
e2fsck -f -y -v /dev/sdb15
         
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

11 inodes used (0.01%)
1 non-contiguous inode (9.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
27020 blocks used (5.18%)
0 bad blocks
0 large files

0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
--------
2 files
e2fsck 1.40.8 (13-Mar-2008)
grow file system to fill the partition  00:00:01    ( SUCCESS )
         
resize2fs /dev/sdb15
         
Resizing the filesystem on /dev/sdb15 to 530112 (1k) blocks.
The filesystem on /dev/sdb15 is now 530112 blocks long.

resize2fs 1.40.8 (13-Mar-2008)

6

Re: Still resizing after more than 9 days

Forbidden symbol:
http://www.roundabout.net/forbidden%2520to%2520enter.gif

So I have either a memory problem or a hard drive problem? I'll run memtest, and what do I run to check the hard drive? If these tests result in nothing, do you think GParted will succeed if I try to resize again?

The system I'm working on is a backup server, which means all the data on the drive is already present somewhere else. Therefore it is not a big crisis if I lose them, but it takes time to copy the data back. smile

7 (edited by stormhead 2008-12-21 18:14:40)

Re: Still resizing after more than 9 days

Hi,

memtest86 or memtest86+ are completely fine for checking your RAM - however, on a realtively new machine, memtest86+ could be faster due to better support for newer hardware.

Most hard drive manufacturers offer diagnostic utilities for download; you can use these to check your drives for errors. If "your" manufacturer does not offer anything, you can try either Hitachis's drive Fitness Test or Seagate's SeaTools for DOS - for the latter, you should make sure you get the graphical version; it is much easier to use and gives much clearer outputs than the text mode version. Both tools are available on a floppy image (which you can of course use to create a bootable CD, if necessary); the DFT should be available as a ready-to-birn iso image as well.
Please note that these tools may fail to access hard drives connected to a hardware RAID controller - these controllers tend to hide the connected drives from the BIOS and operating system and present one or more "virtual" volumes which consist of the storage space offered by the drives instead. So it could be necessary to connect the drive(s) to the OnBoard IDE or SATA controller for testing!

By the way: This memory allocation error is not necessarily a hint to faulty hardware - there is also a chance that the Linux kernel used on your GParted LiveCD does not know how to handle your chipset/mass storage/CPU/whetever correctly. A newer CD version - which likely contains a newer kernel - could help here.
And you can also try PartedMagic instead of GParted; this is another live CD dedicated to partitioning hard drives, and is also employs GParted as the main workhorse. But since it is based on a different Linux distribution, it contains slightly different versions of the tools included, and its kernel very likely was compiled using a different set of options - as a result, if you have a system where the GParted LiveCD fails, PartedMagic often works and vice versa. That's why I prefer to have both CDs at hand...

8

Re: Still resizing after more than 9 days

I rebooted now, and the disk has been resized and seems to be fine. I'll do a disk check with SeaTools and a memory check with memtest86+ anyhow.

I was using GParted version 0.3.7-7. Used 0.4.1-1 to do the remaining task, but I realized it wasn't necessary to keep the data on that disk, so I deleted the partitions instead of resizing it.

Thanks for all your help. smile

9

Re: Still resizing after more than 9 days

0.3.7-7 is quite old. There was big work done since then.
smile
(Topic moved to the live media section)

*** It is highly recommended to backup any important files before doing resize/move operations. ***

10 (edited by miceagol 2008-12-23 01:18:30)

Re: Still resizing after more than 9 days

The hard drive is fine according to SeaTools, but the memtest returned a bunch of errors. Is it important to do anything with that? The memory chips are quite old, PC100, but some BIOS settings might probably fix it?

11

Re: Still resizing after more than 9 days

Hi miceagol,

first, you should run memtest86 on only one single module (that is, remove all modules from the system, except one). Repeat this until you've tested all modules.
If you identified one single faulty module: Trash it and get a new one.
If all modules seem to have errors, this could mean that your CPU (especially the integrated caches) or memory controller (on the main board) are bad and need to be replaced.
Any way, working with faults hardware will result in data corruption and data loss!

The only way to work around memory errors using BIOS settings is to lower the memory clock (which is coupled to the CPU external clock on most systems - so the CPU clock must be decreased in this case, lowering overall system performance by 25 to 50% - depending on the clock decrease chosen) or the memory timings (whichg are usually not directly accessible on old PC100 based systems, so usually there's no way to do this on these machines).

12

Re: Still resizing after more than 9 days

Typical! The faulty memory module was the newest one with 512 MB RAM, and trashing that one means I get half as much memory as I had. Anyway, it's cheap for a new module on ebay. smile

Thanks for the info about memtest, stormhead!

13

Re: Still resizing after more than 9 days

Hi,

you should keep in mind that you'll easily find bad hardware sold as "works in my system, but I don't know if it is really good" on ebay - so there's no guarantee that a module you get there will be OK. In addition to this, for a single memory module, shipping costs might even by far exceed the price for the RAM.
One other possibility to find RAM for your system could be the various mail-order shops around - here in germany, you can still buy 512 MByte SDRAM modules this way, but these modules are of the higher-price segment (low-price manufacturers which have to mage their money on the mass market have reatcted from the SDRAM business long ago).
The big disadvantage of these two ways for getting your RAM is that the old SDRAM-based chipsets imposed restrictions on the layout of the memory modules that were not explicitly documented anywhere (since at the time the chipset was designed, they were no restrictions, but became later when memory technology advanced) - for example, the famous i440BX chipset was able to detect the whole capacity of a memory module only if each single chip on the module didn't exceed a given maximum capacity. At first, this was no problem since there were no large chips available; today, you can easily cram down the capacity for which you needed 32 or even more chips into one single memory chip. As a result, only a small fraction of a module would be recognized if it consisted of modern chips.
Typically, you won't find detailed information about the chipsets a certain module is comatible with on ebay or at your mail order shop's web site; instead, you'll have to hope that the module manufacturer has this data on theis web site.

The second way to get RAM would be a used-hardware dealer - in the city where I attended university we had a shop that bought large numbers of old computers (e.g. from companies that replaced their IT equipment), tested and (where necessary) overhauled them, and sold them (so if you didn't have that much money, you could still get a machine that was fast enough for approximately anything except modern games and serious number crunching for a reasonable price). When they encountered a broken system, the still working parts of them were sold separately.
The advantage of this store was (especially when it came to RAM) that they kept track about the mainboard/chipset each module was running on, so you could get memory that was known to work with your chipset easily.

14

Re: Still resizing after more than 9 days

Apparently, the two remaining 256 MB modules work fine individually, but I get errors when they are both connected (one in DIMM1 and the other in DIMM2). What does that imply? A defective motherboard?

Thanks for your info about old RAM. I'm very skeptical to buying second-hand RAM myself, but it is possible to get new RAM on E-bay, and the price is pocket fluff even with shipping. This one for example.

Buying old RAM from mail-order shops here in Norway is very expensive, and I do not intend on using that much money on an old system. smile But it's nice to use the old PC to host my backup disks, though a reduction from 1 GB to 256 MB RAM is sad.

15 (edited by stormhead 2008-12-29 00:26:39)

Re: Still resizing after more than 9 days

Hi!

Have you tested if the error occurs if a specific memory slot is used? If you test all modules in slot DIMM1, and all are OK there, this does not necessarily imply that the system will work fine if DIMM2 is used instead - corrosion or bending of the contacs as well as bad soldering points can prevent this.

If your problem is not caused by using a specific memorty slot (that is, yout two working modules are error-free in any memory slot), but sill occurs as soon as two modules are used, this is a hint to an electrical problem:
Data (and adress information) is transferred between the memory and the chipset by a stream of voltage pulses on each data line, where one voltage leven stands for a logical 1 and the other for a 0. In between, you'll find an "undefined" range. Data and adress transfer requires permanent changes between these two "valid" voltage levels. However, if the electrical circuit made up by these data lines is bad, it takes too long (compared with the memory clock and the chosen timing values) to take the transition between the "valid" levels - and at the time data is read by the chipset (or written to the memory cells), the voltage is somewhere in the undefined range, resulting in a memory error.
Basically, there are two ways to deal with this situation:
1. Fine-tune the memory clock and timing, so the transition to the opposite voltage level has enough time to complete. This can be done by decreasing the memory clock (which is - as I wrote above - usually coupled to the CPU clock and is therefore not favourable. However, if you have e.g. PC133 memory and a FSB100 CPU, vou can safely run the memory at 100 MHz as well - depending on your chipset, this will cause only a minor performance loss - or even slightly increase performance, expecially with Intel's Pentium II/Pentium III chipsets), or by slowing down the memory timing (please see your mainboard's manual if you can manually set the timing and where to do this). Talking about memory timing, the numbers displayed in the BIOS setup are time delays, measured in memory clock ticks - so higher values stand for longer delays, allowing the signals a bit more time to settle. As a result, higher numbers are safer here - but also a bit slower (usually, this can be measured with the right equipment, but the decrease is far too slow to be perceived by a human without any expensive instruments).
Still about memory timings, each SDRAM module carries a small EEPROM chip, named the "SPD EEPROM" - there, the memory manufacturer stores the fastest safe timing parameters for this module for the different possible clock speeds. During boot-up, the BIOS evaluates the SPD contents of all modules it finds, and can thus set the "overall" fastest safe timing automatically. In practice, this does not always work - e.g., sometimes only the SPD EEPROM on the first memory slot is evaluated. As a result, if the module in this slot permits faster timings than the module on the second slot, this will result in memory errors. Simply swapping the modules can solve this problem in this situation - so you should try this, too.
2. Modify the electrical parameters: The time required to transition from one voltage level to the next basically depends on the resistance, capacitance and inductance in the circuit, as well as on the driving voltage. Capacitance and inductance can not be modified - they are defined by the design of the memory module, chipset and mainboard, and can vary over lifetime due to component aging. However, you can decrease the resistance in the circuit be removing and re-inserting the memory modules (this will wear off corrosion on the electricval contacts).
In addition to this, most mainboards allow you to increase the operating voltage for the memory above the specification value; this will also result in a faster transition to the other valid voltage range and therefore stabilize the memory subsystem. However, increasing the voltage also causes increased thermal stress to the system, which in turn speeds up component aging - and shortens lifetime.

About old PCs and backup disks: 2 x Pentium III @ 450 MHz, seven hard drives (one to boot off, and three pairs of identical drives), where every two identical drives are joined into one software-driven RAID-1 array; LVM across all RAIDs (roughly 1,5 TBytes usable on the volume group, plus the biggest part of the boot drive). File access via FTP, Samba ("Windows network"), NFS, HTTP; along with some other gadgets like self-diagnostics and hardware monitoring. Running fine on Debian Etch (stripped down to the essential system components - no graphical desktop, no office, multimedia or development stuff; the whole operating system with all installed software consumes only about 500 MBytes of hard drive space) - with a mere 256 MByte RAM (of which typically two thirds are used as hard drive cache...) and a swap file that is practically never touched. Delivers up to 40 MByte/sec. across the network - which is roughly sufficient for home use. ;-) You see: 256 MBytes can well be enough...

16

Re: Still resizing after more than 9 days

Hehe, thanks stormhead. smile I do agree with you that I do not need all the memory modules. I'm probably just too stuck in the desktop PC world of thinking. Most importantly, there should not be any data corruption on a backup system, and my money is better used elsewhere. I'll try to fix the memory problems by following your hints, but in a worst case scenario I can live with 256 MB RAM.

The server runs Ubuntu 8.04 server with no X, and currently only functions as a backup server (rsync as cronjob from my desktop each night). I have plans for also using it as a web server, but the Internet connection is too slow for the time being, so I have probably replaced the server by then. wink

17 (edited by miceagol 2008-12-30 00:33:56)

Re: Still resizing after more than 9 days

Hmm, now I suddenly get no errors after over 20 passes with the two 256 MB modules inserted at the same time. neutral

18

Re: Still resizing after more than 9 days

Hi,

it is possible that you simply had some dirt ot rust on the contacts within one memory slot, and by repeatedly removiong and plugging in the module, this has worn off, so now you have a good electrical contact.
Or did you maybe omit one memory slot you used in all your previous tests? Then maybe this slot is bad...