As a fast workaround, maybe enable again the nonfree repo as default ?

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

sysadmin, comment ?

Severity: normal => critical

Installing non free software to users by default is not a sysadmin decision...

CC: (none) => pterjan

Maybe we should check which repos are enabled when the upgrade process starts and leave the upgraded system in the same state?  This is going to be a huge problem if we're removing installed packages on upgrade simply because they came from non-free or tainted.

(In reply to comment #0)
> "E: libkmod: index_mm_open: major version check fail: 65537 instead of
> 2953311319"
 
This seems to come from version 2.6.xx kernels still existing in grub's menu.lst file.  So it's an unrelated problem.

It can't be critical since it's like this for years (previously we weren't enabling restricted, non-free or plf media too)

ok but it was not so annoying with the old year

the "learn more about this new version" go now to the release notes which contain a warning.

Severity: critical => major

I didn't find it so critical for Mageia 1 because I was moving from Mandriva to Mageia and so I was expecting problems.  This is Mageia to Mageia, so I guess I was expecting to skip most of these issues.  I also knew that we had renamed and realigned the repos versus Mandriva.

Also, with Mageia 1 I was able to pass "radeon.modeset=0" to the kernel and get a graphical boot on the first boot.  I was not able to do that here.  I have yet to get the system to boot to KDE, even after installing the radeon-firmware package.

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

CC: (none) => derekjenn

Moving from Mageia 1 to Mageia 2 has proved to be far more difficult than it should have.
Surely the applet can be configured so that if you are using tainted/nonfree repositories prior to updating then those will be enabled during the update.

Ok understood that the 'free' philosophy might not like this - but if Mageia is going to provide these repositories then surely either continuing to use them when an upgrade happens or an option to say something like 'I notice you are using tainted and or Nonfree repositories for this distribution. Would you like to to continue using them in the new distribution?' should be possible.

CC: (none) => c138535

I did finally get the system up and running, but I had to install the proprietary ATI driver, which I had installed before, but did not upgrade because the non-free repo was not enabled during the upgrade process.

I think that ignoring the users previous decision to use non-free and therefore causing the upgrade to have problems is a big mistake.  I can fully understand not making the decision to use non-free for the user, but in the cases where the user has already chosen to use non-free, then their decision should be honored.

--Jeff

it's not that we don't want to, it's more that the code required to detect nonfree and/or tainted (backports, testing, etc...) is not that trivial:

* consider that people can have any amount and types of old and new repositories, this detection will miss often, likely resulting in worse things than this.
* it is much easier to ask the people during upgrade/install
* for the installer, i myself (maybe others) might be planning of rewriting this a bit to make it more transparent
* perhaps for mgaapplet, this can be done the same.

so, imho it's more a feature than a bug, even though it's a feature that will likely solve this "bug" and others like it.

I can only encourage you to participate in Mageia, so that we have more time to implement features like this. (bugsquad or QA or doc or i18n or ...)

I'm currently going through the packaging mentoring, so I'm trying to do my part. :)

awesome :)

Added tainted repo to this bug, because the applet not respecting existing choices for nonfree *and* tainted is on doktor5000's list the most reported issues in the forums.

Solving this for tainted at the same time as for nonfree will probably not be a lot of extra work

CC: (none) => doktor5000, marja11
Summary: mgaapplet-upgrade-helper removes nonfree repo (and so radeon-firmware) when upgrading to Mageia 2 => mgaapplet-upgrade-helper removes nonfree and tainted repo (and so radeon-firmware) when upgrading to Mageia 2

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

this problem should verify also in mageia 3 upgrade, right?

I don't see any info on any changes that were done, so I would assume so.  Unfortunately I don't have a box I can test this on right now.  I do have a virtual machine, but it shouldn't require any non-free drivers.

--Jeff

Media names are stable between release (at least currently) so it should not be hard to keep a hash media name => status and re-enable them.

This message is a reminder that Mageia 1 is nearing its end of life. 
In approximately 25 days from now, Mageia will stop maintaining and issuing 
updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it 
remains open with a Mageia 'version' of '1'.

Package Maintainer: If you wish for this bug to remain open because you plan to 
fix it in a currently maintained version, simply change the 'version' to a later 
Mageia version prior to Mageia 1's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not 
be able to fix it before Mageia 1 is end of life.  If you would still like to see 
this bug fixed and are able to reproduce it against a later version of Mageia, 
you are encouraged to click on "Version" and change it against that version 
of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, 
sometimes those efforts are overtaken by events. Often a more recent Mageia 
release includes newer upstream software that fixes bugs or makes them obsolete.

--
Mageia Bugsquad

without any testing, i'm pretty sure that mga2 => mga3 upgrades will have the same issue.

yep

Version: 1 => Cauldron
Whiteboard: (none) => MGA2TOO MGA1too

Created attachment 3075 [details]
Patch to re enable Tainted and Non Free repos on upgrade


If we do not fix this bug before mga3 comes out then we will have lots of users complaining they have no X server after the upgrade again.

I have taken a look at it and produced this patch.
It simply checks if Tainted or non free repos are already enabled, and re-enables them if they are.

I have tested it on an mga1 to mga2 upgrade.

Thierry can you check it please ?

See also bug 8368

Whiteboard: 3alpha3 MGA2TOO MGA1too => 3alpha3 3beta1 MGA2TOO MGA1too

Will a fix for this make it into 3beta2 do you think? 
We should begin testing with it, if possible.

thank you Derek! i have a mga2 and mga1 system ready to make the upgrade test, if you provide this patch with an update (both for mga1 and mga2) i can upgrade the systems and let you know the issues that still remain. please, let me know


cheers
Marcello

is there an easy way to have this patch working? i would like to switch to beta 3 (and cauldron) but without this patch it's quite sure i will have problems... if thierry hasn't enough time to test it, is there anyone who can suggest me how to apply it to my system? thanks

(In reply to comment #27)
> is there an easy way to have this patch working? i would like to switch to beta
> 3 (and cauldron) but without this patch it's quite sure i will have problems...
> if thierry hasn't enough time to test it, is there anyone who can suggest me
> how to apply it to my system? thanks

Applying the patch to Mageia 2 will not help you upgrade to Cauldron
mgaapplet-upgrade-helper is only activated when the mirrors contain a flag saying an upgrade is available.  That will only happen when Mageia 3 gets officially released. Until then the only way to test this patch is on an upgrade from mga1 to mga2.

If you want to migrate to Cauldron, then you should use the Mga2 Beta2 DVD and select 'Upgrade',
See https://wiki.mageia.org/en/Mageia_3_beta2#Upgrading_from_Mageia_2

Upgrading from the DVD will not use the 'tainted' repository, but should (I think) install packages from 'nonfree' (maybe).

sorry that should be "Mga3 Beta2 DVD"

does 'killall mgaapplet && mgaapplet --testing' allow you to test Derek or does it need a flag to be set on the api before that works?

(In reply to comment #30)
> does 'killall mgaapplet && mgaapplet --testing' allow you to test Derek or does
> it need a flag to be set on the api before that works?

The --testing switch causes mgaapplet to retrieve a different file from the mageia server.
It fetches https://releases.mageia.org/api/a/testing-x86_64?product=Default&version=2&mgaonline_version=2.77.33  while without the testing switch it fetches https://releases.mageia.org/api/a/x86_64?product=Default&version=2&mgaonline_version=2.77.33

So yes. The --testing switch can be used to test upgrades to Mageia 3, but the file on the server would have to be updated first. I suppose Anne would have to do that.

cf: http://svnweb.mageia.org/web?view=revision&revision=1027 too

so, in conclusion i should install mageia 3 beta2 and upgrade using this urpmi comand:

killall mgaapplet && mgaapplet --testing

right? is it more useful for you the testing in this development phase or later?

mgaapplet-upgrade-helper --testing was working and needed repo was here after patching /usr/sbin/mgaapplet-upgrade-helper

(additionally  I changed the api to an updated localed copy of https://releases.mageia.org/api/a/testing-x86_64 )

Blocks: 3342 => (none)
Whiteboard: 3alpha3 3beta1 MGA2TOO MGA1too => 3alpha3 3beta1 MGA2TOO

Created attachment 3622 [details]
subroutine to enable media

Here is a revised proposed patch to enable Nonfree and Tainted media if they were previously already enabled. This file contains a subroutine any::urpmi_enable_media() which can be reused by other patches to fix all the other cases when Nonfree media needs to be enabled such as Bug 8368 and Bug 8379

Attachment 3075 is obsolete: 0 => 1

Created attachment 3623 [details]
patch to enable media if they were previously enabled

This patch calls the subroutine in attachment 3622 [details] to enable nonfree and tainted media if they were previously enabled before the upgrade.

Thierry, can you have a look on that patch and integrate it for coming beta 4 ?

any news about this bug? i would like to make the upgrade trying to use as few hacks as possibile, in order to find the issues that encounters a normal user.. thanks

Thierry can you have a look on it so that we can include it in RC ?

Created attachment 3876 [details]
enable nonfree/tainted during upgrade

improved & cleaner patch against trunk, needs to be backported and tested.

Attachment 3622 is obsolete: 0 => 1
Attachment 3623 is obsolete: 0 => 1

@Derek: please backport and test this new patch to see if it still works for you.

Created attachment 3878 [details]
Patch from comment 40 modified to work with current testing version

I had to modify the patch, to get it to install the 2nd chunk.

I either did something wrong, or it isn't working.

The upgrade is still running, but the tainted and nonfree repos
were not enabled, though they were before starting the upgrade.

I also still had to manually install the upgrade package, and delete the
/var/lib/rpm/__ files after the first transaction.

CC: (none) => davidwhodgins

Would probably be a good idea to add the debug repos, if they were
previously enabled.  That would make getting good gdb traces when
testing the upgrade easier.

the backport looked ok; i don't know why it doesn't work...

oh gods, i seem to have typed Tainted instead of Updates at the last part /o\ (as pointed out to me by coling...

@Dave, can you possibly change Tainted to Updates and retry? (also in your backported patch)?

on second thought, talking with coling, it'll indeed be better for updates and testing and the like to work as well.

i'm gonna redo the patch to check exact names, so that ALL enabled before, will be enabled AFTER, no matter which are selected...

FWIW Dave, you *should* (in theory) be able to let mgapplet guide you through everything if you just enable the updates_testing repo and make sure you have the latest mgaapplet package (from that repo). You need to leave it enabled such that it will be able to install mageia-prepare-upgrade package for you. You also have to set the TEST_DISTRO_UPGRADE=YES flag in /etc/sysconfig/mgaapplet too tho'.

Created attachment 3904 [details]
enable nonfree/tainted during upgrade

haven't had time to test or even typo-check this yet, but this is what i had in mind...

Attachment 3876 is obsolete: 0 => 1

Created attachment 3914 [details]
mgaapplet enable nonfree tainted during upgrade

new patch

Attachment 3904 is obsolete: 0 => 1

Created attachment 3915 [details]
mgaapplet enable nonfree tainted during upgrade backported for mga2

Attachment 3878 is obsolete: 0 => 1

Created attachment 3916 [details]
Working patch

Figured out the problem with the prior patch. The code to
actually add the repos was inside of the if ($add_pwp_auth)
statement.

This patch is working.

Created attachment 3935 [details]
mgaapplet enable nonfree tainted during upgrade for mga2

new version of the patch which enables ALL repositories which were enabled before. This one checks on relative url path, so the name will not matter.

Testing shows that this works.

don't know which of the versions is the one we should take though... this needs to be discussed.

Attachment 3915 is obsolete: 0 => 1

My test using attachment 3395 [details] is not working.  Only Core repos are
enabled, though Tainted and Nonfree were enabled prior to starting
the upgrade.

:-( ... let's just use the simple working version instead.

@Thierry: can you take a look at the working patch and improve/commit it?

CC: (none) => thierry.vignaud

OK, I've committed this patch now (slightly tweaked to only run update_media() if we've actually changed something).

I've submitted the updated version to updates_testing, no cauldron release yet.

CC: (none) => mageia

As for Colin, I've just run a full upgrade test:
Mageia 2 x86-64 full KDE environment using nonfree and tainted repositories

All went well with all needed active repositories.

Fixed for me

OK, so just for clarity, the fix is in mga2's updated mgaonline, but not yet in a released version of cauldron/mga3's mgaonline (it's in svn)

I didn't look whas was pushed on mga2 but https://bugs.mageia.org/attachment.cgi?id=3935&action=diff#mgaapplet-upgrade-helper.orig_sec3 and --nocheck seems not to exit according to the help of urpmi.update

(in mgaapplet log: Unknown option: nocheck )

@Manuel

This is what when into svn:
http://svnweb.mageia.org/soft/mgaonline/trunk/mgaapplet-upgrade-helper?r1=8220&r2=8219&pathrev=8220

and what was ultimately pushed to mga2.

Is that OK for you?

sorry it was s/exit/exist in my previous post

Well ok, as it seems to be only cosmetic, it's fine for me of course.

@Manuel ahh I see the bit you were referring to now. Note that the --nocheck argument there is in the patch context, i.e. it's not a change in this patch just the surrounding code.

You are correct tho', that --nocheck is unrecognised by urpmi.update and it should ultimately be removed from mgaonline code. Having checked locally it seems not to get in the way so we don't need to worry about it too much.

Anyway, as we've had a few tests now, I think we can close this bug as fixed (as per bug #8157 I've marked this bug as blocking bug #9744 which will be used as a tracker to actually push the update).

Status: ASSIGNED => RESOLVED
Depends on: (none) => 9744
Resolution: (none) => FIXED