Nemesis update april-06-2017 discussion

Arch based Porteus community project
User avatar
francois
Contributor
Contributor
Posts: 4902
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Nemesis update april-06-2017 discussion

Post#31 by francois » 23 Apr 2017, 02:05

1) I have tried to recompile a recent kernel (4.9 LTS) but it gives me acpi errors

According to falcony:
https://forum.porteus.org/viewtopic.php ... 9&start=75
Might be related to linux kernel, if it is 4.9.1:
https://bugs.archlinux.org/task/52271

At the end user reports that in 4.9.6 it is fixed.

For slackware kernel 4.9.1 here is a solution. I don't know if you can adapt to your systemd installation:
viewtopic.php?f=53&t=6688


2) Thanks for the backup advice.
We will see how ncmprhnsbl, our expert in residence in terms of arch linux will modify its updated modules. :wink:
Voltaire: Le mieux est l'ennemi du bien.

User avatar
ncmprhnsbl
Full of knowledge
Full of knowledge
Posts: 784
Joined: 20 Mar 2012, 03:42
Distribution: 3.2.2-64bit xfce/openbox
Location: australia
Contact:

Re: Nemesis update april-06-2017 discussion

Post#32 by ncmprhnsbl » 23 Apr 2017, 09:18

istinnjazz wrote: I would like to note that I have just seen significant changes to the latest update of openrc manjaro packages, there will be conflicts updating to the latest base, messages like this may come out:
thanks for the headsup :)
have managed to update the three base modules without too many dramas : viewtopic.php?f=138&t=6484&start=15#p54722
francois wrote:I don't know if you can adapt to your systemd installation

no systemd here :wink: not sure whether nekos kernel(s) include this option..
Forum Rules : http://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
francois
Contributor
Contributor
Posts: 4902
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Nemesis update april-06-2017 discussion

Post#33 by francois » 24 Apr 2017, 03:10

You are right. Really, I don't know where I had this impression. I thought that istinjazz was able to work with a systemd version of nemesis. Unless he did with the first brew of nemesis before brokenman moved from systemd to openrc. Or I dream about it. :shock:
Voltaire: Le mieux est l'ennemi du bien.

User avatar
istinnjazz
Samurai
Samurai
Posts: 114
Joined: 15 May 2016, 14:10
Distribution: Manjaro-OpenRC/Nemesis

Re: Nemesis update april-06-2017 discussion

Post#34 by istinnjazz » 24 Apr 2017, 22:10

No systemd... :Search: it is nice that ncm... can release those updates. Really good stuff. Ok ... I have a system with many packages installed as modules and savefile mixed, without any kind of organization . So for me there have been risen various issues , versions and conflicting packages. So i might have to re think of some more rodust ways to use the system.Using those updates (or a normal update) could be impossible without serious uninstallations and hacks. Probably I will have to reconfigure a bare system again. :unknown:
@francois: Acpi error is a different and a bit specific issue, but it is related with those updated acpi kernel new code. Thanks for the suggestions anyway but it is beyond this post. So for the time being no more kernels. :)

User avatar
istinnjazz
Samurai
Samurai
Posts: 114
Joined: 15 May 2016, 14:10
Distribution: Manjaro-OpenRC/Nemesis

Re: Nemesis update april-06-2017 discussion

Post#35 by istinnjazz » 25 Apr 2017, 18:43

The update strategy or system maintenance can have a new topic, I mean the general idea of using the system not really the method itself. So then some scripts can be proposed to possibly resolve some of the issues that could break the system, prevent conflicts, file versioning etc.
The thing I know is that unpredicted conflicts may occur, depending on the system usage.
But in general I think it will never be straight foreword. But some ideas could help the health of growing up the system with installations. But this will always be under the "base" of manjaro/openrc update idiosyncrasy. The way someone would keep a heavily used system updated with minimal conflicts, would be a challenge. The rolling release is by it self prone to incompatibilities or system explosions but the aufs system layering could also add some possible inconsistency. Or am I wrong?
Last edited by istinnjazz on 26 Apr 2017, 06:33, edited 1 time in total.

User avatar
ncmprhnsbl
Full of knowledge
Full of knowledge
Posts: 784
Joined: 20 Mar 2012, 03:42
Distribution: 3.2.2-64bit xfce/openbox
Location: australia
Contact:

Re: Nemesis update april-06-2017 discussion

Post#36 by ncmprhnsbl » 25 Apr 2017, 22:33

istinnjazz wrote:But in general I think it will never be straight foreword. But some ideas could help the health of growing up the system with installations. But this will always be under the "base" of manjaro/openrc update idiosyncrasy. The way someone would keep a heavily used system updated with minimal conflicts, would be a challenge. The rolling release is by it self prone to incompatibilities or system explosions but the aufs system layering could also add some possible inconsistency also. Or am I wrong?
i think that's a fair assessment ..
(one of )the key(s) to (user) updating is knowing(or finding)(keeping track of) where everything is, so the smaller and simpler the setup, the easier(or more possible) that will be..
not to mention hardware quirks(compiled drivers etc..)
ultimately, if brokenman chooses to return to this manjaro base for future porteus, (i think) each iteration would be a 'rebuild from scratch' process(far easier to script)
possibly on a three month cycle(notwithstanding urgent security patches)
which still leaves the user with 'my stuff is broken' possibilities...
a tricky thing to balance.. lightweight live vs up to date and complete...
Forum Rules : http://forum.porteus.org/viewtopic.php?f=35&t=44

User avatar
istinnjazz
Samurai
Samurai
Posts: 114
Joined: 15 May 2016, 14:10
Distribution: Manjaro-OpenRC/Nemesis

Re: Nemesis update april-06-2017 discussion

Post#37 by istinnjazz » 26 Apr 2017, 18:49

ncmprhnsbl wrote:
istinnjazz wrote:But in general I think it will never be straight foreword. But some ideas could help the health of growing up the system with installations. But this will always be under the "base" of manjaro/openrc update idiosyncrasy. The way someone would keep a heavily used system updated with minimal conflicts, would be a challenge. The rolling release is by it self prone to incompatibilities or system explosions but the aufs system layering could also add some possible inconsistency also. Or am I wrong?
i think that's a fair assessment ..
(one of )the key(s) to (user) updating is knowing(or finding)(keeping track of) where everything is, so the smaller and simpler the setup, the easier(or more possible) that will be..
not to mention hardware quirks(compiled drivers etc..)
ultimately, if brokenman chooses to return to this manjaro base for future porteus, (i think) each iteration would be a 'rebuild from scratch' process(far easier to script)
possibly on a three month cycle(notwithstanding urgent security patches)
which still leaves the user with 'my stuff is broken' possibilities...
a tricky thing to balance.. lightweight live vs up to date and complete...
I see, I'm glad you have a similar view and your points make sense. real helpful for everyone.
I have some notes on my experiments update on my used system, I will point the basic stuff as my system is a personal case.

1. be careful on xorg, it is good to have this in different base module. Hopefully it will not get a conflict with the core module in the future by unresolved dependencies. I have disabled every related package in pamac (xorg*, xf*). Pacman simple update (Pacman -Syu) cannot do this exclusion easily, and in this case some driver may conflict. For example no gui for xorg 1.19 for me and nvidia drivers.

2. Use pamac. Update it first. You will see some or all of possible conflicts before downloading the packages. Pamac will keep all the downloaded packages in its cache directory so you can use them even if you have no Internet access (happened due to networkmanager conflict).
Newest pamac resolves the issue with the message box that you couldnot read all the informatio, e.g. hundrends of conflicting permissions, common @ nemesis.
Resolved @ v4.3.4. I have needed an other package also to use this.

3. There are some odd permission issues when reinstalling, uninstalling. You have to manually delete files for the update process to continue for single packages or on an update process. This is a known problem (bug?) not resolved.

4. Find a way to have wifi wlan access via console so to avoid problems with net access. (example: iw package). I propose to add this to core.

5. Network manager had issues here. At least 3-4 packages conflicted until the service was up and running. Classic conflicting case. The savefile had an updated version install, since 3.5 version, by using the update there was versioning conflict with the new openrc and maybe new login system.
Files downloaded manually from a manjaro mirror from an other os, added to pacman cache, installed etc. with pacman -S, sometimes pacman -Sd command.
Dbus was one of them. Logout menu has now all the commands in place (had been disappeared except logout).

6. read about the openrc services commands and see what has happend to those services, try to restart failed services and log error messages. So those messages may point you to the right packages to (re)install and pacman will lead you to uninstall the conflicting ones...
But be careful as you have to know the new package to use... (dbus, elogin-dbus) sometimes you have to reinstall even the conflicting one, and then exchange with the new. So there might be opposite questions from pacman to unistall a conflicting package over an other.

7. backup savefile/native on every successful step or you may cannot go back, or at least log some good moves.

8. Some system explosions never logged (brutal un-installations, failed full system updates etc..), just to see the behaviour of the new base (xorg1.19/nvidia340.96 fail for example, nvidia driver will always be a xzm for me for obvious reasons, like the gui.xzm)

9. Uninstall a package and install it as a xzm if you need to avoid its existence in savefile (or need to exchange versions with core), e.g gcc. Still need to see what kind of stuff it is better to use as xzm modules.

10... still there are conflicting versions everywhere, hopefully there are no more conflicting packages that could break the functionality. The scenario... THIS-UPDATE-->SAVEFILE-->CURRENT-BASE to be of different versions is common. And the only info I have about this is the pacman database error message
.. to be continued, the update process has not been finished, this could take some time, it is a good way to refresh some linux knowledge

User avatar
istinnjazz
Samurai
Samurai
Posts: 114
Joined: 15 May 2016, 14:10
Distribution: Manjaro-OpenRC/Nemesis

Re: Nemesis update april-06-2017 discussion

Post#38 by istinnjazz » 27 Apr 2017, 21:49

Keep in mind that reinstalling a package it will add/save installed files in savefile even if it is of the same version with base/core. Probably the creation stamp will consider files different and system will add them all as different even if most of them are the same. Normal I guess, just a note.

User avatar
francois
Contributor
Contributor
Posts: 4902
Joined: 28 Dec 2010, 14:25
Distribution: kde xfce porteus manjaro kubun
Location: Enfin l'été, le changement climatique attendu: le soleil.

Re: Nemesis update april-06-2017 discussion

Post#39 by francois » 28 Apr 2017, 03:05

Nice to read you istinjazz. I thought that nmcli could have been enough. But from what I understand from what you say iw is more basic and troubleless.
Voltaire: Le mieux est l'ennemi du bien.

Post Reply