1

Topic: Urgent help needed: Return to X server

Hi, it's 5 am here and I just woke up from my laptop beeping rather loudly. I had left it doing a resizing operation and it was still chugging along so I hit ctrl+alt+F1 to see if something was happening.

I now have a gparted ~ # prompt and I can't return to graphic mode. There's still some lag so I hope it hasn't stopped the whole process. What should I do? I only had one spare backup drive and I had already filled it up with data from one of the partitions I'm deleting. I'm VERY scared right now.

Help me, please.

2

Re: Urgent help needed: Return to X server

Nevermind,

Tip: NEVER press Alt Gr when using the live media. It screws the whole keyboard.

3

Re: Urgent help needed: Return to X server

Hi!

I never noticed this keyboard screwing - and I tend to switch between the X server and text consoles quite often (a running top is usually a good idea, and having a look into the kernel log via dmesg every now and then can be very helpful, too). So it dioes not seem to be a general problem!
To track the problem down, a bit more information would be helpful - which GParted version are you using, in which way is the keyboard screwed (and I'm sure the developers will come up with additional questions)?

4 (edited by Crushyerbones 2008-09-28 15:18:36)

Re: Urgent help needed: Return to X server

I'm afraid I can't check right now but it seems my problem is that alt gr is a toggle like caps-lock.

By the way, is it normal for it to take more than 12h to resize a 85GB partition into a ~160GB one? When I started at around midnight it mentioned it would take about 6hours. It's now 2pm and the estimates say 03:08:45. There is terrible lag and it seems each second estimated is about 5 seconds real time.

5

Re: Urgent help needed: Return to X server

Hi!

The lag and poor performance could both be a hint towards a heavily loaded CPU. Since nothjing besides GParted is running, this wold mean that disk I/O creates this hich CPU load - which in tuirn means that the system has fallen back to PIO mode for IDE transfers.
This can have several reasons:
- the IDE controller reports its own DMA capabilities (and those of your hard drives) incorrectly;
- the IDE driver used for your chipset is buggy or unable to do DMA;
- disk I/O errors have occurred (due to a bad IDE cable or a controller or hard drive failure) - in this case, the system dropc back to PIO since this is the most reliable transfer method.

I think it is best not to disturb the running process (if it is interrupted for some reason, the result is likely to be 100% data loss), so wait until GParted gets the job done.
Afterwards, go back to a text console and issue the following commands:

hdparm -i /dev/hda
dmesg | grep hda

(replace hda with the proper device name for your hard drive). The first one gives you (among other data) the drive's transfer capabilities, including the currently set transfer mode; the second extract from the kernel log buffer all messages about the hard drive you were working on and prints them on the screen. If you had IDE I/O errors, these should be displayed then.

6

Re: Urgent help needed: Return to X server

Ok, I will try to remember. Though at this rate I might forget by then xD

7

Re: Urgent help needed: Return to X server

I just noticed, altough CPU consumption is high the Laptop is not heating as it usualy does when using a normal OS, is gparted single-threaded?