Hi André,

Do you mind re-doing the attempted install, and if you hit this problem again:


insert a second USB key

switch to tty2 with ctrl+alt+F2 

I know you know, but writing it for others who read this ;-) 

type: "bug" 
(without the "")

and attach report.bug that is written to the USB-key to this report.

if needed, compress the file first.

Thanks!

Keywords: (none) => NEEDINFO
CC: (none) => marja11, thierry.vignaud
Source RPM: (none) => drakx-installer-stage2

Hi Marja,
It was my first try with RC. I formatted swap and the installation went on. I (as asked) re-did the installation, but the bug didn't show again. 
BUT, RC doesn't work on my laptop. The first install took more than 2 hours, and after reboot it was very, very slow. For example, 1 mn to get the menu, and another 1 mn to get the submenu. Impossible to open Writer, it starts and collapse after 2 mn and half. Switching from a console to another one takes several mn, and after enter the login, the password is never asked or needs several mn.
I did a second install with the same result.
I did a third install on another partition (same laptop). It lasts only an hour. After the first reboot, RC was very slow again. After a second reboot, RC seems to work fine, but there was freezes and the HD always running at the max level. The freezes last about 30 sec and everything seems to work again, until the next freeze. I have also many error messages during the first update after the repos are configurated, for example (for many rpm):
"There was a problem during the installation
Can't move file /var/cache/urpmi/partial/lib64xvidcore4-1.3.2-5.mga4.tainted.x86_64.rpm to var/cache/urpmi/rpms/lib64xvidcore4-1.3.2-5.mga4.tainted.x86_64.rpm"
or
"A fatal error occured: unable to write config file [/etc/urpmi/urpmi.cfg]"
So, the update is impossible.
Either RC has big problems or my 6 years old laptop is dying, I will install Mageia 3 to make it clear.

Bad news for Mageia 4 RC.
I did an install of Mageia 3 x86_64 DVD in the same partitions of the same computer using the same method with the same USB stick.
Installation lasted less than 30 mn. No slowness, no freeze and no error message.

(In reply to André DESMOTTES from comment #3)
> Bad news for Mageia 4 RC.
> I did an install of Mageia 3 x86_64 DVD in the same partitions of the same
> computer using the same method with the same USB stick.
> Installation lasted less than 30 mn. No slowness, no freeze and no error
> message.

I should have replied to comment 2 before you started installing Mageia 3 :'-(

You probably didn't make a copy of /root/drakx/report.bug.xz before you installed Mga 3 again, did you?

If you do have the report.bug.xz of the Mageia4RC install, then please attach it.
If you don't have it, then I hope you won't mind redoing the install... /o\

Created attachment 4835 [details]
report.bug.xz

Comment on attachment 4835 [details]
report.bug.xz

I understood you asked me to save this file if the bug shew again whereas it didn't.
But I did a third install on another partition I still have, here it is:

I see no errors in both or you log file (and btw the summary looks to not match with what you say)

There is something odd in the log:

ERROR: Filesystem check failed!
ERROR: 1285 clusters are referenced multiple times.
NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
The usage of the /f parameter is very IMPORTANT! No modification was
and will be made to NTFS by this software until it gets repaired

The two or three things that took most time were:

* Install took: 0:49:58
* step "installPackages" took: 0:50:05
* step "setRootPassword_addUser" took: 0:20:22

Ouch!!

Now I see I misread:

"I did a third install on another partition (same laptop). It lasts only an hour. "

I suppose that is the install of which you attached the bug.report.xz?

I had mistakenly assumed that that one had taken over 2 hours, too, sorry about that..... if that is the install the bug.report.xz refers to, then it was wrong of me to pick the long install time as issue for this bug report.

Bug reports should preferably be about only one issue. There are no logs for the original issue ("swapon (sda7) failed: input/output error"), so it is impossible to look into that.

IIUC, there are no logs about the long install time issue, either, if so: impossible to look into that, too.

So what is left? The little freezes after reboot, the update errors and the HD always at max. speed, correct?

I could ask you to attach the related part(s) of journalctl -a .... but if you'd like to help testing pre-final isos, it is maybe better to try again with a (just released) 2nd round final iso

WDYT?

CC: (none) => eeeemail

I think it's better to forgot what I have done so far, here are new tests on a cleaner basis.
As I had suspicions about my hardware, I totally erased all the disk partitions and created 7 new ones, all formatted ext4. I also used memtest86+ during 2 hours, all seems fine.
On sda1 (/) and sda2 (/home) I installed mga3 DVD 64b KDE. It lasted 25 min.
On sda5 (/) and sda6 (/hoée) I installed mga4RC DVD 64b KDE. It lasted 45 min.
sda 7 for swap
sda 8 and sda 9 unused (for tests).

For each installation, I did the same actions:
Sources configuration including tainted (MCC)
System update (MCC)
Installation of flash player and a chess game
Dolphin configuration
NFS setting
sda 8 and sda 9 mounting  in /mnt
Modification of partitions and formatting on 2 USB sticks using a console (They weren't detected in MCC either with mga3 or 4)
I watched web videos and read news with firefox
I played chess (and lost)

With mga everything went fine and smoothly. With mga4, there was slowness's and three freezes, two in the MCC (downloading) and one in Firefox. Each freeze lasts about 20 to 30 seconds and during this time mouse and keyboard are unusable. No console, no alt ctrl Fn. The disk is fully working and suddenly, everything is OK again. All the clicks during the freeze are executed.

Some times in sec mga3 / mga4
Boot from power on to the end of the welcome music (mgaWelcome disabled): 56 / 65 (same time for the connection, about 4 sec)
Opening Writer: 11/ 5
Shutdown: 15 / 10

I go on with observation.

can you run 
journalctl -f 2>&1 | tee journalctl-f.txt
as *root* in a terminal next to the window(s) in which you are working, and look whether funny things happen during or right  before those little freezes?

And then please attach journalctl-f.txt after you've seen those freezes, (preferably both for FF and for MCC) and tell which times correspond with them?

I hope the output gives a clue about what is going on :-)

Summary: Installing 4RC takes 4 times as long as installing Mageia 3 on the same partitions => Short 20~30 second freezes after 4RC install

Created attachment 4864 [details]
asked file

Freeze at 20:14:31

Created attachment 4865 [details]
asked file

freeze at 13:29:55 installing package at-spi2-atk, it lasted 2 min

Created attachment 4866 [details]
asked file

freeze at 14:06 uninstalling cinnamon, the progressing bar stayed about 3 min without any move. It wasn't  really a freeze because I could access to the menu and open writer for example, even if it was very long.

and when you have top running in a 2nd screen, which program/process is "at the top" during those little freezes?

s/screen/window/

It is MCC

Hello, i have the same problem. 

After a new complete intallation of Mageia 4 (Delete Mageia 3 and install Mageia 4 ) . I installed my software and after few hours,  one freeze , i couldn't switch with command and must restart the computer. 

And second times etc.. For a total of 8 times. No special actions before the freeze (surfing net, read pdf , open Dolphin ..) 

I have Mageia 4 KDE . 

I switch again with Mageia 3. 

Thanks for your attention, and sorry for my bad english. 

FaithFully 

skulls

CC: (none) => l_italiano_del_sud

hello,

After many tests I am sure now I am having problems with the HDD. New bad blocks found every week by e2fsck. I swapped Mageia 3 and Mageia 4 and now it is Mageia 3 that is having problems. Mageia 4 is fine.

What is strange is that smartctl never found a reallocated sector.

Closing as a HW bug then

Status: NEW => RESOLVED
Resolution: (none) => INVALID