Created attachment 5880 [details]
photo

Classic DVD 32 is not affected so likely a missing package or two.

Nonfree appears to be completely missing from dualdvd, judging by the idx

Classic DVD 64 is not affected either, so just dual so far.

Anne, Thomas, you should check the boot options in isolinux.cfg between full ISOs and the dual one, there might be a difference in config that would explain that glitch

Summary: 5b3: Display corruption unable to install => 5b3: Display corruption unable to install (only with dualdvd ISO)
CC: (none) => ennael1, sysadmin-bugs, thierry.vignaud, tmb
Component: Installer => Release (media or process)

Just checked but same things in all isolinux.cfg

label linux
  kernel <arch>/vmlinuz
  append initrd=<arch>/all.rdz automatic=method:cdrom vga=788 splash quiet

where's the thing that select either 32 or 64bit?

in isolinux directory :
isolinux/
   isolinux.cfg
   i586.cfg
   x86_64.cfg

cat isolinux/isolinux.cfg
default load
SERIAL 0

label load
        com32 ifcpu.c32
        append 64 -- x86_64 -- i586

label i586
        CONFIG i586.cfg

label x86_64
        CONFIG x86_64.cfg

With the latest dualdvd (round 4 11th Feb) this is fixed.

I spoke too soon. It began when choosing keyboard layout.

Switched to tty2, which was fine, and back and then corruption when I moved the mouse

clicking Next to move it on to the partitioning screen, the entire window and part of the left side bar are corrupted.

The window appears with square coreners and the outer rounded edges are reversed, with the right hand rounded edge appearing on the left, with part of a button and the left hand rounded edge appearing on the right.

I'll attempt to switch tty with the other DVDs also to see if that acts as a trigger.

I'm unable to cause this to happen using DVD 32 so definitely just a dual thing.

@tv: I don't get why you think it's related to syslinux as the picture clearing show we are already under X. At that stage, syslinux have no impact.

In case it helps..

# lspcidrake -v | grep -i card
Card:NVIDIA GeForce 8100 to GeForce 415: NVIDIA Corporation|GT216 [GeForce GT 220] [DISPLAY_VGA] (vendor:10de device:0a20) (rev: a2)

I think it mis-initialize the gfx card as this is the only difference between normal ISOs & dual ISO

Experienced this today with the Classical DVD 64, so dual only is a false lead and it is seemingly 64bit only.

I didn't do anything special to trigger it, just selected language and clicked through the license agreement. I've been testing mostly 32bit ISOs until this point but unsure how it didn't affect 64bit dvd previously.

I'm dumping again to a different USB stick to rule out PEBKAC and media issues.

Summary: 5b3: Display corruption unable to install (only with dualdvd ISO) => 5b3: Display corruption unable to install (only with 64bit non-efi)

Probably either a kernel issue or a fbdev issue

Source RPM: isolinux => kernel

Confirmed it. Happened on the license screen this time DVD 64. 
It starts with a mouse trail of corruption.

What hardware info is needed? Most can be seen on bug 15255

Could you complete a full install and then attach your /root/drakx/report.bug.xz?

Keywords: (none) => NEEDINFO

I can't see to do so Thierry. The corruption makes everything illegible.

I've tried the same ISO on a different non-efi computer with a newer graphics card though, nvidia-current, and it doesn't have this issue.

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

CC: (none) => zayd_depaor

Is it still valid using rc iso?

Reported on pad by pete larson (azziam) with nvidia304. Adding him in cc.

I'll check dual with nvidia340.

CC: (none) => petel123123
Keywords: NEEDINFO => (none)

Confirmed still present nvidia340 64bit (tested with dual)

Created attachment 5971 [details]
report.bug

I've performed an install, from memory mostly, and reached as far as the summary and bootloader configuration.

I managed to grab report.bug, but terminals are corrupted also.

We still seem to be missing some nonfree:
unknown package `x11-driver-video-nvidia340'

Also xdm but that is reported elsewhere IINM.

x11-driver-video-nvidia340 not being on the ISO is another issue (please open another BR).
Anyway installer doesn't use nvidia driver, just fb and thus rely on the kernel.

What's strange is that yours logs shows x.org server 1.16.3 whereas we've 1.16.4 for a month.

Also Drakx is at v16.62 (which should have x.org server 1.16.4) instead of 16.65

is RC using an outdated stage2? That would have been rebuild against an outdated tree?

As said in previous mail, RC was built before new stage2 was out (see mails with tmb). Tests to be done with up to date stage2

Still valid 5RC 2nd Build using dualdvd DATE: Tue Mar  3 08:57:38 CET 2015

Created attachment 5979 [details]
new report.bug from build 2

I think there is still a discrepancy there..

X.Org X Server 1.16.4
Release Date: 2014-12-20
...

[    28.556] (II) LoadModule: "fbdev"
[    28.557] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[    28.561] (II) Module fbdev: vendor="X.Org Foundation"
[    28.561] 	compiled for 1.16.3, module version = 0.4.4

[    28.751] (II) LoadModule: "evdev"
[    28.751] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so
[    28.764] (II) Module evdev: vendor="X.Org Foundation"
[    28.764] 	compiled for 1.16.2, module version = 2.9.1

I may be entirely wrong though.

the "compiled for ..." are just informational, noting that they have not been rebuilt since that server version vas default.

This should not be an issue as the api is stable between all "1.16.x"

Indeed that's OK, we don't rebuild input/video driver for new minor server releases (X server ABI being stable).

That's said, there's nothing obvious (vesafb, 16bpp).
Bpp is 16bits/pixel.
Can you try booting with "linux vga=XXX" instead of just <enter>?
Can you try:
- vga=787 (15bpp),
- vga=789 (24bpp)
- vga=771 (8bpp, never tried but who knows)

See http://pierre.baudu.in/other/grub.vga.modes.html or http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Linux_video_mode_numbers 

Currently we were using vga=788 (16bpp).


Does that make a difference?

Keywords: (none) => NEEDINFO

I'll give them a try, note though that 32bit DVD works fine on this same HW.

Also: do you confirm that if you install with only the keyboard, everything is OK?

Summary: 5b3: Display corruption unable to install (only with 64bit non-efi) => 5b3: Display corruption once the cursor moves (only with 64bit non-efi)

If that doesn't work, we could try playing with  "SWCursor" option

787 works \o/
789 X fails to start, ends with repeating "slow to start" message.
771 X fails to start, ends with repeating "slow to start" message.

Oh, X does eventually start after a page or two of the repeating message. 
It then has corruption as before.

With mouse unplugged, it's also fine, although tricky to navigate. The corruption started when moving the mouse cursor over the language choice window initially.

that was mouse unplugged and default kernel options

Plugged mouse in again at partitioning stage and attempted to continue to custom partitioning and the corruption starts again as before.

(In reply to claire robinson from comment #40)
> Oh, X does eventually start after a page or two of the repeating message. 
> It then has corruption as before.

Actually it may have started with vesa driver instead of fbdev (we wait only 60s for the X server to come up).
Can you attah the logs for that install?

Hardware: i586 => x86_64
Summary: 5b3: Display corruption once the cursor moves (only with 64bit non-efi) => 5b3: Display corruption once the cursor moves (64bit is KO, 32bit is OK) with 16bpp & 24bpp (OK with 15bpp)

Created attachment 5980 [details]
report789.bug

taken after the xorg failed to start and the repeating "too slow" with vga=789
corruption occurred with mouse movement over the text area as before

I'll repeat with vga=771

Indeed fbdev failed to initialize and we tried vesa driver instead.

Created attachment 5981 [details]
report771.bug

same with vga=771, same symptoms and outcome.

Thierry any clue on that one ? DO you need more information?

I've no clue.

I've dropped the upstream "default to 32bit if console says 8bit" + dependent patches from x11-driver-video-fbdev and rebuilt stage2 with it.

@MrsB: Please try with boot,iso when drakx-installer-stage2-16.67-2.mga5 is available in your local repo

First thing tomorrow, thanks Thomas

The corruption is still present using current boot-nonfree.iso from March 7th dumped onto a usb stick.

drakx-installer-stage2-16.67-2.mga5.x86_64.rpm on the mirror.

Valid build 3 (DATE: Sun Mar 15 22:54:23 CET 2015)

Keywords: NEEDINFO => (none)

What is the status on this one? Any idea to debug it further?

Would it be worth looking at what changed between 5beta2 and 5beta3 to identify what caused the regression?

Valid in latest RC ISO's

ISO:  Mageia-5-RC-dual-DVD.iso
DATE: Sun Mar 29 14:21:36 CEST 2015
MD5:  OK     SHA1: OK

Proposed to be added in errata with explanations. if ok then we can decrease priority

Can you try latest boot.iso?
It has latest kernel which has fb fixes

Keywords: (none) => NEEDINFO

I just tried with new dual and the problem persists. It should have the new kernel fixes. I'll grab the boot.iso though and try that too.

Confirmed also with boot.iso

Still valid

Tested with dualdvd DATE.txt: Wed Apr 15 09:01:48 CEST 2015

Keywords: NEEDINFO => (none)

Corruption started on the language choice screen.

I was asked to look for this bug on my hardware with the April 15 DualDVD iso. I did NOT see it at all, using usb flash media created with IsoDumper. Everything appeared to look and act normally. 64-bit install had no issues.

Detailed hardware list:

Asus-made Fujitsu D1711 Socket 754 motherboard (Asus #K8V-MX/s)
AMD Sempron 3100+ processor
nvidia GeForce 6200 OC AGP video card, using digital output port
AOC e2351F LED monitor
Logitech MK320 cordless optical desktop set, less than two weeks old
(K330 keyboard, M215 optical mouse, Unifying receiver)

CC: (none) => andrewsfarm

Ahh it's possible it did a 32bit install with that processor TJ. 
I don't think it will support 64bit unfortunately.

Not so, Claire. The "Details" display during installation showed many packages that included "64" in their names. And when it came to setting up my US mirror, my repository choices included both 64 and 32 bit choices.

This processor is one of the earliest Semprons to be capable of 64-bit operation, before they added the "64" to the name. IIRC, the main difference between it and the early Athlon 64 is the size of the L2 cache. 

That, and because my motherboard only allows 2GB of RAM, are two of the reasons I have been confining my operations to 32-bit. No real advantage to going to 64-bit for me. Yet.

cpuinfo:

processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 44
model name      : AMD Sempron(tm) Processor 3100+
stepping        : 2
cpu MHz         : 1800.000
cache size      : 256 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow pni lahf_lm vmmcall
bogomips        : 3600.16
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

Yep, that's the Amd Palermo that brought 64bit to Semprons :)

Has worked like a champ since I bought it and the motherboard on eBay from a recycler in 2010. Replacement for a failing Biostar Socket 7 motherboard.

Could this be added to the errata for the time being?

@doc team: Could you document this issue in the Errata, and then decrease the priority of this bug?

CC: (none) => doc-bugs

(In reply to Rémi Verschelde from comment #69)
> @doc team: Could you document this issue in the Errata, and then decrease
> the priority of this bug?


@ MrsB
Do you mind doing that? You know this bug and won't need to read over 68 comments to decide what to add

CC: (none) => marja11

Dropping release_blocker status, it should still be added to the errata though.

Priority: release_blocker => Normal

my first job in the morning

BTW does the same bug affects FC & Ubuntu installers?

Whiteboard: FOR_ERRATA => FOR_ERRATA NEEDINFO

What are they? :D

I'll download and give them a go.

BTW someone should check what mode is used by other distros.
Eg FC doesn't set a mode and rely on X auto picking a driver between modesetting/fbdev/vesa.
So it probably ends with:
- "modesetting" on amd/cirrus/intel/libvirt/matrox/nouveau/lvia/vmware
  (risky!)
- "vesa" on other !UEFI machines (eg: VBox)
  (for us that would mean no more screenshots b/c we use fb2png)
- and probably with "fbdev" on UEFI.

Dunno about other distros.

On the other hand, Claire, could you report the issue upstream at https://bugs.freedesktop.org/ against xorg fbdev driver?
It looks like fbdev doesn't use the right RGBx representation when it paints the cursor over the framebuffer.

Happy to do so Thierry but no idea really what to report :\

Already in errata.

Whiteboard: FOR_ERRATA NEEDINFO => NEEDINFO
CC: (none) => filip.komar

Can we check this bug for Mageia 6 ?

I'll need to set up that system again, but plan to anyway. Will do asap and fit it with an ssd. It can be dedicated to the purpose then.

Problem still exists in sta1 64bit stage2.

Keywords: (none) => 6sta1

(In reply to Anne Nicolas from comment #78)
> Can we check this bug for Mageia 6 ?

(In reply to claire robinson from comment #80)
> Problem still exists in sta1 64bit stage2.

Keep it in the Mga6 release critical tracker? Or can it be moved to a Mga7 tracker?

If it's just me then feel free Marja. Will stick with i586 on that system. It's quite a legacy system now, but all my hardware is unfortunately.

I think this bug is obsolete. Should we close it?

It is very old.

If problem is seen again, please open a fresh bug.

Status: NEW => RESOLVED
Resolution: (none) => OLD
CC: (none) => fri