Bug 13684 - F2 screenshots are empty after EFI-install (was using vesa instead of fb, now fb2png doesn't manage 32bit color depth)
Summary: F2 screenshots are empty after EFI-install (was using vesa instead of fb, now...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Thierry Vignaud
QA Contact:
URL:
Whiteboard: 5beta3
Keywords: NEEDINFO
Depends on:
Blocks:
 
Reported: 2014-07-05 16:36 CEST by Marja Van Waes
Modified: 2015-02-12 06:14 CET (History)
3 users (show)

See Also:
Source RPM: drakx-installer-stage2, fb2png
CVE:
Status comment:


Attachments
pre-5alpha1report.bug.xz (244.71 KB, application/x-xz)
2014-07-05 20:20 CEST, Marja Van Waes
Details
report.bug.xz of version 16.40 install (but fb) (330.55 KB, application/x-xz)
2014-08-28 22:51 CEST, Marja Van Waes
Details
ddebug.log of EFI install on 2014-07-12 (207.48 KB, application/x-xz)
2014-11-29 12:48 CET, Marja Van Waes
Details
report.bug, stage2 v.16.54 (36.68 KB, application/x-xz)
2015-02-10 11:56 CET, Marja Van Waes
Details
report.bug.xz with stage2 v.16.55 (36.57 KB, application/x-xz)
2015-02-10 14:01 CET, Marja Van Waes
Details
Andrew's fb2png SRPM (9.55 KB, audio/x-rpm)
2015-02-11 06:42 CET, Thierry Vignaud
Details
adapt stage2 to new fbdev (799 bytes, patch)
2015-02-11 06:55 CET, Thierry Vignaud
Details | Diff
adapt stage2 to new fbdev (v2) (800 bytes, text/plain)
2015-02-11 06:59 CET, Thierry Vignaud
Details
ls -al from /root/drakx/DrakX-screenshots (1.49 KB, text/plain)
2015-02-11 11:58 CET, Marja Van Waes
Details
classical iso in VBox (_without_ fb2png fix) (26.22 KB, image/png)
2015-02-11 16:41 CET, Marja Van Waes
Details
diskdrake in VBox, using patched stage2 (209.12 KB, image/png)
2015-02-11 20:28 CET, Marja Van Waes
Details

Description Marja Van Waes 2014-07-05 16:36:56 CEST
I tried twice to make screenshots during a pre-Mageia5alpha1 64bits install, both times the screenshots in /root/DrakX-screenshots/ were all empty, but the time stamps and the amount of .png files seemed correct.

This was both for screenshots of normal screens, and for a shot of a help screen.

I did not try whether screenshots from before the partitioning step were any better.
Marja Van Waes 2014-07-05 16:37:08 CEST

Whiteboard: (none) => 5alpha1

Comment 1 Thierry Vignaud 2014-07-05 19:52:24 CEST
Please attach your /root/drakx/report.bug.xz

Keywords: (none) => NEEDINFO

Comment 2 Marja Van Waes 2014-07-05 20:20:37 CEST
Created attachment 5258 [details]
pre-5alpha1report.bug.xz
Marja Van Waes 2014-07-05 20:20:55 CEST

Keywords: NEEDINFO => (none)

Comment 3 Thierry Vignaud 2014-07-05 20:40:03 CEST
That's b/c it failed to load fb xorg driver on your machine (intel again) and thus it used the vesa driver

CC: (none) => tmb

Comment 4 Thierry Vignaud 2014-08-22 09:03:49 CEST
Can you try latest cauldron install (uploaded this morning)?
eg if you use http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/x86_64/ VERSION should contains 16.40.

also you need to use this morning install/images/boot.iso (or install/images/boot-nonfree.iso if you've hardware that needs firmware)

then after the install is completed, your /root/drakx/report.bug.xz should tell us why xorg/vesa failed

Keywords: (none) => NEEDINFO

Comment 5 Thierry Vignaud 2014-08-22 16:52:16 CEST
Explanation: the logs would help us understand why vesa failed on your box, that won't help taking snapshots when using vesa instead of fb

Summary: F2 screenshots are empty after install (0 Bytes) => F2 screenshots are empty after install (0 Bytes) when using 'vesa' driver instead of 'fb'

Comment 6 Marja Van Waes 2014-08-22 18:50:51 CEST
(In reply to Thierry Vignaud from comment #4)
> Can you try latest cauldron install (uploaded this morning)?
> eg if you use
> http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/
> x86_64/ VERSION should contains 16.40.
> 
> also you need to use this morning install/images/boot.iso (or
> install/images/boot-nonfree.iso if you've hardware that needs firmware)
> 
> then after the install is completed, your /root/drakx/report.bug.xz should
> tell us why xorg/vesa failed


Thanks, Thierry, that is great!

I wish I had taken that laptop with me... If the trains back aren't too delayed, then I'll test Monday night, else it'll be near the end of next week.
Comment 7 Marja Van Waes 2014-08-28 22:51:24 CEST
Created attachment 5380 [details]
report.bug.xz of version 16.40 install (but fb)

(In reply to Thierry Vignaud from comment #3)
> That's b/c it failed to load fb xorg driver on your machine (intel again)
> and thus it used the vesa driver

Sorry, when you said this, I should have remembered that for EFI installs Vesa is used. 


(In reply to Thierry Vignaud from comment #5)
> Explanation: the logs would help us understand why vesa failed on your box,
> that won't help taking snapshots when using vesa instead of fb


boot(-nonfree).iso doesn't support EFI install, so I did a regular install to a USB-key on that system instead.

And now of course, it _not_ being an EFI install, fb was used.

Attaching the log, anyway, so it won't be lost if you'd still like to see it. 

I intend to try again tomorrow evening or Saturday with "xdriver=vesa" appended to the kernel options.
Comment 8 Thomas Backlund 2014-08-28 23:09:51 CEST
(In reply to Marja van Waes from comment #7)
> Created attachment 5380 [details]
> report.bug.xz of version 16.40 install (but fb)
> 
> (In reply to Thierry Vignaud from comment #3)
> > That's b/c it failed to load fb xorg driver on your machine (intel again)
> > and thus it used the vesa driver
> 
> Sorry, when you said this, I should have remembered that for EFI installs
> Vesa is used. 
> 

well not really as efi does not really care about vesa, but it sort of works anyway... 

> 
> (In reply to Thierry Vignaud from comment #5)
> > Explanation: the logs would help us understand why vesa failed on your box,
> > that won't help taking snapshots when using vesa instead of fb
> 
> 
> boot(-nonfree).iso doesn't support EFI install, so I did a regular install
> to a USB-key on that system instead.
> 


It should work (unless I have broken it lately)

Anyway I have some efi changes that I will start pushing this weekend...
Comment 9 Marja Van Waes 2014-08-29 13:52:45 CEST
(In reply to Thomas Backlund from comment #8)
> (In reply to Marja van Waes from comment #7)
> > Created attachment 5380 [details]
> > report.bug.xz of version 16.40 install (but fb)
> > 
> > (In reply to Thierry Vignaud from comment #3)
> > > That's b/c it failed to load fb xorg driver on your machine (intel again)
> > > and thus it used the vesa driver
> > 
> > Sorry, when you said this, I should have remembered that for EFI installs
> > Vesa is used. 
> > 
> 
> well not really as efi does not really care about vesa, but it sort of works
> anyway... 


/o\

I'm mixing up so many things now, that I'll put "having a vacation" near the top of my todo list!

> 
> > 
> > (In reply to Thierry Vignaud from comment #5)
> > > Explanation: the logs would help us understand why vesa failed on your box,
> > > that won't help taking snapshots when using vesa instead of fb
> > 
> > 
> > boot(-nonfree).iso doesn't support EFI install, so I did a regular install
> > to a USB-key on that system instead.
> > 
> 
> 
> It should work (unless I have broken it lately)

Thanks, I hadn't tried. It'll probably be easier to do that.

IIRC, the bootloader screen for an efi-install doesn't have a button to add or change kernel options. How do I choose "xdriver=vesa" if it doesn't automatically use vesa again, as it did on that laptop with (pre-)alpha1 ?

> 
> Anyway I have some efi changes that I will start pushing this weekend...

Great :-)
Comment 10 Marja Van Waes 2014-08-31 17:07:23 CEST
While using the same boot-nonfree.iso earlier today, "cat /tmp/Xconf" showed: 
Driver     "fbdev"

I wish I knew how to force using vesa with a network install

Next attempt, with today's boot-nonfree.iso, trying with 

linux xdriver=vesa

at the boot prompt, doesn't seem to make a difference: /tmp/Xconf still shows "fbdev"

(just "xdriver=vesa" was rejected)
Comment 11 Marja Van Waes 2014-08-31 17:14:21 CEST
(In reply to Thierry Vignaud from comment #5)
> Explanation: the logs would help us understand why vesa failed on your box,
> that won't help taking snapshots when using vesa instead of fb

TBH, I'm not 100% sure I understand what you say here.

You do want taking snapshots to work when installer falls back to vesa instead of fb, so it is useful if I manage to reproduce the problem, correct?
Comment 12 Marja Van Waes 2014-11-29 11:40:32 CET
still don't manage to force using the vesa driver in stage2

with the EFI-boot-install I had:
* running: mount -t tmpfs none /tmp/.X11-unix
* Trying with server Driver:fbdev
* waiting for the server to start (1 )
(etc)
* waiting for the server to start (60 )
* Timeout!!
* Trying with server Driver:vesa
* waiting for the server to start (1 )
* waiting for the server to start (2 1)
* waiting for the server to start (3 2)
* AFAIK X server is up

EFI-boot installs haven't been possible for a while (I hope tmb will give a ping when it should work again with boot.iso)

For a normal install, when adding xdriver=vesa to the kernel options, that works in stage1:
*       automatic=method:cdrom initrd=x86_64/all.rdz automatic=method:cdrom vga=788 xdriver=vesa

but vesa is *not* used in stage2:
* running: mount -t tmpfs none /tmp/.X11-unix
* Trying with server Driver:fbdev
* waiting for the server to start (1 )
* waiting for the server to start (2 1)
* waiting for the server to start (3 2)
* AFAIK X server is up
Comment 13 Thierry Vignaud 2014-11-29 12:00:32 CET
fbdev is nice if it's working.
If fbdev fails and if we fallback to vesa, I would need the full ddebug.log to be attached
Comment 14 Marja Van Waes 2014-11-29 12:48:21 CET
Created attachment 5660 [details]
ddebug.log of EFI install on 2014-07-12

(In reply to Thierry Vignaud from comment #13)
> fbdev is nice if it's working.
> If fbdev fails and if we fallback to vesa, I would need the full ddebug.log
> to be attached


If screenshotting with F2 wil never be possible with vesa, then the summary should be changed to "fbdev fails in EFI-install".

My newest ddebug.log is from *before* drakx-installer-stage2-16.40, but it is younger than the one in attachment 5258 [details] .... I hope it contains more useful information, anyway.

fbdev never failed on this machine when doing a regular install, it only failed with EFI-installs. Since asked to try with drakx-installer-stage2-16.40, I haven't manage to do an EFI-install, but that could have any reason: I hadn't EFI-installed right before 16.40 was released.

If screenshotting with F2 wil never be possible with vesa, then the summary should be changed to "fbdev fails in EFI-install".

Attachment 5258 is obsolete: 0 => 1
Attachment 5380 is obsolete: 0 => 1

Comment 15 Thomas Backlund 2014-11-29 16:02:54 CET
(In reply to Thierry Vignaud from comment #13)
> fbdev is nice if it's working.
> If fbdev fails and if we fallback to vesa, I would need the full ddebug.log
> to be attached

That's the problem.

EFI spec knows nothing about vesa, so if it works, it's just pure luck ...

We should use efifb when running install in efi mode

I was also thinking of adding a is_efi() function to drakx that checks if /sys/firmware/efi exists and if it does return 1, otherwise 0.

That way the check can be reused over all drakx to do efi specific coding...
Comment 16 Marja Van Waes 2015-02-10 11:56:33 CET
Created attachment 5879 [details]
report.bug, stage2 v.16.54

Sorry, Thierry, I forgot to attach a new ddebug.log when EFI-install started to work again :-/

The bug is still valid here with stage2 v16.54 (I'll try 16.55 asap)

Attaching report.bug.xz of the last upgrade install I ran for bug 14980 (based on version 16.54, but with anaselli's 2nd patch included, which shouldn't affect this bug).

On the first screenshot I see:
* running: fb2png /dev/fb0 /tmp/DrakX-screenshots/1.png 0
Not supported!!
matchbox-wm: X error warning (0xa00ab1): 140 (opcode: 138)

The 4th and later screenshots (I don't see 2nd and 3rd) have the same error, except for the matchbox-wm part.

There are several warnings and errors in Xorg.log.

However, it is not vesa that is used in the end. I see that submodules "fb" and "shadow" were loaded after (sub)modules "fbdev" and "fbdevhw" were unloaded.

Something I think (but my assumption aren't always correct) cannot affect this bug either, is that there was an issue with the 32bits media with all 64bits boot-nonfree.iso installs I tried over the last days, using a local mirror. The 32bits media on the same local mirror worked fine, when updating after reboot without changing urpmi.cfg

Attachment 5660 is obsolete: 0 => 1

Marja Van Waes 2015-02-10 11:56:54 CET

Keywords: NEEDINFO => (none)
Whiteboard: 5alpha1 => 5beta3

Marja Van Waes 2015-02-10 11:58:12 CET

Summary: F2 screenshots are empty after install (0 Bytes) when using 'vesa' driver instead of 'fb' => F2 screenshots are empty after EFI-install (0 Bytes)

Comment 17 Marja Van Waes 2015-02-10 12:02:26 CET
(In reply to Marja van Waes from comment #16)
> The 32bits media on the same local mirror worked fine, when updating
> after reboot without changing urpmi.cfg

That can't be true: the 32bits media must have gotten disabled!
Anyway, this is a separate issue.
Comment 18 Thomas Backlund 2015-02-10 12:03:04 CET
currently screenshots in efi mode wont work.

they rely on vesa support, something that is not supported in efi

So screenshots can only be done on nun-uefi installs for now.
Comment 19 Marja Van Waes 2015-02-10 12:10:56 CET
(In reply to Thomas Backlund from comment #18)
> currently screenshots in efi mode wont work.
> 
> they rely on vesa support, something that is not supported in efi
> 
> So screenshots can only be done on nun-uefi installs for now.

I can live perfectly well with this getting fixed *after* Mga5 release, Thomas :-)

However, I'm not sure screenshots rely on vesa support, because when I first hit this problem I got this answer:

(In reply to Thierry Vignaud from comment #3)
> That's b/c it failed to load fb xorg driver on your machine (intel again)
> and thus it used the vesa driver

Or did something change since then?
Comment 20 Thierry Vignaud 2015-02-10 12:20:21 CET
(In reply to Thomas Backlund from comment #15)
Does v16.54p2 (as seen in Marja logs) has a patch to include efifb?

(In reply to Marja van Waes from comment #16)
Strange, your install used fb (through efifb, not vesa, yet fb2png failed...
On the other hand, fb2png dates from 2001...

We could:
- either patch it to handle more color depths (here the "not supported" message means it doesn't support the color depth of the fb)
- or try to alter the efifb mode if possible (tmb?)
- or try to see if android's fb2png works better with UEFI...
(https://code.google.com/p/android-fb2png/source/browse/)

Source RPM: drakx-installer-stage2 => drakx-installer-stage2, fb2png

Comment 21 Thierry Vignaud 2015-02-10 12:26:00 CET
Ours only support 16 & 24 bits color depth (resp 2 & 3 bytes) but print "not supported" for 8 & 32 bits depths (resp 1 & 4 bytes).

Though it says 32 bit could work:

  else if (inbyte == 4){ // should work, test test test!!!
	printf("Not supported!!\n");
	exit(1);
  }
Comment 22 Thomas Backlund 2015-02-10 12:27:59 CET
efifb is built into the kernel (no other option), so it's always available.

on xorg side, we rely on fbdev seeting it up for us
Comment 23 Thomas Backlund 2015-02-10 12:29:05 CET
(In reply to Thierry Vignaud from comment #21)
> Ours only support 16 & 24 bits color depth (resp 2 & 3 bytes) but print "not
> supported" for 8 & 32 bits depths (resp 1 & 4 bytes).
> 
> Though it says 32 bit could work:
> 
>   else if (inbyte == 4){ // should work, test test test!!!
> 	printf("Not supported!!\n");
> 	exit(1);
>   }


So we could try to enable it and see if it can handle it :)
Thierry Vignaud 2015-02-10 12:32:18 CET

Summary: F2 screenshots are empty after EFI-install (0 Bytes) => F2 screenshots are empty after EFI-install (was using vesa instead of fb, now fb2png doesn't manage colro depth)

Comment 24 Thierry Vignaud 2015-02-10 12:33:47 CET
We could. Needs patching.
But we would still be stuck with an old unsupported tool.

Also note that android's fb2png handles 32bit depth since 2012:
https://code.google.com/p/android-fb2png/source/detail?r=5f242486daa0dff66e60bf638e578819535169c3#
Comment 25 Thierry Vignaud 2015-02-10 12:37:42 CET
There's also https://github.com/AndrewFromMelbourne/fb2png
which support 16, 24 & 32 bits depths (but not 8bit)
Comment 26 Thierry Vignaud 2015-02-10 13:22:51 CET
Actually, when reading the sources, I think Google's one only support 16 & 32 bit (and only some RGBx representations).
eg:

bpp              | 8 | 16 | 24 | 32 | date
------------------------------------------
old fb2png       | - |  X |  X |  - | <= 2001
android's fb2png | - |  X |  - |  X | May 2014
Andrew's fb2png  | - |  X |  X |  X | Sep 2013

So I think we should go with Andrew's fb2png.
Also its code is more generic whereas android's is hardcoding only some 16/32 RGBx representations.

Could with easily tested with a VM.

Btw, Thomas, you set color depth to 24 when using EFI
(http://gitweb.mageia.org/software/drakx/commit/perl-install/install/gtk.pm?id=a87029bb51f98212171ddc62e144511b715587b7)
but Marja's logs hints that fbdev may not actually change the color depth:
"Depth 24, (--) framebuffer bpp 32"

Which would explain the fb2png failure as it's supposed to handle depth 24 fine.
Comment 27 Thomas Backlund 2015-02-10 13:45:14 CET
(In reply to Thierry Vignaud from comment #26)

> Btw, Thomas, you set color depth to 24 when using EFI
> (http://gitweb.mageia.org/software/drakx/commit/perl-install/install/gtk.
> pm?id=a87029bb51f98212171ddc62e144511b715587b7)
> but Marja's logs hints that fbdev may not actually change the color depth:
> "Depth 24, (--) framebuffer bpp 32"
> 

Yeah, thats because grub2 sets up graphical mode in depth 24, so I need to match it when fbdev initializes or it will fail to get into graphical mode.

I tried to use depth 32 but that didn't work...

I'll try to test some more, but for now I'm actually happy it atleast gets us a working graphical installer :)
Comment 28 Marja Van Waes 2015-02-10 14:01:21 CET
Created attachment 5881 [details]
report.bug.xz with stage2 v.16.55

Nothing important changed, but attaching report.bug.xz from an upgrade with last night's 64bits QA traditional DVD, because the used stage2 is newer and because it is the official stage2 (instead of a locally built one)

Attachment 5879 is obsolete: 0 => 1

Comment 29 Thierry Vignaud 2015-02-11 06:42:27 CET
Created attachment 5889 [details]
Andrew's fb2png SRPM

A 9.6kb SRPM that switches from old outdated fb2png to Andrew'sone
Only tested with 24bit fb
Comment 30 Thierry Vignaud 2015-02-11 06:44:21 CET
Anyone care to build it, rebuild stage2 with it, test boot new stage2 with EFI fb?

Keywords: (none) => NEEDINFO

Thierry Vignaud 2015-02-11 06:44:31 CET

Summary: F2 screenshots are empty after EFI-install (was using vesa instead of fb, now fb2png doesn't manage colro depth) => F2 screenshots are empty after EFI-install (was using vesa instead of fb, now fb2png doesn't manage 32bit color depth)

Comment 31 Thierry Vignaud 2015-02-11 06:55:24 CET
Created attachment 5890 [details]
adapt stage2 to new fbdev

you need to rebuild the stage2 with that patch when using new fb2png
Comment 32 Thierry Vignaud 2015-02-11 06:55:42 CET
Note that old fb2png failed to me with 24bit bpp, so it's already an improvement as stated in comment #26
Comment 33 Thierry Vignaud 2015-02-11 06:59:00 CET
Created attachment 5891 [details]
adapt stage2 to new fbdev (v2)

you need to rebuild the stage2 with that patch when using new fb2png

Attachment 5890 is obsolete: 0 => 1

Thierry Vignaud 2015-02-11 06:59:16 CET

Attachment 5891 mime type: application/x-patch => text/plain

Comment 34 Thierry Vignaud 2015-02-11 09:49:24 CET
Marja? want to test?
Comment 35 Marja Van Waes 2015-02-11 10:21:49 CET
(In reply to Thierry Vignaud from comment #34)
> Marja? want to test?

yes, I'd like to, but still lack needed knowledge to become a full packager and might have done the first step wrong, were those commands correct:

$ rpmbuild --rebuild fb2png-0.1-17.git7ca311e.mga5.src.rpm
  (error: Failed build dependencies:
        libpng-devel is needed by fb2png-0.1-17.git7ca311e.mga5.x86_64)
# urpmi lib64png-devel
$ rpmbuild --rebuild fb2png-0.1-17.git7ca311e.mga5.src.rpm

so can I safely use
/home/marja/rpmbuild/RPMS/x86_64/fb2png-0.1-17.git7ca311e.mga5.x86_64.rpm ?

If so: I'll put it in 
/path/to/local/mirror/mageia/distrib/cauldron/x86_64/media/core/release/

However, I'm not sure I do know how to correctly use genhdlist2 then :-/
Comment 36 Marja Van Waes 2015-02-11 10:23:33 CET
the idea is to test with boot.iso install, rather than drakx-in-chroot
Comment 37 Marja Van Waes 2015-02-11 11:07:10 CET
nm, I installed the new fb2png package and will rebuild stage2 with your patch
Comment 38 Thierry Vignaud 2015-02-11 11:10:06 CET
(In reply to Marja van Waes from comment #36)
Obviously as we cannot take screenshots with F2 with drakx-in-chroot :-)
(same issue which will also happen if/when we switch to Wayland :-) )

(In reply to Marja van Waes from comment #35)
Just update fb2png on your system with it then rebuild stage2.
If you use iurt to build packages then yes you would need to run genhdlist2 on the media (or gendistrib in order not to break file deps).
So I recommend you not to use iurt, it'll be simpler:
 sudo urpmi SPECS/drakx-installer-stage2.spec
 # then either:
 rpmbuild -ba SPECS/drakx-installer-stage2.spec
 # or:
 bm -b
Comment 39 Thierry Vignaud 2015-02-11 11:10:18 CET
(In reply to Marja van Waes from comment #37)
> nm, I installed the new fb2png package and will rebuild stage2 with your
> patch

yes!
Comment 40 Marja Van Waes 2015-02-11 11:58:10 CET
Created attachment 5894 [details]
ls -al from /root/drakx/DrakX-screenshots

@ Thierry
You fixed it!

As you can see in the attachments, all today's screenshots are OK (the empty ones are from before the new fb2png package + your patch)

Screenshotting the help works, too :-)

I did not check installer logs, because it all works fine. Do want to see a log, anyway?
Comment 41 Thierry Vignaud 2015-02-11 12:38:10 CET
You can just check for fb2png, checking it looks OK in logs
Comment 42 Marja Van Waes 2015-02-11 12:53:29 CET
(In reply to Thierry Vignaud from comment #41)
> You can just check for fb2png, checking it looks OK in logs

about half of the
* running: fb2png -p /tmp/DrakX-screenshots/*.png
and
running: fb2png -p /mnt/root/DrakX-screenshots/*.png
lines is followed by:

matchbox-wm: X error warning (0xa006ba): 140 (opcode: 138) 

of course, "(0xa006ba)" changes every time
Comment 43 Thierry Vignaud 2015-02-11 13:06:11 CET
matchbox often outputs such warnings...
Btw can you check the images are good?
Can you also test your stage2 on a regular vbox vm so that we ensure there's no regression on "classic" fb?
thanks
Comment 44 Marja Van Waes 2015-02-11 14:19:04 CET
(In reply to Thierry Vignaud from comment #43)
> matchbox often outputs such warnings...
> Btw can you check the images are good?

The width might be smaller and the height higher than what I saw while installing, and they cannot be used for documentation, because the left panel is missing (like it was missing while upgrade installing)

Ypu can check the screenshots here
http://waesvanm.home.xs4all.nl/Mageia/screenshots/New_fb2png/

> Can you also test your stage2 on a regular vbox vm so that we ensure there's
> no regression on "classic" fb?

Not now (that requires a lot of "how did I do that again?.... I haven't installed in vbox since over a year ago... don't have the needed time now), but it can be found here
http://waesvanm.home.xs4all.nl/Mageia/Stage2/With_new_fb2png/x86_64/
(sorry for having forgotten to add a "_" before "fb2png" in VERSION)

CC'ing Akien, who I think does a lot of vbox installs, and who knows more about stage2 than any other QA iso-tester I can think of

CC: (none) => remi

Comment 45 Thierry Vignaud 2015-02-11 16:03:39 CET
That wasn't what you saw on the screen?
Comment 46 Marja Van Waes 2015-02-11 16:19:59 CET
(In reply to Thierry Vignaud from comment #45)
> That wasn't what you saw on the screen?

It _was_ what I saw on the screen, only difference is that width:height was far from 4:3 (my laptop has a wide screen)

I've spent some time fighting with vbox, anyway, but wasn't successful, sorry
Comment 47 Marja Van Waes 2015-02-11 16:24:33 CET
(In reply to Marja van Waes from comment #46)

> 
> I've spent some time fighting with vbox, anyway, but wasn't successful

meaning that I didn't even manage to start install from the USB-key
Comment 48 Marja Van Waes 2015-02-11 16:41:25 CET
Created attachment 5895 [details]
classical iso in VBox (_without_ fb2png fix)

Tbh, when trying to do a VBox install with the last classical iso on DVD (so without the fb2png fix), I'm not succesful, either

I got as far as the screen in the attached screenshot, tried pressing "Esc", any other key ("j") and "linux".
Comment 49 Marja Van Waes 2015-02-11 16:52:59 CET
also CC'ing wilcal, who is said to have done EFI-installs in VBox

@ wilcal

I didn't get anywhere (see comment 47 and comment 48), and appreciate any tips or tricks

CC: (none) => wilcal.int

Comment 50 Marja Van Waes 2015-02-11 20:28:21 CET
Created attachment 5898 [details]
diskdrake in VBox, using patched stage2

(In reply to Thierry Vignaud from comment #43)

> Can you also test your stage2 on a regular vbox vm so that we ensure there's
> no regression on "classic" fb?

I did finally manage to use the USB-key with fixed stag2 (contents copied from classical 64bits DVD, mdkinst.sqfs replaced with the one with Thierry's fix) in combination with an old boot-nonfree.iso, which for some reason EFI-booted nicely in VBox.

I did not manage to finish the install (seems not all needed packages were copied to the USB-key), but the screens look OK, I think that is all that matters?

Attaching one screenshot
Comment 51 Rémi Verschelde 2015-02-11 21:13:06 CET
(In reply to Marja van Waes from comment #50)
> Created attachment 5898 [details]
> diskdrake in VBox, using patched stage2

That's interesting, you don't seem to be affected by bug 12422.
Comment 52 Marja Van Waes 2015-02-11 21:21:22 CET
(In reply to Rémi Verschelde from comment #51)
> (In reply to Marja van Waes from comment #50)
> > Created attachment 5898 [details]
> > diskdrake in VBox, using patched stage2
> 
> That's interesting, you don't seem to be affected by bug 12422.

Well, this is only in VBox, when efi-installing on real hw, there is no left panel at all, not even covered: it is simply not there (for screenshots see the first link in comment 44)

The patched stage2 was based on git version 16.56, btw
Comment 53 Thierry Vignaud 2015-02-11 21:23:52 CET
(In reply to Marja van Waes from comment #46)

I meant testing on a non UEFI VM :-)

As for proportions, your screen may have streched the image somewhat, the png we obtain is rendered on other machines with square pixels, so ratio might look a little bit different.
I was afraid we were missing some bits of the fb image.

So good to go.
Comment 54 Thierry Vignaud 2015-02-12 06:14:59 CET
Closing

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


Note You need to log in before you can comment on or make changes to this bug.