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.
Whiteboard: (none) => 5alpha1
Please attach your /root/drakx/report.bug.xz
Keywords: (none) => NEEDINFO
Created attachment 5258 [details] pre-5alpha1report.bug.xz
Keywords: NEEDINFO => (none)
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
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
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'
(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.
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.
(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...
(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 :-)
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)
(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?
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
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
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
(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...
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
Keywords: NEEDINFO => (none)Whiteboard: 5alpha1 => 5beta3
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)
(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.
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.
(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?
(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
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); }
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
(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 :)
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)
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#
There's also https://github.com/AndrewFromMelbourne/fb2png which support 16, 24 & 32 bits depths (but not 8bit)
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.
(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 :)
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
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
Anyone care to build it, rebuild stage2 with it, test boot new stage2 with EFI fb?
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)
Created attachment 5890 [details] adapt stage2 to new fbdev you need to rebuild the stage2 with that patch when using new fb2png
Note that old fb2png failed to me with 24bit bpp, so it's already an improvement as stated in comment #26
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
Attachment 5891 mime type: application/x-patch => text/plain
Marja? want to test?
(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 :-/
the idea is to test with boot.iso install, rather than drakx-in-chroot
nm, I installed the new fb2png package and will rebuild stage2 with your patch
(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
(In reply to Marja van Waes from comment #37) > nm, I installed the new fb2png package and will rebuild stage2 with your > patch yes!
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?
You can just check for fb2png, checking it looks OK in logs
(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
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
(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
That wasn't what you saw on the screen?
(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
(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
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".
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
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
(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.
(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
(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.
Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED