Looks similar to https://bugs.mageia.org/show_bug.cgi?id=11928 somehow ...

CC: (none) => doktor5000
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=11928

and in rescue / failsafe mode ?

CC: (none) => tmb

Could you please tell me how to access failsafe mode from the live DVD?

(In reply to Manuel Hiebel from comment #2)
> and in rescue / failsafe mode ?

Same result. I used the "Safe settings" option from the boot screen; hope that was the right way.

When it gets stuck at this point are you able to get a login prompt if you press ctrl-alt-f2 or f3?

I was able to get a login prompt using Alt+f2.

However, I'm an end-user and didn't know what to do at this point other than "startx", which failed. "Connection error" and a number of files not found.

If this is so reminiscent of that other bug from M4, what was tried that time that resolved the issue?

So it sounds as if it's X not starting. 

If you add xdriver=radeon kernel option, does it help?

Using the xdriver=radeon option, I get through the language, keyboard and time zone selection process, then the "Oh no!" screen and we're dead in the water at that point.

I have the same sort of problem, but not the same error messages in Description except for the "ipv6 BROADCAST matching" one; *just for Gnome*, KDE gets through this to install OK. This has been true for all M5 pre-releases up to Beta3
.
It looks as if this is related to AMD/ATI/Radeon graphics. Mine is HD 7310.

I raised a similar bug 15283 in error, should that be marked as a duplicate of this one?

CC: (none) => lewyssmith

I do not know the compile option in the shorewall and kernel, but I see that is relationed, I will try download Gnome Live DVD and see what is happening, in a older Compaq Presario, I have the same error even this does not block or break the boot process.... but I do not used Live DVD I used the Clasical DVD 32 Bits....

CC: (none) => neoser10

I got the same results from a boot after using the classical installer. 64 bit though.

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

Exact same problem here with Mageia-5-beta3-LiveDVD-KDE4-x86_64-DVD on an Asus A53S with i5-2450M CPU. Given the list of comments I suspect it is unnecessary to add that I tried different kernel options to be sure . . . .

CC: (none) => waterbearer54

I have just tested and reproduced this bug in Mageia 5 beta 3. GNOME, 64-bit, using both default and xdriver=radeon kernel options as suggested earlier. No deviation from the symptoms above.

Colin can you have a look on that one as you already worked on it fir Mageia 4? Thanks !

CC: (none) => mageia

(In reply to Alan Augustson from comment #14)

Hi Alan, you changed the status from "New" to "Assigned" - this is actually only intended for the Assignee, to indicate that he is actually working on this bug. Only changing the status will not help anything, but may confuse the Bug squad.

Assignee: bugsquad => mageia
Status: ASSIGNED => NEW

Inadvertent click. Sorry for any inconvenience.

What is the status on this bug? Is it still valid in the current RC ISOs?

CC: (none) => remi

No activity here. For a "release blocker" I'm not sensing much urgency. I guess not enough chassis are affected.

I have just tried to boot the latest Mageia 5 RC Gnome Live x64 DVD
 Mon Mar 16 00:30:00 CET 2015
on real EFI hardware, AMD/ADI/Radeon HD 7310 video. It *still* blocks on:
"xt_addrtype: ipv6 does not support BROADCAST matching"
so remains a bad problem for this particular ISO.
This has not happened with the KDE Live DVDs which run & install fully.

So same kernel and drivers...

For Lewis it  sounds like the Gnome "OH no..." bug

can you remove any: "vga=... splash quiet" from kernel command line to hopefully catch more error messages

(In reply to Thomas Backlund from comment #21)
> can you remove any: "vga=... splash quiet" from kernel command line to
> hopefully catch more error messages

I've already tried that. That kernel option change is what gets me as far as the "Oh no" screen, after accepting my language and keyboard settings.

Will try to test this on the RC later today.

Whoops, my bad. Looks like we're still on B3.

Hi reporter can you test it using RC isos ?

(In reply to Anne Nicolas from comment #25)
> Hi reporter can you test it using RC isos ?

He won't as he does not have access yet to the internal testing ISOs.

Alan, if you want to test the current (unreleased) build of the RC, you'll have to add yourself to the QA ISO testers list: https://wiki.mageia.org/en/QA_ISO_testers
Then I can forward you the information about how to get the ISOs.

Is there a fix that needs testing, or is this just for verification?

I'm on the list.

There is no singled-out fix since the issue is not perfectly diagnosed yet AFAICT, but they were lots of changes since Beta3, so it would be nice to have a status update before going further into debugging.

I've sent you the instructions to get the ISOs by email, feel free to ask if it's unclear.

Trying Gnome x64 Live DVD RC Tue Mar 24 00:30:00 (rsync'd Wed 25th)
on real EFI h/w with AMD/ATI/Radeon graphics, via USB of the ISO contents.
No progress, still stopping on:
 "xt_addrtype: ipv6 does not support BROADCAST matching".

In reply to Comment 21: there is no possibility of editing the kernel command line from the EFI boot menu.

(In reply to Lewis Smith from comment #30)
> Trying Gnome x64 Live DVD RC Tue Mar 24 00:30:00 (rsync'd Wed 25th)
> on real EFI h/w with AMD/ATI/Radeon graphics, via USB of the ISO contents.
> No progress, still stopping on:
>  "xt_addrtype: ipv6 does not support BROADCAST matching".

this one is harmless...

> 
> In reply to Comment 21: there is no possibility of editing the kernel
> command line from the EFI boot menu.


Oh but you can... it' grub2, just press "e" for edit :)

Tested using the RC ISOs.

Absolutely no deviation in results.

(In reply to Thomas Backlund from comment #31)
> > No progress, still stopping on:
> >  "xt_addrtype: ipv6 does not support BROADCAST matching".
> this one is harmless...
Disagree. It stops booting the Gnome Live ISO (or installing directly from the boot menu)!

> > In reply to Comment 21: there is no possibility of editing the kernel
> > command line from the EFI boot menu.
> Oh but you can... it' grub2, just press "e" for edit :)
Thanks for the tip.

(In reply to Lewis Smith from comment #33)
> (In reply to Thomas Backlund from comment #31)
> > > No progress, still stopping on:
> > >  "xt_addrtype: ipv6 does not support BROADCAST matching".
> > this one is harmless...
> Disagree. It stops booting the Gnome Live ISO (or installing directly from
> the boot menu)!

No it does not. 
It's just the last informational message printed before the real reason for the lockup.

Created attachment 6176 [details]
journalctl output for boot when X server fails to start

I think I'm seeing the same bug as Lewis (but probably not the same as Alan). I have an up-to-date Cauldron install, using the Cinnamon desktop. When using LightDM, the X server starts using either the radeon or the fglrx driver. Using GDM, it still starts with the radeon driver, but not with the fglrx driver. Attached is the journal from the failing combination. This looks to be the important bit:

  (II) Loading /usr/lib64/xorg/extra-modules/libglx.so
  (II) Module glx: vendor="Advanced Micro Devices, Inc."
  compiled for 6.9.0, module version = 1.0.0
  /etc/X11/X: symbol lookup error: /usr/lib64/xorg/extra-modules/libglx.so: undefined symbol: LoadExtension

LightDM still puts the X server log in /var/log/Xorg.0.log, which includes the first three lines above, but not the symbol lookup error message.

This is with a Radeon HD 7850.

CC: (none) => mageia

Just tried again with the 1st April 2015 Live Gnome x64 DVD (booted on a real EFI box from USB).
Same result as ever, stopping on:
 "xt_addrtype: ipv6 does not support BROADCAST matching".
Virtual consoles *are* available after the blockage. Is there anything I can look for?

Since Shorewall has been mentioned in connection with this bug, a few lines before that cited above were:
"[OK] Started ip6tables Firewall for IPv6
 [OK] Started iptables Firewall for IPv4".

We all seem to have AMD/ATI/Radeon video.

In reply to Comment 21
> can you remove any: "vga=... splash quiet" from kernel command line
> to hopefully catch more error messages
there was no such string to remove.

(In reply to Lewis Smith from comment #36)
> Virtual consoles *are* available after the blockage. Is there anything I can
> look for?
> 
You could check the journal to see if you are getting the same error I am. As root:

  journalctl -b 0 | grep LoadExtension

should show it.

Doing just [was unsure of -b O or 0, and b is not in the man page]
 # journalctl | grep LoadExtension
gave 6 quasi-identical lines of the same final error msg:-
"localhost gdm-Xorg-:n[nnnn]: /etc/X11/X: symbol lookup error:
 /usr/lib64/xorg/extra-modules/libglx.so: undefined symbol: LoadExtension"
n = 0-5.

(In reply to Lewis Smith from comment #38)
> Doing just [was unsure of -b O or 0, and b is not in the man page]

Odd - it's there in the man page I'm looking at. It's the number 0, which gives the journal entries for the current boot.

Anyway, I think that confirms we are looking at the same bug. The reason I think Alan may be seeing a different issue is that he reported problems with all desktops, whereas you and I only see problems when using gdm and gnome-shell.

A probable explanation of the bug Lewis and I are seeing can be found here:

  http://oliverchang.github.io/2014/12/22/fixing-linux-amd-catalyst-linux-drivers-gdm/

Since I use almost exclusively Gnome-Shell, my testing of the KDE version was more cursory, and I forgot to test KDE at all for Beta 3 and the RC. I'll try to get to that today.

Regarding the info at Martin's link, what matter is the AMD Catalyst Driver to the Live boot process, since at that point you're using either radeon or some other OSS driver? I could be missing the point.

(In reply to Alan Augustson from comment #41)

> 
> Regarding the info at Martin's link, what matter is the AMD Catalyst Driver
> to the Live boot process, since at that point you're using either radeon or
> some other OSS driver? I could be missing the point.

Live medias comes with nonfeee nvidia/amd gpu drivers installed by default.

One way around this would be to not install the fglrx drivers by default on Gnome live medias, but instead keep them in "Live Nonfree" media on iso for those wanting to play with fglrx after install.

Atleast until amd fixes the crappy fglrx (by the rate amd is going, that would probably mean mga6)

Unfortunately the free radeon driver is even more crappy when used with my card - it has a number of rendering bugs - so I'm stuck with using fglrx.

A couple of ways round this issue:

  - patch fglrx as described in the link I gave (a bit ugly, but it
    does tackle the issue at source)

  - patch gdm to fall back to the old logging method (/var/log) if
    fglrx is being used

I'll do some tests this evening to see what does or doesn't work.

(In reply to Martin Whitaker from comment #43)
> Unfortunately the free radeon driver is even more crappy when used with my
> card - it has a number of rendering bugs - so I'm stuck with using fglrx.
> 

Yes, but it could maybe be useful for getting the live medias to boot at all on your hw.

> A couple of ways round this issue:
> 
>   - patch fglrx as described in the link I gave (a bit ugly, but it
>     does tackle the issue at source)

Not an option for Mageia. the fglrx license prohibits altering stuff
shipped by Amd in binary form....

> 
>   - patch gdm to fall back to the old logging method (/var/log) if
>     fglrx is being used
> 

sounds fragile...

> I'll do some tests this evening to see what does or doesn't work.

I wonder if the 15.3 beta driver behaves any better

Created attachment 6204 [details]
Patch to fix bug by generating X server log file in /var/log

This patch to gdm fixes the bug for me. Rather than try to do anything clever, it simply stops gdm from redirecting the X server log file to /dev/null.

Note that with this patch, the X server log is also stored in the journal. If you want to prevent this duplication, you could configure gdm with the --disable-systemd-journal option (and not need this patch). I've not tested this, though.

Patch added in gdm. To be tested in coming isos

I look forward to testing when the ISOs are ready. Thanks everyone; crossing my fingers...

I'm gonna log this here rather then starting another bug.
I think it's the same problem.

M5RC i586 install from boot.iso
04/02/15 20:46
MD5SUM: 050b61aa950b06ae3c2c98dee8457cc0

I've installed this three times. Twice in Vbox and once
on real hardware. All three resulted in an unbootable
install. It never even got started. The computer saw
nothing to boot to. On Vbox it went back to the boot.iso
file and started all over thinking there was nothing
on the drive. I selected GRUB2.

CC: (none) => wilcal.int

William, I'm *definitely* not the resident expert, but intuitively that "feels" like a different problem. In my/our case the computer did at least recognize the bootable system and at least began the boot process. We're pretty sure now that this one is related to the use of AMD graphics hardware.

(In reply to William Kenney from comment #48)

> I'm gonna log this here rather then starting another bug.......

I have created:

https://bugs.mageia.org/show_bug.cgi?id=15645

Good news at last; important progress.

Playing with the Gnome Live DVD M5 RC dated 10 April 2015, on x64 EFI real hardware, booting that from USB stick rather than DVD, the boot process completed for the first time for me with Mageia 5.
I chose the 'Live from USB' boot menu option, that worked at least enough to install from the Gnome sidebar. *That* went to end OK, and the resulting system booted & basically works OK. I am writing from it.

As far as I am concerned, this bug at least is now resolved. Let others confirm.

I need a new link to the RC iso.  :(

Please disregard that. Found the correct procedure.

Nope. Every option I could think of to try, led to the "Oh no" screen.

Only now the "Oh no" screen has the "Mageia Welcome" panel over it.

Keyboard and mouse are completely unresponsive at that point; no option but to power down.

Disappointing, but I did suspect you were seeing a different bug to us.

If you tested this by installing, can you boot successfully in failsafe mode? If so, login as root, and assuming the "Oh no" happened on the previous boot, type

  journalctl -b -1 > lastboot.log

and save the resulting lastboot.log somewhere you can get at it later to attach to this bug report.

(In reply to Alan Augustson from comment #54)
> Nope. Every option I could think of to try, led to the "Oh no" screen.
> 
> Only now the "Oh no" screen has the "Mageia Welcome" panel over it.
> 
> Keyboard and mouse are completely unresponsive at that point; no option but
> to power down.

This looks more like: https://bugs.mageia.org/show_bug.cgi?id=15653

Can you test a gnome 586 iso to confirm it only happend on x86_64 for you too

(In reply to Martin Whitaker from comment #55)
> Disappointing, but I did suspect you were seeing a different bug to us.
> 
> If you tested this by installing, can you boot successfully in failsafe
> mode? If so, login as root, and assuming the "Oh no" happened on the
> previous boot, type
> 
>   journalctl -b -1 > lastboot.log
> 
> and save the resulting lastboot.log somewhere you can get at it later to
> attach to this bug report.

I tested using the Live DVD. Don't have space to spare for a test install.

(In reply to Thomas Backlund from comment #56)
> (In reply to Alan Augustson from comment #54)
> > Nope. Every option I could think of to try, led to the "Oh no" screen.
> > 
> > Only now the "Oh no" screen has the "Mageia Welcome" panel over it.
> > 
> > Keyboard and mouse are completely unresponsive at that point; no option but
> > to power down.
> 
> This looks more like: https://bugs.mageia.org/show_bug.cgi?id=15653
> 
> Can you test a gnome 586 iso to confirm it only happend on x86_64 for you too

Hard to say. These results mimic those I was previously getting, when I would try the boot with the xdriver=radeon option. The only difference being the Mageia Welcome panel. Is it possible this patch allowed me to progress through this bug, onward to that?

-- Oh... and would that be possible, to boot the 586 iso on a 64-bit machine? I've seen distros that wouldn't permit that...

(In reply to Alan Augustson from comment #58)

> Is it possible this patch allowed me to progress
> through this bug, onward to that?

Yes, the patch "fixes" the issue you reported initially in comment 0: 
"And boot simply ceases at that point."

The "Oh no..." part is more of  bug 15653

(In reply to Alan Augustson from comment #59)
> -- Oh... and would that be possible, to boot the 586 iso on a 64-bit
> machine? I've seen distros that wouldn't permit that...

Yes, 32bit installs are supported on 64bit hw.

Testing the 586 ISO gives the "Oh No" screen, but without the Mageia Welcome over it.

If this is Bug 15653, then either M5 is in trouble or I am. They're reporting that one as "fixed" also, so I'm guessing it will not be addressed further.

As I said there, I am only an end-user, so I know little other than when something works, or doesn't. Sorry if I've been less than helpful.  :(

Alan, one thing you could try, which has worked for me in the past, is to try switching to a text login before the "Oh no" screen appears. There's only a short window of opportunity to do this - the pseudo-ttys only become available around the same time as the X session is started. The easiest way I found was to remove the "splash quiet" from the boot command line, wait for the screen to switch from rolling text to graphics mode, then repeatedly press Ctrl-Alt-F2. Note that you need to press and release all three keys - if you hold down Ctrl and Alt and just press F2, you may have pressed Ctrl and Alt before the X server keyboard handler has noticed them.

If this works, login as root and use journalctl to look for error messages.

Do you still have problems with the KDE live DVD, or is this now just a GNOME problem?

Confirmed it's strictly a GNOME problem.

Am I allowed to re-open the supposedly-fixed Bug 15653? And how would I be able to copy that gigantic quantity of text from journalctl, to something I can append to the Bug report?

I reopened bug 15653 and made it a blocker, let's close this one and move the discussion there if you agree.

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

I was able to get a console and run journalctl. I didn't understand a thing, but I did notice that the final [FAILED]=level error read

"xt_addrtype: ipv6 does not support BROADCAST matching"

which is what this bug was about in the first place...

I'll cross-post it to the other bug; one or the other of these is still a problem...

(In reply to Alan Augustson from comment #63)
> And how would I be able to copy that gigantic quantity of text from
> journalctl, to something I can append to the Bug report?

Find the device name of the root partition of your existing Mageia-4 installation. If you don't already know it, type

  df

in a terminal when running M4, and one of the lines should look something like this:

  /dev/sda6       16382888  6944700   8582944  45% /

Then, when you get to the root login from the M5 live DVD, type

  mount /dev/sda6 /mnt
  journalctl > /mnt/root/journal.txt
  umount /mnt

(replacing /dev/sda6 with the right device name for your M4 root partition)

When you reboot M4, you should find the file journal.txt in the /root directory.

Don't worry about the message "xt_addrtype: ipv6 does not support BROADCAST matching" - it's not important. I'm seeing it on my working M5 installation. It just happens to be the last message that gets printed out before the xsession is started.

Thanks for your help. I'll append that journal.txt file to Bug 15653.

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

CC: (none) => Damien.Genthial

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

CC: (none) => orathon.bird

I have the same error with the Mageia-6-GNOME-LiveDVD:

"xt_addrtype: ipv6 does not support BROADCAST matching"

Status: RESOLVED => UNCONFIRMED
Resolution: FIXED => (none)
Ever confirmed: 1 => 0
CC: (none) => flink

(In reply to Franz Holzinger from comment #70)
> I have the same error with the Mageia-6-GNOME-LiveDVD:
> 
> "xt_addrtype: ipv6 does not support BROADCAST matching"

As noted in comment 66, that message is nothing to worry about in itself. That you are seeing it just tells us the X server has failed to start. There are many possible reasons for that, and it is very unlikely to be the one fixed here. Please open a new bug report, describing your hardware, and saying whether you have tried the various workarounds described here

  https://wiki.mageia.org/en/Mageia_6_Errata#Non-working_graphics

and here

  https://wiki.mageia.org/en/Mageia_6_Errata#GNOME

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