also valid Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD

What is the proper way to get the language  + timezone + keyboard choice screens if you can only start sddm after starting Live mode in text mode?

Hardware: i586 => x86_64

Confirmed for Mageia-6-dev1-LiveDVD-PLASMA5-x86_64-DVD

CC: (none) => yves.brungard_mageia

bug 17842 might be a duplicate or related

*** Bug 17842 has been marked as a duplicate of this bug. ***

CC: (none) => westel

Is this bug still valid for the released 6dev1 isos?

Keywords: (none) => 6dev1, NEEDINFO
Whiteboard: 6dev1 => (none)

On an installation from DVD:
Now, when the screen is displayed, the English flag is present. When I start to type the user name, it switch the the French one. The language defined for the user is thus available.
Are new Live ISOs available?

(In reply to Marja van Waes from comment #5)
> Is this bug still valid for the released 6dev1 isos?

still valid for 

Mageia-6-sta1-LiveDVD-GNOME-i586-DVD.iso
DATE.txt:  Sun May 22 15:00:00 CEST 2016

(as per e-mail:)

It's alive....


What is _NOT_ fixed yet :/
   * no language / region / keyboard questions at boot, they boot/login
in english
   * no finish-install after install to convert live user to wanted user
or setting any passwords

I posted this on qa-discuss, but don't know if Thomas saw it:

Thomas Backlund wrote:
> TODO:
> Still only boot in english as I havent had time/energy to
> fixing/converting/... xsetup scripts that both gdm and sddm ignores
> nowdays...
> If someone wants to help out, feel free...
>
> And simply caling the xsetup scripts or draklive-install /
> finish-install from
> /etc/X11/gdm/PreSession/Default
...
> does not work...

I had a look at this. The reason is that the X server is not running when the PreSession script is run (and the Init script is not run at all). Relevant bug reports are

https://bugzilla.gnome.org/show_bug.cgi?id=748297

and

https://bugzilla.gnome.org/show_bug.cgi?id=751602

I can't immediately see a way to solve this, unless you start up a temporary X session for the draklive-install / finish-install.

CC: (none) => mageia

Created attachment 7999 [details]
Error log from matchbox window manager

Further to my comment above, I've tried booting the Live DVD to run level 3, then using xinit or startx to run the finish-install script. If I simply run

  xinit /usr/sbin/finish-install

then the first dialogue box is displayed in the top left hand corner of the display, but there's no way to interact with it (no response to keyboard or mouse). Running

  xinit /etc/X11/xdm/Xsetup_0

gives me a working mouse cursor but an otherwise blank screen. Modifying

  /etc/X11/xsetup.d/30-start-matchbox.xsetup

to redirect the output of matchbox-wm to a log file shows a number of errors, as per the attached log file.

Trying the same procedure with a Mageia 5 Live GNOME DVD gives no errors, and lets me complete the finish-install process.

Created attachment 8026 [details]
Patch to enable finish-install to run when using gdm

Removing the line

  any::set_wm_hints_if_needed($in);

from /usr/sbin/finish-install allows the dialogues to be displayed by matchbox, although they are then displayed in full-screen mode. A regression in gtk3?

Making the attached patch to /etc/X11/prefdm enables finish-install to be run when using the GNOME live DVD. There is a long delay (~40 seconds) between finish-install starting and the first dialogue being displayed, but that may be unrelated.

ok, so I tried the patch and removed the line referenced in comment 10 (and removed the "GNOME" check so it would trigger under plasma too), and it didnt work at all on GDM/Gnome... the Gnome isos just booted into live mode...

But on Plasma isos it did trigger and run in full-screen mode ...

But on re-boot after install it would not trigger at all on either isos, so it would not change root pw, add new username/password and change that....

and we still need to trigger draklive-install if they choose install on iso boot

So for now I tested a xdg autostart setup that works for all other parts than final usermod "live" -> "selected user name"..

But I also hit the same ~30-40 sec delay before finish-install actually starts...


So more tinkering needed...

(In reply to Thomas Backlund from comment #11)
> ok, so I tried the patch and removed the line referenced in comment 10 (and
> removed the "GNOME" check so it would trigger under plasma too), and it
> didnt work at all on GDM/Gnome... the Gnome isos just booted into live
> mode...

Could you try inserting

  /bin/plymouth quit

before the call to xinit. I didn't need this when testing on real H/W, but have found it necessary when running in VirtualBox.

If this works, I'll investigate what's happening post install.

I get the same long delay before finish-install actually starts. But it starts immediately if you manually start the prefdm service after booting to run level 3, so I guess it's some other service that's slow to come up.

AH, yeah... good point ... I forgot about testing without plymouth...

But that should maybe easy to test by removing vga=^ splash quiet to prevent it from activating...

Hm, come to think of it... could it be waiting for network service I've disabled ?
(Since I enable NetworkManager instead)

And iirc it didn't start any faster when triggering it in live mode after the system had been up for a while... I guess I need to read through finish-install and if that does not help, try to strace it...

You may also look at "systemd-analyze blame" output

Yeah, but running under xdg autostart is not caught by systed-analyze...

But looking on logs I see:
Jun 27 16:30:00 localhost finish-install.desktop[1733]: Too late to run INIT block at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Glib/Object/Introspection.pm line 257.
Jun 27 16:30:01 localhost org.gnome.Shell.desktop[1560]: Window manager warning: "XF86Help" is not a valid accelerator
Jun 27 16:30:01 localhost finish-install.desktop[1733]: Subroutine Gtk3::main redefined at /usr/lib/perl5/vendor_perl/5.22.2/Gtk3.pm line 525.
Jun 27 16:30:01 localhost gnome-shell[1560]: GNOME Shell started at Mon Jun 27 2016 16:29:17 GMT-0400 (EDT)
Jun 27 16:30:02 localhost mageia-mgaonline.desktop[1753]: /home/live/.MgaOnline/mgaonline should be set to TRUE: please use --force or -f option to launch applet
Jun 27 16:30:02 localhost mgaapplet[1753]: ### Program is exiting ###
Jun 27 16:30:27 localhost finish-install.desktop[1733]: Ignore the following Glib::Object::Introspection & Gtk3 warnings


the first 16:30:00 time is when xdg autostart triggers finish-install
the last 16:30:27 time is when I press enter on first question as fast as possible when the windows pops up...


so 27 seconds to start on a running live system...

Is there a way to enable debug on perl so it would be more verbose of vhat it's doing or do I need to add log() stuff at every place I want checked ?

Using strace suggested the delay was caused by building the fontconfig cache. The following experiment seems to confirm it:

 - Boot to run level 3 and log in as root
 - xinit /etc/X11/xdm/Xsetup_0
     - approx 25 secs until language selection window is displayed
 - Kill xserver
 - xinit /etc/X11/xdm/Xsetup_0
     - less than 1 sec until language selection window is displayed
 - Kill xserver
 - \rm /var/cache/fontconfig/*
 - xinit /etc/X11/xdm/Xsetup_0
     - approx 25 secs until language selection window is displayed

And the font that is causing the long delay is

  /usr/share/fonts/OTF/source-han/SourceHanSans.ttc

Deleting that file reduces the delay to about 2 seconds.

Nice find :)

I didn't even think about that :/

Seeing as:
meta-task/SOURCES/rpmsrate-raw:    LOCALES"zh" || LOCALES"ja" || LOCALES"ko" fonts-otf-source-han

I cant really drop that one from the isos, but I should be able to pre-generate font cache during iso build...

I will try that tomorrow...

Or sort of now :)

running fc-cache once at init 3 and the going init 5 gives pretty much instant startup of finish-install as soon as desktop is available

(In reply to Thomas Backlund from comment #18)
> I cant really drop that one from the isos, but I should be able to
> pre-generate font cache during iso build...

Yes, deleting it was just for diagnosis, not a realistic solution.

Looks like the slow caching of the source-hans-sans font is a known problem with no good resolution:

  https://github.com/adobe-fonts/source-han-sans/issues/85

Running fc-cache early will help, but people with older hardware will thank you if you pre-generate the cache!

Getting back on topic for this bug, I'll try to look at why my original patch didn't work post install this evening.

So the fc-cache problem is problematic as we already create /var/cache/fontconfig (and have done since mdk/v days) at install time using filetriggers.

so regenerating them at end of live image creation changes nothing...

And generating a /home/live/.fontconfig/ only creates a identic copy of /var/cache/fontconfig.

but for some reason the fc-cache decides it needs to regenerate cache on live boot, and the contents of the files are not exactly the same... so some weird interaction is going on...

But since we only have one problematic font I will play some tricks with draklive to work around it and we'll live with the 2s delay of the rest...

Cache might be rebuilt due to timezone differences? E.g. filesystem created in one timezone, then fonts in another.

Ok, found a other problematic fonts... the google-noto-* have the same issue...


@Martin:
And it it plymouth that messed up both initial installer and the trigger on reboot.

disabling plymouth gives the installer time to start as it should...

Created attachment 8085 [details]
Revised patch to enable xsetup scripts to run before DM starts

I've modified my patch for the prefdm script to remove the check for GDM and to always quit plymouth before running the Xsetup script. I've tested this both in VirtualBox (both normal and EFI boot) and on real H/W (two machines, both UEFI). I've tested boot to live desktop, install from live desktop, boot to live installer, and boot installed system, and get the expected behaviour in each case.

I tested this on the June 27th Mageia-6-sta1-LiveDVD-GNOME-x86_64-DVD ISO, with the following additional changes:

1) Deleted /etc/xdg/autostart/finish-install.desktop

2) Commented out "call('gnome-reboot')" in /sbin/finish-install

3) Restored the ./usr/bin/pkexec in /etc/X11/xsetup.d/60draklive-install.xsetup (not sure if this was actually needed - the real problem was the next item)

4) Commented out any::set_wm_hints_if_needed in /sbin/draklive-install

Attachment 8026 is obsolete: 0 => 1

We crossed!

s#./usr/bin/pkexec#/usr/bin/pkexec# in the above.

yeah, pkexec is not needed in /etc/X11/xsetup.d/60draklive-install.xsetup

since we start xinit as root we have all privilegies needed when we trigger finish-install

It's a left-over since I tested triggering finish-install xsetup as live user

I will add the fixes in comment 24 and re-spin all isos...

Thanks a lot for your help

A workaround that allows us to restore the call to any::set_wm_hints_if_needed() (and hence no longer run in full-screen mode) is to build drakx-matchbox-window-manager with the --disable-composite option. I've tested this both in VirtualBox and on real hardware, and both finish-install and draklive-install (run from the boot menu) display properly.

(In reply to Martin Whitaker from comment #27)
> A workaround that allows us to restore the call to
> any::set_wm_hints_if_needed() (and hence no longer run in full-screen mode)
> is to build drakx-matchbox-window-manager with the --disable-composite
> option. I've tested this both in VirtualBox and on real hardware, and both
> finish-install and draklive-install (run from the boot menu) display
> properly.

@Thierry,

do you see any potential breakages elsewhere of doing this ?

We don't use matchbox anymore for installer so you can do whatever you want for draklive.
But why not use mutter like we now do in installer?
matchbox is no more maintained for years...
I didn't even remember that finish-install was using it...

Yeah, I'll take mutter for a spin...

If it works we can drop matchbox...

Actually that wont work as it means pulling in gnome stuff on an already bloated plasma iso...

So back to matchbox for now

Heh, it only added some 2.6M to the iso so I can live with it,
I'll teach draklive-install to remove int from final install like we do for draklive-install itself

ok, so it's heavier to start and not as nice on plasma as on gnome...

I will play some more with it, but will also fix up the matchbox build so we have options...

(In reply to Thomas Backlund from comment #31)
(In reply to Thomas Backlund from comment #32)
> Heh, it only added some 2.6M to the iso so I can live with it,

Yep, most deps are already pulled by other programs anyway (gtk+3, ...)

What's more, we rely on a WM that wasn't updated since 2007.
Though http://git.yoctoproject.org/cgit/cgit.cgi/matchbox-window-manager/ seems to point to a minor release a couple weeks (1.2 -> 1.2.1)

Well, I dont mind reying on "old" as long it does not have critical bugs,
and yeah :) ... I just noticed the same 1.2.1 release :)

I tried that release (which needs the latest release of libmatchbox), but it didn't fix this bug.

commit f61c1f4b247c244d82c26ca7af77d332ca391f59
Author: Thomas Backlund <tmb@...>
Date:   Sun Jul 3 01:31:52 2016 +0300

    - auto_inst.cfg.pl: block problematic fonts (mga#17223)
    - live core media: add problematic font (mga#17223)
---
 Commit Link:
   http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=f61c1f4b247c244d82c26ca7af77d332ca391f59

On sta1 Plasma 5, a quick way to fix the forced-language-flag at login screen is:

/usr/share/sddm/scripts/Xsetup
+++ setxkbmap <LANGUAGE_CODE>

Maybe this could be automatically added so that new users speaking != English don't worry?

CC: (none) => tukozaki

(In reply to tu kozaki from comment #39)
> On sta1 Plasma 5, a quick way to fix the forced-language-flag at login
> screen is:
> 
> /usr/share/sddm/scripts/Xsetup
> +++ setxkbmap <LANGUAGE_CODE>
> 
This worked for me. With the add-on, with <language_code> as fr, the French flag is displayed instead of the US one at first screen, before any touch.

Seems the one thing that got missed was to add my prefdm patch to the initscripts package.

commit 9e65f2d3d2438d03a58f5f5a8322060fb1b8eb2e
Author: Martin Whitaker <mageia@...>
Date:   Sat Oct 22 18:05:37 2016 +0100

    Simplify and update update_media.sh.
    
    Add nvidia proprietary drivers, remove problematic fonts (as we now
    have a proper fix for mga#17223).
---
 Commit Link:
   http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=9e65f2d3d2438d03a58f5f5a8322060fb1b8eb2e

commit b6a40abe0a9f4127a1def0ac5b5667e963eebd80
Author: Martin Whitaker <mageia@...>
Date:   Sat Nov 12 19:06:31 2016 +0000

    Temporarily add patches for mga#17223, mga#19517, mga#19520.
---
 Commit Link:
   http://gitweb.mageia.org/software/build-system/draklive-config/commit/?id=b6a40abe0a9f4127a1def0ac5b5667e963eebd80

 Bug links:
   Mageia
      https://bugs.mageia.org/17223
      https://bugs.mageia.org/19517
      https://bugs.mageia.org/19520

Note that the patch needs updating to cope with the recent changes to prefdm, but I'm not rushing to do it as I'm not convinced the recent changes are correct (as per my comments on dev@ml).

I have no longer seen this in recent lives (sta2), selecting language, timezone and keyboard was possible and worked fine.


(In reply to Martin Whitaker from comment #44)
> Note that the patch needs updating to cope with the recent changes to
> prefdm, but I'm not rushing to do it as I'm not convinced the recent changes
> are correct (as per my comments on dev@ml).

I didn't read that discussion. Can this bug be closed, now, or do you want to keep it open?

With the last installation I done with Classical installer (sta2), the behavior is the same as what I cited in Comment 6.
But this is not Live. Is the bug report limited to Live?

(In reply to papoteur from comment #46)
> With the last installation I done with Classical installer (sta2), the
> behavior is the same as what I cited in Comment 6.
> But this is not Live. Is the bug report limited to Live?

That's not related to this issue, it's bug 15357 (upstream sddm issue).

Martin, is this bug now fixed?

Created attachment 8866 [details]
Updated patch to enable xsetup scripts to run before DM starts

I am applying the attached patch during the Live ISO build. Should it be applied to the base system?

Attachment 8085 is obsolete: 0 => 1

can someone validate this patch ?
can we add it for testing purposes ?

CC: (none) => mageia

(In reply to Nicolas Lécureuil from comment #49)
> can someone validate this patch ?
> can we add it for testing purposes ?

It's been applied to the Live ISOs since July, and fixes the bug. AFAIK it's not needed for installed systems, but does no harm. I've applied it to my main Mageia-6 system here with no ill effects.

i think you should go and commit for mass tests.

as it is a blocker we need tests and bugs closing ;)

Yes I would go for it so that we can test it widely and close this bug

CC: (none) => ennael1

OK, done.

(In reply to Martin Whitaker from comment #53)
> OK, done.

Is this fix part of the new sta2 ISO? Can it be marked as FIXED now?

Fix applied and available on sta2

Please reopen if the bug is still valid with  sta2 isos

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