Created attachment 2132 [details]
systemd-analyse blame output

Created attachment 2133 [details]
systemd-analyze plot output

I think adding
DKMS_ONBOOT=no
HARDDRAKE_ONBOOT=no
to /etc/sysconfig/system for the live cd images would help.

As expected, this bug affects the kde live cd too.

This looks like a bug I just fixed relating to harddrake (everytime) and how it starts numlock service. Detailed in #4772

I've confirmed the first boot after install that used to have this problem is now fixed.

So while the DKMS_ONBOOT thing on a livecd might be sensible to disable, It shouldn't be needed.

I'll mark as fixed for now, but please reopen if it's not fixed after a new drakxtools is pushed.

Status: NEW => RESOLVED
CC: (none) => mageia
Resolution: (none) => FIXED

Still a problem with todays live cd iso images.

From systemd-analyze blame ...
177370ms mandriva-everytime.service
 
This is on real i586 hardware, booting from a usb stick.
 
When booting a fully up-to-date cauldron install from disk,
3490ms mandriva-everytime.service
 
That's a difference of almost 3 minutes.

Checking with urpmi --auto-select, the only updates missing
from the live cd are ...
  libldap2.4_2                   2.4.29       2.mga2        i586
  openldap                       2.4.29       2.mga2        i586
  rpm-helper                     0.24.10      1.mga2        noarch
  sound-scripts                  0.62         7.mga2        noarch
 
none of which I expect will have any impact on this.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

It seems to relate to the timeout when starting/stopping services, but I'm not sure why this could be.

The important package is: drakxtools-backend-14.16-1.mga2

It's the one that should ensure --no-block mode is passed when starting services.

Can you possibly boot with systemd.log_level=debug systemd.log_target=console to see if there are any messages that give any clues?

OK, so I've tried quickly on my lunch break.

So far it seems that simply removing the "splash quiet" options from the kernel are enough to make it boot quickly.

I've only tested in VirtualBox but the little CD icon was continually active to show it was reading data from it constantly.

This might help workout exactly where the problem is.

And it seems it's just the splash option that's causing the problem. Removing just it also gets a fairly speedy boot for me.

Can you confirm this at your end on a real setup + USB? I guess some info can be gained from doing "systemd.log_level=debug systemd.log_target=kmsg" but leaving splash and quiet options set. Hopefully then /var/log/dmesg and dmesg output combined will be sufficient to give some clues.

Actually, this is maybe a bit of a red herring.

With the "systemd.log_level=debug systemd.log_target=kmsg" I don't see anything too crazy. There is a small gap between 49s and 74s when nothing happens so I think this is pretty much everytime doing it's thing.

When I check the blame, I get:
 37987ms mandriva-everytime.service

So that all looks good. I'll try again without any options, but I suspect there isn't actually a problem for me under VirtualBox.

Yup, booting again and it does it in 38s. So I guess I cannot see this problem.

Note, when you say:
> When booting a fully up-to-date cauldron install from disk,
> 3490ms mandriva-everytime.service

This is not a fair comparison, as this is what it does every boot, not first boot. Your first boot will always be slower as it does a lot more the very first time it is run.

I think 40s on a live CD isn't too crazy here.

So I'm not sure how else I can help debug if i cannot reproduce the problem.

FWIW, I used the Europe GNOME 64 bit iso.

Created attachment 2153 [details]
/var/log/dmesg from the livecd boot (gnome i586)

This shows dmesg output from the first 54 seconds of boot

Created attachment 2154 [details]
Output of dmesg command

Output from dmesg command showing dmesg output from second 163 on. Note
267.512874] systemd[1]: Job graphical.target/start finished, result=done

I can't see anything specific in there.

Just tried putting the iso on to a USB and booted it on real h/w here. I now have:

 19033ms mandriva-everytime.service

So on 20s on real h/w. Again, not seeing the slowdown here :s

I've not tried the i586 or KDE versions yet, but which version did you use specifically (I know it was i586, but not sure which flavour)

Just tried the i586 KDE iso and again only 19s.... Hard to reproduce this one... might be hardware dependent?

-rw-r--r-- 1 dave root  700448768 May  1 07:58 Mageia-2-rc-LiveCD-GNOME-Europe1-Americas-i586-CD.iso
-rw-r--r-- 1 dave root  706740224 May  1 06:15 Mageia-2-rc-LiveCD-KDE4-Europe1-Americas-i586-CD.iso

ping ? what shall we do with this one ?

CC: (none) => ennael1

Maybe let it be a open for post-rc to see if someone else hits it...

Dave, can you give exsct hw specs, and I'll see if I can find something like it at work

Created attachment 2190 [details]
Output of lshw

Final RC is out. I presume you can still reproduce Dave? Hopefully TMB can find similar h/w.

Yes.  Not only are the live cd's slow to boot, but an upgrade done using
the live cd is slow to boot, as it appears to be using a non-hostonly
initrd in the upgraded installation.

Bug 5790 is about the upgrade using live problems.

This bug is still in the final live cd (both gnome and kde).

Almost 6 minutes from grub to asking for language.

If you do any in-place upgrade (i.e. via urpmi) then it will use a non-hostonly initrd by design.

This is because we cannot query udev properly when booted into mga1 as things like lvm etc are started too early for the necessary metadata to get into the udev database.

So the non-hostonly initrd is intentional.

I've personally no idea how a live install+upgrade works... it's likely some kind of chroot I guess? It likely could be made to use a hostonly initrd but it might need some tweaks to the drakx code to make it do the necessary symlinks etc. for the udev querying and the "fake dracut initrd" stuff to work.

OK, so the actual slowness part of this is obviously some kind of h/w thing that is only triggered in some circumstances. We need to narrow that down, but I guess it's kinda hard to work out what to do. We'd really need to have a kernel-param option to disable various harddrake things to see which one of them is causing problems.

@colin is this gonna happen now? or is this for after release?

or is this option just needed for some testing?

CC: (none) => alien

I personally don't think I'll have time :s And the option would just be needed to work out which bit of harddrake is contributing to this specific slowdown. As it does several tasks, narrowing down which one is to blame is needed. As I've not been able to reproduce on two different physical machines and several VMs, I expect it's related to h/w in some capacity.

so, in other words, we should link this one to mga3 tracker?

(In reply to comment #24)
> If you do any in-place upgrade (i.e. via urpmi) then it will use a non-hostonly
> initrd by design.

Yes, but running dracut -f after booting into the system created by an
install from the live cd is leaving things in the initrd, that are only
needed in the live cd boot.

See https://bugs.mageia.org/show_bug.cgi?id=5790#c6

It also leaves in

(In reply to comment #28)
> so, in other words, we should link this one to mga3 tracker?

It should be requested as an update after release.

While it is quite annoying for anyone with older hardware like
mine, I don't consider this to be a release blocker.

Any changes to dracut at this point, to get it to not include
the dmraid, non-hostonly-init-lvm, mgalive-root modules, etc.,
when running in an installed system, would be risky at this
late stage.

It will have to be fixed by an update after release.

@colin , do you agree? so we can make this high instead of release_blocker?

Yeah that seems to be a good compromise. I agree it's annoying but it's also a tricky one it seems.

Reducing priority as per previous comment.

Priority: release_blocker => High

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Closing, because no one seems to have hit this bug in Mageia 2 final

Please reopen if I'm wrong

Status: REOPENED => RESOLVED
CC: (none) => marja11
Resolution: (none) => OLD