SM 6.5 RC-3 (32 bit) and gparted

Except for the very latest Gparted (0.3.4-4?) [which has problems with the Nvidia Geforce Go 7600 GPU in my laptop and will only accept the vesa driver; earlier versions work OK.], there is nothing wrong with Gparted. Scanning is done perfectly. Both on my laptop and desktop system.
I have been using Gparted for (re)partitioning jobs (always from LiveCD) for a couple of years now. Never missed a beat.

Must be something else. Although I have no clue what.

Regards, Ko

Ko Bros

Normally, Ko, things like this fall into place fairly quickly, and a solution becomes evident. However, this gparted issue appears to be the recalcitrant parted-fe child.

I really don't know where it's falling apart, and have kept trying different release versions on another identical machine since posting. I did happen to get the 32-bit RC-3 past scanning, but it ended-up throwing errors and bailing on an NTFS resize, that qtparted doesn't choke on at all.

The gparted live CD was worse in that all versions locked-up the machine solid--requiring a jab at the red button.

I'll keep trying with it, but it does appear to my eye that gparted isn't dependable enough for me to rely upon in the "convert a windoze user" context. If I have to drag out a SLAX disc to do the partitioning, or do things from the CLI, that just isn't going to be perceived very well.

I do hope that it isn't too difficult to have both in final (How big can qtparted be, anyway?), even if gparted is the only K Menu entry.

If nothing else, serving as a dire warning to others is not a bad thing to be.

Both Gparted and Qtparted do depend on the parted package (and other, different packages).
My experiences with both utilities are just the opposite of what you find. Gparted always being the more reliable one here.

Anyway, adding qtparted to the 6.5 release shouldn't be a big problem (spacewise), since one of the 6.5 RC's (RC1?) did have both of them pre-installed.

You better email Warren about it - and pretty quick.

Ko Bros

I e-mailed dev at mepis.org about it on March 14th (two e-mails sent with symptoms and more).

The version of GParted in the Ubuntu repositories worked fine with 6.5 RC1.

But, not the one from the mepis repositories in 6.5 RC2 and later.

GParted never gets passed Scanning all Devices from a 6.5 RC2 Live CD, regardless if devices are unmounted or not.

It doesn't crash, and you can close it. It just never times out with no drive activity (at least not after around 8 minutes trying it more than one way.

I also tried installing GParted from a 6.5 RC1 install on the hard drive. It selected 0.2.5-2Mepis1 by default.

I got the same symptoms as I do from the 6.5 RC2 Live CD (GParted never gets past the scanning all devices screen, regardless if the partitions are mounted or not using the mepis package for it).

It's a relatively compatible setup with SimplyMEPIS (older 3.x.x, 6.x).

It's a Dell Dimension 8300 and uses the Intel 875P Chipset with an 800mhz FSB and integrated SATA. This one has an Intel 3GHZ P4 with HT and a Dell installed Nvidia FX5200 for graphics. It's only got one hard disk in it right now (a motherboard attached SATA) and it's divided into 4 Partitions (sda1 is NTFS, sda2 is SimplyMEPIS 6.0 Final using reiserfs, sda3 is a 1GB Linux Swap, sda4 is ext3 and has the latest SimplyMEPIS 6.5 RC on it.

I haven't tried this mepis gparted package version on any other PCs yet. But, the latest Ubuntu package for GParted in the Dapper repositories works with 6.0 Final or a hard disk install with RC1 on it for my PC (as long as you haven't updated from RC1 to later RCs and use the GParted package in the Ubuntu repositories versus the one in the MEPIS repositories).

Unfortunately, as soon as you update an RC1 or earlier version to the latest packages, neither the mepis or ubuntu version of Gparted will work any longer (I tried going back to the Ubuntu package to find out, but apparently too many other packages like parted, liparted and more are involved. I didn't try to go back to the Ubuntu versions of all of them. But, I suspect it's the new mepis package for liparted causing it (one I didn't try to go back with since it looked like it would try to remove too much other stuff related to the latest updates).

My solution... I use this version of GParted. It's worked on every PC I've tried it on, including a newer HP Pavillion that won't even boot SimplyMEPIS 6.x versions I've tried on it at all (although I did need to select 800x600 - 16 bit color from the GParted menus for one PC).

Download Links for GParted Live CD version 0.3.1-1

Jim C.

Hi,

Just got word from Warren that both will be in there. And both in the menu-system.

Regards, ko

Ko Bros

Download Links for GParted Live CD version 0.3.1-1

Same here. That old version of the GParted Live CD has been my workhorse partitioning tool for some time. The latest version of the GParted Live CD (v0.3.4-0) has been especially problematic.

Yeah. I saw that too.

With both being front-ends, I'm fairly certain that neither takes up appreciable space, but there might come a day when one or the other will have to go.

In that event, we'll still have cfdisk, I supose.

If nothing else, serving as a dire warning to others is not a bad thing to be.

I hate to cause any concern.

But, I just checked QTParted and it's doing something similar now in a hard disk install of RC3, too (although it does eventually finish loading, it hangs in "Getting devices" for approximatley 4 minutes before it finally finishes loading).

Both Gparted (the latest one from the Ubuntu Dapper repositories) and QTParted were loading without these kinds of symptoms on my PC prior to the updates from RC1 to RC2.

My guess is that one of the dependencies installed with the newer mepis package for GParted in RC2 also impacts QTParted (at least on my PC).

Jim C.

Just for the heck of it, I decided to wait longer for GParted to load (I'd already tried it multiple times with ho luck in the past, waiting for > 5 minutes each time).

Well.... with my PC, if you wait approximately 17 minutes, Gparted eventually loads (after being stuck on "scanning all devices" for that long).

As mentioned in my last post, it takes QTParted approximately 4 minutes to load.

These symptoms (extremely long load times) were not present prior to the updates from RC1 to RC2 on my PC.

Jim C.

You made me boot to CD... on my machine GParted loaded in about 6 seconds. I guess is machine dependent. When you talk about RC3 do you mean LiveCD or machine upgraded through pools? (it also might be something related to your program choices and settings if you talk about HD install)
--
Check out MEPIS Wiki: www.mepis.org/docs

I noticed the issue with a 6.5 RC2 Live CD first on March 14th.

Before upgrading my hard disk install from RC1 to RC2, I tried the GParted from the Ubuntu repositories and it worked fine.

However, when I updated the hard disk install from RC1 to RC2, the new GParted from the MEPIS repositories did not load correctly without getting stuck on "scanning all devices" (but, it was updated to a version from the Mepis repositories since it was added to the release).

When I tried to go back to the GParted version from the Ubuntu repositories, it no longer worked either (after the updates from RC1 to RC2 on the hard disk install).

I also tried going back to the ubuntu versions of some of the dependencies that were updated (but, I did not try removing latest mepis package for libparted1 since it would have removed too many other packages related to the RC2 updates). It could be something else entirely, but since I did not try to remove libparted1, that one is on my suspect list as the culprit (although I did try it with more than one version of it loaded with the older ubuntu and newer mepis GParted package)

GParted still does not work from the hard disk install (now RC3, no matter what version I've tried from the repositories (the latest ubuntu version that was working before the RC1 to RC2 updates, or the newer mepis version added to RC2).

I have not tried it from an RC3 Live CD. But, the problem exists from an RC2 Live CD and a hard disk install after updating from RC1 to RC2 (and now RC3).

So, it's unlikely that I'd see any difference from an RC3 Live CD (since EnigmaOne is seeing what appears to be the same problem from an RC3 Live CD, and I've seen it from both an RC2 Live CD and a Hard Disk install that has been upgraded to RC3).

I also experimented with the drives both mounted and unmounted before reporting the issue and also removed USB Devices (card reader, printer) to make sure they were not causing the problem. I saw no difference trying it a variety of ways (sticks on "scanning all devices" after updates from RC1 to RC2 on a hard disk install (and now updated to RC3), with the same symptoms trying to run it from an RC2 Live CD)

Jim C.

What the heck... just to make sure it's still present from a Live CD of RC3 (even though EnigmaOne is seeing from an RC3 Live CD and I'm seeing from an RC2 Live CD and a hard disk install that's now upgraded to RC3), I'm downloading 6.5 RC3 now and I'll give it a spin from a Live CD, too.

It's going to take a while (probably a good hour or so since I'm pulling it at around 200KB/Second right now).

Jim C.

I verified that it's still broken from a 6.5 RC3 Live CD (same as EnigmaOne is seeing). Gparted hangs on "Scanning all Devices".

Summary of my findings:

6.5 RC1
GParted worked prior to updates to RC2 (using the latest one from the ubuntu dapper repositories)

QTParted worked prior to updates to RC2

6.5 RC2
GParted hangs on "Scanning all Devices" from 6.5 RC2 Live CD or from hard disk install

QTParted hangs on "Getting Devices" from Hard disk install that was updated from RC1 to RC2 and then RC3.

6.5 RC3
GParted hangs on "Scanning all Devices" from a 6.5 RC3 Live CD

QTParted hangs on "Getting Devices" from a hard disk install (updated from RC1 to RC2 to RC3).

Note that both QTParted and GParted will eventually load (takes 16 or 17 minutes for GParted and about 4 minutes for QTParted). But, I don't trust them. For example, I see some very strange stuff in the partition list (/dev/mapper/sda1 showing unallocated, with a separate drive entry for /dev/sda that also shows sda1 as being NTFS).

Jim C.

Just for the heck of it, I went ahead and did a clean install of 6.5 RC1 to verify my earlier findings with GParted working.

After the clean install of 6.5 RC1, I used Synaptic, unchecked the mepis repositories to make sure it wasn't going to try and install the newer versions of some of the dependencies introduced in RC2.

Then, I installed gparted 0.1-0ubuntu10 using Synaptic and ran it from a console.

It started fine withing hanging the way the newer mepis packages for GParted in RC2 and RC3 do. But, I did get some errors like these when it was loading:

Error: Can't have a partition outside the disk!
debugreiserfs 3.6.19 (2003 www.namesys.com)

debugreiserfs: can not open reiserfs on "/dev/mapper/sda2p1": No such file or directory

I also see the same types of odd entries for /dev/mapper I see from an RC3 Live CD if you want to wait a long time (16+ Minutes) for it to finish "scanning all devices" and actually load the main menus from RC2 or RC3.

I then tried QTParted from a console and see errors with it, too. For example:

"No Implementation: Support for opening ntfs file systems is not implemented yet."

So, I would not trust either one of them for actually partitioning my drives from SimplyMEPIS 6.5 (RC1 through RC3). I'd have to go back and try earlier 6.5 Betas to see if they had issues, too. My guess is that these issues probably probably have something to do with ntfs-3g (only a guess, since I remember seeing problems trying to use these tools from one of the Knoppix Live CDs a while back after they started including ntfs-3g).

My solution:

Stick with the older 0.3.1-1 version of the GParted Live CD for partitioning.

Jim C.

I can't speak directly to your experiences, Jim; however, I can clarify what I ran into with the HP/gparted debacle that instigated this mention. (All 32-bit.)

My first attempt with gparted resulted in a hang, on device scan, that I finally killed, given your mention of time-frames, probably around the 15 minute mark; which might have been right before it would have self-resolved.

I also tried different versions of the gparted LiveCD with various and very unsatisfactory results--in a couple of instances I had to hit the reset switch.

RC-2 was no better.

Back to RC-3, and did get gparted to actually skip through device scanning in a few seconds; however, when it came to applying an NTFS partition resize operation, the machine turned into a block of ice for more than an hour.

The Beta-7 (somebody nipped-off with my RC-1 cd) qtparted loaded quickly, pulled partition information from the drive and allowed me to resize the NTFS partition and add a Reiser and swap.
That machine has been running all day today on both the windoze and SM Beta-7 --> RC-3 installations and, so I've been told, no anomalies are to be had from it.

I did a Beta-7/qtparted installation on another machine (this one, as a matter of fact: http://www.gabston-howell.org/tech/gateway.bro.shtml ) this morning, with stellar results. The machine has been fully updated to RC-3 packages, over the wire, and this version of qtparted works flawlessly, although I am dealing with an IDE drive on that particular piece of equipment.

I'm the first one to admit that this has very much the flavor of a moving target about it.

I have another machine to try this out on tomorrow...a duplicate of the original HP chassis...and I'll give that a shot with a USB key of the RC-3. That should give me the most current 32-bit package set to work with on these school machines.

I will try both from the shell to see what's coming back as far as error text goes.

If nothing else, serving as a dire warning to others is not a bad thing to be.

I got almost the exact same times from the hard disk install that was updated from RC1 to RC2 to RC3, and booting into a RC2 or RC3 Live CD. All were within a minute of each other (after between 16 and 17 minutes, Gparted will finish the "scanning all devices" and actually load showing partitions and menu options.

When I first reported it when RC2 was released, I assumed that it was not going to time out (trying multiple times, waiting > 5 minutes each time with no apparent disk activity). But, it does appear that it will eventually load (at least on my hardware), and it's relatively consistent in how long it takes. But, most users are not going to wait 16+ minutes, and I wouldn't trust it anyway, judging by the strange entries I'm seeing for partitions.

Jim C.

Most users will have my experience, GParted loads in 6-7 seconds on 3 different types of machines that I have around. The problem is specific to you machine (and EnigmaOne's) and I'd suggest you talk directly to Warren about it and provide detailed information about type of drivers and your set up.

--
Check out MEPIS Wiki: www.mepis.org/docs

Most users will have my experience, GParted loads in 6-7 seconds on 3 different types of machines that I have around. The problem is specific to you machine (and EnigmaOne's) and I'd suggest you talk directly to Warren about it and provide detailed information about type of drivers and your set up.

--
Check out MEPIS Wiki: www.mepis.org/docs

Same here. I have the same experience as Adrian on my AMD64 desktop with both 32 and 64 Mepis RC versions (including RC3) and on my HP-DV9055 laptop (which runs only 64bit versions, including RC3). Scanning is done in 6-7 seconds.
. Contact Warren with as much details about your system as possible.

Regards, Ko

Ko Bros

I sure hope you're right if Warren goes final with this thing as is.

My concern would be how many users have actually tested partitioning with newer RCs (and out of those, how many have combination including NTFS and other file system types like reiserfs and/or ext3 (if the combination even has anything to do with it).

I suspect that the hardware used in my desktop is pretty common. It's a Dell Dimension 8300 with an Intel 875P chipset with a 3.00ghz (Prescott) P4 with 1MB L2 Cache, HT, 800mhz FSB and 1GB of RAM.

Most everything is built into the motherboard, except that I've also got an Nvidia FX5200 graphics card in it (pre-installed by Dell). It's not a new box (introduced in 2003). Even the SATA drive in it was preinstalled by Dell.

I yanked all other drives (I've got external USB drives, card readers and more), just to make sure they were not causing issues. I'll forward lspci, lsusb, lshw,and lsmod to dev at mepis.org as soon as I get a chance (I've got some company right this minute).

Is anything else I should grab for them?

BTW, I just had to kill QTParted from a hard disk install (fresh install of rc1, updated to rc3). It's hanging on the device scan about every other time I try it, and I haven't even installed an Nvidia driver on the PC yet (or any other apps for that matter)..

Jim C.

Jim C.

Seems to me i saw a post from Warren about heeding the hand referring to that file system. I may be wrong but i thought he meant to not use it. And i am wondering if that is your problem. I may be missing the point here but its in my mind.

jim

You may want to be a bit more specific.. What do you mean by "that file system"? Do you mean ReisersFS? Did the post have anything to do with partitioning?

I've got 4 partitions on the only hard disk in it right now (a motherboard attached SATA). sda1 is NTFS with XP Pro on it, sda2 is ReiserFS with SimplyMEPIS 6.0 Final on it, sda3 is Linux Swap (approx. 1GB), sda4 is ext3 and used for testing newer betas and RCs).

I've also got a some external USB attached hard drives I use with this box. But, none are plugged in now to make sure that they are not causing any problems.

Jim C.

Yes i am referring to ReiserFS unfortunately i cant remember the particular thread. I will try and find it and post it when time allows i have some work to do soon.

jim

Great. If you find something about it, let us know. If I recall correctly, EnigmaOne has a preference for ReiserFS. So, I'm wondering if that could be a factor now (and EnigmaOne, please feel free to comment).

Jim C.

OK, I think this is some progress if we can tie the problem to ReiserFS, now it would be useful if you could test on the same machine but with a drive that doesn't have ReiserFS...
--
Check out MEPIS Wiki: www.mepis.org/docs

If it ties in with Reiserfs, then it will be a combination of the specific hardware + reiserfs.
My AMD64 desktop has ONLY reiserfs partitions (since I bought it 2 years ago) for Mepis (32 + 64 bit) and Gparted scans fast on that machine. So, the problem at hand does not tie in directly with reiserfs.

Regards, Ko

Ko Bros

I don't have another SATA drive handy. But, I've got some IDE drives in PCs that are sitting around.

I was going to try the latest RC on some of the other PCs later. But, it may be time better spent for me to yank a drive out of one of them and try it in this same Dell box to see if it's drive (or partition type) related, or something unique to this box causing it (which I suspect is very different from the ones EnigmaOne is seeing problems with).

I'm a bit busy right this minute. But, I'll find some time later this evening to open some cases and see if it's drive or file system type specific (I'll try an IDE drive from another PC a few different ways in it).

Jim C.

I probably will, until I get the time to do a head-to-head between Reiser and JFS, XFS, etc. to see which is best for my uses. (Might be right-around the time I start striping at the workstation level.) At this point, Reiser beat-out ext3 a number of years ago, and has been a solid performer ever-since.

Specific to that point, Jim, where I have had the problem has been at the point where I am attempting to access and resize a single NTFS partition on the target drive.

Now, unless the operator_mind_reading package (I hear it's still in alpha) has been installed without my knowledge, I don't think that gparted, qtparted, or even parted knows what I have planned for the unallocated space that is to be created on the drive as a result of halving the size of the NTFS partition.

It would be kind of cool if it did, though.

At this point, it's happening (or has at least once) on partition table-less IDE drives (factory new state), as well as drives possessing a single vfat/fat32 part; and I'm going to be running into my archival drives pretty soon, in testing all of this out.

If nothing else, serving as a dire warning to others is not a bad thing to be.

So, I'm wondering if that could be a factor now...

Specific to that point, Jim, where I have had the problem has been at the point where I am attempting to access and resize a single NTFS partition on the target drive.

Now, unless the operator_mind_reading package (I hear it's still in alpha) has been installed without my knowledge, I don't think that gparted, qtparted, or even parted knows what I have planned for the unallocated space that is to be created on the drive as a result of halving the size of the NTFS partition.

It would be kind of cool if it did, though. Eye-wink

Thats funny ! I got a big laugh out of that alpha
operator_mind_reading package. You're an imaginative little rascal aren't you. (still laughing)

On a more serious note i'll be dipped if i can find that thread it may be of no help anyway. I should have reread the beginning of this thread to refresh the fact you were running from cd, but still don't know if everybody is was running from same. Hope it didn't waste too mutch time.

jim

Whatever is causing the conflict appears to be chipset (or maybe bios) related (at least on my hardware).

I pulled my wireless, floppy, sata drive, swapped my CD/DVD Drive, tried two different IDE drives, tried a variety of bios options, and the symptoms remain the same.

GParted hangs on scanning devices with 6.5 RC2 or RC3 on this Dell Dimension 8300 using an Intel 875P chipset.

Jim C.