Fresh x86_64 install from full cauldron tree, select Custom Desktop, all repositories including non-free and tainted, then select every install package category. The install fails due to missing packages or conflicts. From ddebug.log: * ERROR: selection failed: hylafax+-5.5.8-1.mga6.x86_64 (due to conflicts with mgetty-sendfax-1.1.37-1.mga6.x86_64) krb5-appl-servers-1.0.3-8.mga6.x86_64 (due to unsatisfied /usr/sbin/service[*]) libmariadb-devel-10.1.13-1.mga6.i586 (due to unsatisfied mariadb-client(x86-32)[>= 10.1.13-1.mga6], due to unsatisfied mariadb-client(x86-32)[*][>= 10.1.13-1.mga6], due to unsatisfied mariadb-common(x86-32)[*][>= 10.1.13-1.mga6], due to unsatisfied mariadb-common(x86-32)[>= 10.1.13-1.mga6]) mariadb-client-10.1.13-1.mga6.i586 (due to conflicts with mariadb-client-10.1.13-1.mga6.x86_64, due to conflicts with mariadb-client-10.1.13-1.mga6.x86_64) mariadb-common-10.1.13-1.mga6.i586 (due to conflicts with mariadb-common-10.1.13-1.mga6.x86_64, due to conflicts with mariadb-common-10.1.13-1.mga6.x86_64) rsh-0.17-32.mga6.x86_64 (due to conflicts with krb5-appl-clients-1.0.3-8.mga6.x86_64) swi-prolog-doc-7.2.3-4.mga6.i586 (due to unsatisfied /usr/bin/swipl) If we're going to allow a set of packages in the category selections, then they ought to be conflict-free.
Thanks for the report, assigning to all packagers collectively and CC'ing the maintainers for hylafax+, krb5-appl, mariadb and swi-prolog.
CC: (none) => alien, mageia, mail, thomasAssignee: bugsquad => pkg-bugs
Priority: Normal => release_blockerBlocks: (none) => 15527
CC: (none) => wilcal.int
I've been attempting a 64-bit, Plasma boot.iso on real hardware install every couple days and each time I come up with some failed transactions. A few repeat but I think there are some that come and go. I'll try to post what I get as I go along. I think we have two open bugs for basically the same thing: https://bugs.mageia.org/show_bug.cgi?id=18413 https://bugs.mageia.org/show_bug.cgi?id=18463 I suggest we mark one of this as a dup and use that to post what we get as we go along.
Created attachment 7806 [details] M6 failed transactions during boot.iso install
Created attachment 7809 [details] M6 failed operation during boot.iso install Today the ( stage 2 ) xorg server would not even start. See attachment.
*** Bug 18463 has been marked as a duplicate of this bug. ***
Depends on: (none) => 18484, 18487CC: (none) => marja11Summary: Full network install aborts due to conflicts => [TRACKER] Full network install aborts due to conflicts and other issues
A side note. My working M6 i586 Vbox client when updated today also failed to start it's xorg server and will have to be reinstalled to get working again. I don't think I have a path to get there. :-((
(In reply to William Kenney from comment #6) > A side note. My working M6 i586 Vbox client when updated today also > failed to start it's xorg server and will have to be reinstalled to get > working again. I don't think I have a path to get there. :-(( Aren't you dropped to RL3? You only need to install libxfont1-1.5.1-5.mga6 that Shlomi pushed two hours ago, so it might already be on your mirror (see bug 18487 )
(In reply to Marja van Waes from comment #7) > Aren't you dropped to RL3? You only need to install libxfont1-1.5.1-5.mga6 > that Shlomi pushed two hours ago, so it might already be on your mirror (see > bug 18487 ) Ya I probably missed that one. I'll try again soon.
Created attachment 7816 [details] M6 failed to start xorg during boot.iso install OK rsync'd at 01:00 UTC ( 3x in succession to make sure I'm up-to-date ) rewrote boot.iso to the usb drive zero out target HD restart process and, sorry, got the same results. See attachment.
Regarding comment 9, it's likely different from bug 18487. Better more it to another bug report if we intend to use this one as a tracker.
(In reply to Rémi Verschelde from comment #10) > Regarding comment 9, it's likely different from bug 18487. Better more it to > another bug report if we intend to use this one as a tracker. Please don't, unless there's a new stage2 that still has the problem. http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/install/stage2/ mdkinst.sqfs is still the one that was created when we had the broken libxfont
(In reply to Marja van Waes from comment #11) > Please don't, unless there's a new stage2 that still has the problem. > > http://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/cauldron/i586/ > install/stage2/ > > mdkinst.sqfs is still the one that was created when we had the broken > libxfont Thierry, should stage2 be rebuilt then?
CC: (none) => thierry.vignaud
Rebuild in progress. Please don't mix different issues in the same bug report next time...
(In reply to Thierry Vignaud from comment #13) > Rebuild in progress. > Please don't mix different issues in the same bug report next time... I suppose it would have been OK to reopen Bug 18487 - Symbols not found starting Xorg: /usr/libexec/Xorg: undefined symbol: InitGlyphCaching and request a rebuild of stage2 there?
That or opening a new bug report. After all, even if it's the same root cause, the issue is not the same (system xorg vs installer stage2's xorg)
This is not an installer bug. Packages need fixing, not the installer
Component: Installer => RPM Packages
Seems to have been fixed.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Blocks: 15527 => (none)