Classic ISOs either loading stage 1 for installation or loading the Rescue console takes an unusually long time. It's almost as if it's using USB 1 rather than USB 2 (just guessing!) On my system, from hitting enter to 'Install Mageia 4' at the menu to stage 1 appearing takes over a minute. Similar for Rescue. The initial kernel load also seems slower than normal, it then sits with it showing 100% for some time before stage 1 starts to appear. Reproducible: Steps to Reproduce:
CC: (none) => davidwhodgins, dvgevers, marja11, tmb
Same thing here using DVD32 on virtualbox. It seems to deal with stage1
I'll take a look, but with latest RC DVD ISO, the rescue system starts nice and fast for me with the 64bit ISO. Is it only 32 bit that's affected?
CC: (none) => mageia
Speaking with Colin: 23:04 < coling> ennael, try hitting esc, going into text mode, and then running whatever action you want (linux or rescue I guess) but pass rd.break=initqueue too. 23:05 < coling> ennael, this should drop you to a shell. At each stage you can type "exit" (or ctl+d) and then perhaps it'll be apparent as to which part in the process things become slow. So did I. I get initqueue:/# [ 21.411122] piix4_smbus 0000:00:07.0: SMBus base address unintialized - upgrade BIOS or use force_addr=0xaddr I found this on vbox web site: http://fintastical.blogspot.fr/2010/11/virtualbox-piix4smbus-error.html
Using xdriver=vesa for install seems to improve things a little bit
Ah, sorry, I wasn't too bright last night: I've only looked at how fast reaching the boot menu went, because that's the part that has been a problem here on (at least) a 32bits system. Here the part from boot menu to stage 1 did /not/ take longer than expected, but I haven't yet tried the newest traditional DVDs.
This sort of confirms to me the problem lies earlier in the process, it takes around 30 seconds from typing linux rd.break=initqueue at the boot: prompt to reach the console. This is classic dvd 64 on real iron btw.
I did some tests again this morning... and all is working ok... I did not change anything. I suspect something related to vbox
any feedback using the last RC isos?
There was no noticeable change, but so far I only performed the upgrade.
Definitely usb1. Using livedvd it's taking forever just to load the kernel.
after the initial slowness the live mode itself is fairly responsive. I think the problem lies somewhere with bios/syslinux
I have noticed something similar with booting from the CD itself. It has continued from at least the Beta or earlier. I thought that the CD must have been rearranged somehow so that the whole CD had to be read before anything happened, but that is more a description of the effect than an unintelligent guess.
CC: (none) => laidlaws
Is this still an issue? Perhaps it's "solved" with the new syslinux in the rebuilt ISOs?
Haven't tried USB with Mga4. Should have kept out of this one.
CC: (none) => thierry.vignaudSource RPM: (none) => syslinux
(In reply to Doug Laidlaw from comment #14) > Haven't tried USB with Mga4. Should have kept out of this one. And I will get out now. My Comment 12 is probably not relevant.
CC: laidlaws => (none)
Source RPM: syslinux => syslinux, BIOS
Can you please try using Mageia 5?
I fear that won't change anything. Usually linux reading USB is quite fast. What is not is right before, slow BIOS reading (due to it emulating floppy on USB or whatever)
I just noticed this bug, so I'm a little late to the party, but I've been doing some installs from boot.iso recently and I've noticed that after you hit ENTER to the initial syslinux screen to indicate "install", it takes way longer than it ever did to hit the stage 1 curses screen that says "detecting USB devices". I'm talking 30 seconds to a minute or more. Once you hit USB detection, everything moves along smoothly. So whatever is going on here may have nothing to do with booting from USB. I'd try booting from boot.iso and see if you experience the same delay.
CC: (none) => ftg
Component: Installer => Release (media or process)CC: (none) => sysadmin-bugs
CC: dvgevers => (none)