What are the most desired installation tests for STA-2 ?

[rickst29]

Hi. I've got a system with two hard drives, one containing MGA-5.1. The other is the same size, and I can use dd to make an exact copy into the second drive as many times as we would like to do that.

Option 1: Should I simply install to SDA2 without any attempt to upgrade an existing 5.1 install, verify that my fairly normal hardware works OK on that installation? I don't think that we'd learn anything new:
I'm using "Live KDE" right now, from USB, with no obvious issues yet. (I have a 2650x1440 screen, AMD A8 APU, and graphics came up fine - no "unwanted relics" of 1920x1080 stuff appeared.)

Option 2:: Attempt upgrade from the "Live" USB, with 5.1 already on the target disk (with a fairly complex large KDE-4 user config already present).

Option 3: Attempt online upgrade, with either MGA-6 media alone (MANY packages will fail to upgrade, if that's considered a bug and we don't have a complete listing yet). Or with MGA-6 media configured first, and 5.1 Update+Backport Media configured second?

Please advise. My existing 5.1 is remarkably "fat", containing somewhat more than 2000 packages.

[Lebarhon]

Hello,

Somebody reported a crash after having chosen "erase and use entire disk" at the partition step. This option isn't easy to test because you need a disk totally available. If yo could check this, thanks a lot.
Take care, if you have several disks, this option use them all, think to unplug the spare one.

[rickst29]

Hello,

Somebody reported a crash after having chosen "erase and use entire disk" at the partition step. This option isn't easy to test because you need a disk totally available. If yo could check this, thanks a lot.
Take care, if you have several disks, this option use them all, think to unplug the spare one.

I got "Works-for-me" in two simple tests.

First test, with just a single disk in the system (already containing some data): Defaulting all GUI choices, It worked fine. (Erased the disk, and created two ext4 partitions + one swap partition, proceeded to finish the install.)

Second test, with two "scratch" disks in the system: I chose one of them as the 'target disk', in the GUI pull-down, defaulted everything again, and it worked again.
But it DID NOT use both disks, and I was not offered "use all hard disks" in the GUI pull-down menu. The unused disk (mounted by "Live" USB as SDA1) was not modified.

I can imagine two other ways that the Problem Reporter could still have trouble: #1 partitioning might have failed due to a disk hardware problem. And #2, if he went into "custom" and chose non-default filesystem types, or spread the install on to multiple disks, he may have found a defect which I did not look for.
But default behavior of "erase and use the whole disk" worked well, and it did not use both disks.

[benmc]

Hello rickst29

Option 2:: Attempt upgrade from the "Live" USB, with 5.1 already on the target disk (with a fairly complex large KDE-4 user config already present).

Unfortunately, the Live will not support an upgrade.

For upgrade you will need to burn a Classical installer of either x86_64 or i586, same as your existing system.
Or use the net installer to do the upgrade. Obviously, a reliable and fast internet connection is required for this.

Not sure if has been fixed yet but you may strike : https://bugs.mageia.org/show_bug.cgi?id=20111.
accept the info, and continue the upgrade.

best regards

[Lebarhon]

But default behavior of "erase and use the whole disk" worked well, and it did not use both disks.

Thanks again to confirm that. The other guy, on the French MLO forum said the installation crashed and his both disks have been formatted. As Cauldon has had a formatting bug, it is good to be sure everything is OK.

[rickst29]

For upgrade you will need to burn a Classical installer of either x86_64 or i586, same as your existing system.
Or use the net installer to do the upgrade. Obviously, a reliable and fast internet connection is required for this.

Thanks, benmc: I will try both ways.

My first pass with "urpmi --auto-update -auto" had interesting and fatal results. (I will try again over the weekend, because I did only one "pass" before attempting restart -and the network did not come up to perform a second "pass"). Interesting things:

#1 (while running on MGA 5.1): After stepping back to runlevel 3, the command refuses to execute on a wireless connection. So, as a bypass, I stuck a "wireless bridge/repeater" in the middle, and plugged in a cat5 cable: That allowed urpmi to proceed (even though the hidden "upstream link" was still wireless). Perhaps wireless becomes unusable in runlevel 3, due to interference from NetManager: "ifconfig -a" showed both links up, and running keep-alive packets in both directions without error. But "ifconfig <interface> down" and "ifconfig <interface> up could not reset either the wired or wireless connection - they simply stayed active with packet counts continuing to increment. Edit 2017-03-12: My router was running with bad "bridge" definitions. No problem exists with using urpmi on the network, at runlevel 3.

#2 (While operating on the first ~700 RPMs within MGA 5.1): The RPM for lib64 samba didn't want to go in, because it had a file conflict with another library, a "lib64netapi0". I'll SWAG that the new Samba Library probably contains all the files of the old RPM, which it should delete upon upgrade to the "bigger" RPM. (I deleted the conflicting RPM by hand, and the new Samba library RPM installed successfully after doing that.) I Opened a bug, search on "lib64netapi0".

#3 During the second phase (~3700 more RPMs), I had lots of header file conflicts from "old baggage" i586 Development RPMs. I'll try replacing/removing/ all of my i586 packages before attempting online upgrade again.

#4 Probably a mistake by me: Instead of running a second "pass" under MGA 5.1, I restarted the computer - and it wouldn't connect to anywhere on either network interface - so I couldn't proceed. The breakage was probably related to a failed, partial installation of a "Network Manager" package. (Sort of like the situation in #1, but worse. No connections under either runlevel 3 or runlevel 5.)
- - - - -
Test plan:
<preparation 1> On my production MGA 5.1: Remove ALL i586 packages. (And installing any obvious x64 replacements).
<preparation 2> Clone MGA 5.1 production back to the test target disk.
<test 1> Burn the STA-2 traditional installer DVD, and run it against the target disk.
<test 2> Clone MGA5.1 production back to the test target disk, and try online "urpmi --auto-update -auto" again. But this time, repeat the command (under 5.1) until it stops installing packages.

question for test 1: should I go ahead and "Search for new Updates" at the final installer step?

[benmc]

question for test 1: should I go ahead and "Search for new Updates" at the final installer step?

At the moment, the mirrors are having large numbers of updates sync'd, so there is a high likelihood that that search for new updates will fail.

I usually find it is better to add a mirror after the reboot, for this reason.
I have just complete a single DE install myself and several $MIRRORLIST repos were unavailable, so I manually chose a mirror.

[rickst29]

I ran my "test 2" first (urpmi --auto-update --auto --verbose), install was completely successful. But starting up MGA-6-Cauldron (approx 4 AM snapshot, EU time, March 11) I experienced 2 "medium" bugs and one "minor" bug, all with workarounds:
- - - -
PROBLEM 1: KDE Init, first time, wants to switch to an incorrect video driver (I label this "medium" because it looks so bad).

Initializing runlevel 5, the DM came up nicely. But, when I chose a KDE session, something within KDE startup said that my "ATI R7 video card" was to old for the "flgrx" driver, and it wanted to revert to "ATI". The only choice in the pop-up was "OK", so I let it go ahead: Result = black screen with no mouse.

As a related test, I used the root console where I had initiated runlevel=5 to revert back down (runlevel=3), and then restarted runlevel=5. The DM came up nicely, and I chose a GNOME-3 session: That session came up fine, with compositing.

I returned to runlevel 3 (from a Gnome XTERM with root permissions) and ran drakx11. I tested and confirmed fglrx "for 6400 and later" as the driver I wanted; upon another switch to runlevel 5, a KDE session came up fine, with no complaint.

My video card: "Kaveri [Radeon R7 Graphics]" within a 2016-vintage A-10 APU. (PCI Vendor ID x1002, Device ID x130f). Perhaps it's actually too _NEW_ for KDE to understand, and KDE needs to update some internal list of valid cards?

PROBLEM 2, also "medium": Within a Gnome-3 session, the "shutdown/restart" Panel offers only "shutdown", "restart", "cancel" -- there's no choice for "logoff". (The same panel appears via icon and via Ctrl-Alt-Del). I have no convenient workaround for this, other than switching runlevel down and back up from an xterm.

PROBLEM 3, IMO "low": When KDE's first run migrates a KDE menu, MenuItem "firefox" is left with an old kde4-only "command" trying to run the executable as an argument. That command needs to be stripped off, leaving just "firefox %u".

[benmc]

PROBLEM 2, also "medium": Within a Gnome-3 session, the "shutdown/restart" Panel offers only "shutdown", "restart", "cancel" -- there's no choice for "logoff". (The same panel appears via icon and via Ctrl-Alt-Del). I have no convenient workaround for this, other than switching runlevel down and back up from an xterm.

at the top right of the screen, when you click on the power "button" your user name should be listed in the small window.
clicking on your user name should bring up an offer to logout.

for your other problems, 1 + 3, please check bugzilla, to see if the issues have been reported.
if not, please create a bug report.
when triage reply, please endeavour to supply any info requested.

best regards

[rickst29]

got it, thanks! (GNOME logoff)

[rickst29]

First, it generated the same Samba error. A little bit later (perhaps 40 minutes....) it generated a fatal error which said something like "unable to upgrade GLIBC".... which IMO is a pretty major problem. It also refused to quit, and wouldn't even respond to Ctlr-Alt-Del. I had to power off. According to the processing time estimate and the bar graph, this was only about 5% into the job. (Estimated at 15-18 hours).

Another thing: Does MGA-6 LSB still require qt3 ? The traditionl installer kept it. I didn't look at the qt libraries present after my "online upgrade", but a system with qt3 AND qt4 AND qt5 seems a bit "ugly". Should I remove LSB?