Why do Manjaro Stable updates break the system? Is it bad testing?

Well, unfortunately, you don't understanbd how boxit works.
What you imagine can prove to be totally impractical.

Lets not overcomplicate things here. Techically, we don't really need 3 branches, 2 branches and additional repos would suit much better.

You talk on the surface, I talk under the hood, that is hidden by surface.

Why do the developers have to test in depth at all?
Wouldn't it be good if there were a bunch of users that regularly use "testing" for example and report back any problems during upgrades or while using any Manjaro specific tool?

At the moment I plan to allow our (Java) developers and our system administrators to use Manjaro as their OS instead of LTS Versions of Linux Mint and Ubuntu (mainly because many used tools are directly available in current versions in repo/AUR).
To realize this I currently have 3 hardware systems actively used by myself. Two systems are desktop PCs and the last one is a notebook that I use if I am neither in office nor home office (or if some other system does not work).
Now - if I am confident that I can allow my colleagues to use Manjaro I have to test most updates on my own systems before I allow anyone else to update their system.
You know what I mean? Right, I have to test anyway. :wink:

So, where is your fridge located at? And how many people have regularly access to that fridge? I think there will be a solution.
And yeah, I know that you all are doing this in your free time. Therefore I appreciate it even more that you all are open to communicate and open minded in general.

3 Likes

Did you or someone else had problems with an install based on such "esoteric" thinks like Nilfs2 or ZFS? I fear that using this could introduce new bugs that will not exist on a "normal" installation.
About 3 months ago I already had small problems with my LVM installation of CentOS 7 that did not happen in my "normal" install. This was one of the reasons I switched my systems from a combination of CentOS 7 and Linux Mint to a sole use of Manjaro.

Any of these tools apart from disk cloning will possibly produce some additional errors. But it will be possible to rule them out if other testers with different recovery tools won't have the same issue after an update.

I only once had a filesystem related error when I tried to buildiso on btrfs with systemd - it failed somewhere in the middle. It worked however with btrfs + openrc.

3 Likes

Did a fresh installation of 17.0 KDE EFI VM x64 and upgraded once with octopi, once with pamac (after restoring snapshot of course).

Both updates were fine. Was not the case yesterday.

P.S.: Going to fill my fridge now, not only devs give their free time.

6 Likes

That sounds reasonable although it might be difficult to find people willing to stay in testing after such a modification, since they wouldn't be any advantages to it. Full disclosure, I'm on testing.

I read about the first 50 posts, where the discussion was still civilized, then skipped to the end, where it is not any more. I would try to comment on the first part of the discussion.

  1. Concerning the lack of manpower: I'm maintaining a number of AUR packages: https://aur.archlinux.org/packages/?K=PhotonX&SeB=m If I can be of any help by taking care of some of the less important Manjaro packages (say, those from the community/ repo) and thereby free some time for any of the more knowledgeable people to spend on more important things like ensuring smoother updates, I would gladly volunteer. Where can I sign up? :slight_smile:

  2. Concerning the expectations that users should read the forums before updating: I strongly disagree. I understand that on rare occasions manual intervention is necessary but it shouldn't be necessary to go to the forums to be warned. By the way, I know several happy Manjaro users who don't even speak English.

  3. Concerning the expectations that Manjaro devs should ensure smooth updates: As has been pointed out several times, everybody is doing all the work voluntarily so there can be no expectations whatsoever. On the other hand the devs can try to improve how things work and collaborate with the community. This is actually how it has always worked so far and this is what makes Manjaro so special. I am really surprised why the rough tone appeared in this discussion out of a sudden.

  4. Concerning practical solutions: I strongly agree with the proposal of some kind of notification which pops up before a dangerous update is started. It could include some comments on how to handle the update or at least a request to go read the update announcement on the web. The important part here is that the notification is automatic and reminds users to do something. Hardly someone goes to read update announcements before the update. At least I never did. :smile:

Thanks for reading and I hope that the discussion gets a bit more constructive again!

16 Likes

Not to mention add administrative users with no additional password requests. Walked away without locking your screen? I now own your ass, and deleted your user. Thanks.

I have time to do this also, just need some instructions or guidance on what I need to read up on to be able to do it.

I think that the idea of a smaller (generally more experienced and/or more dedicated) group of users testing an update (understood as a batch of updates) before that (and precisely that) batch update lands in stable is a good one.

How this might be (best?) implemented is another question. :wink:

1 Like

Here the update did not cause any inconvenience for me, but occurred of people who interrupted the update and this caused a system break, certain actions that could cause the break of the system is the responsibility of the user and is not always the responsibility of team of developement.
I be going to virtualize the Manjaro in virtual machine to perform tests of updates and keep Manjaro in repository stable in my laptop. :slight_smile:

Hi!

Such déjà vu! This whole discussion isn't new, and the same suggestions were made before.

I'll just point out a few things:

-> Yesterday I wanted to install qupzilla and pacman automatically updated keyring and system, also breaking GL symlinks. I noticed that, so I came to the forum to check what was happening and fully updated the system, even-though I didn't want to. This should never have happened. The symlink management should have been preformed along with the respective packages update, as sueridgepipe mentioned. Mistakes happen!

-> The proposed changes in mechanics of the branches aren't new. Clearly something needs to change. As I said in previous post (buried somewhere), I believe testing batch updates prior to their move to stable could improve reliability. I don't know if it would attract or repel users. The way I see it, there's not much benefit in having three branches currently because testing and unstable don't seem to differ that much besides development.

-> I and other users also mentioned before the need for a safe and easy way to roll back. I still think this is paramount, not only to ensure recovery from messy situations but also to allow users from testing branch to test both single and batch updates (that is, if the testing mechanics remains essentially the same).

-> As I was reading through the topic, I was thinking on proposing something like this. I wasn't aware of systemd.offline-update, so thank you @Mel.

As for the discussion on wether Linux is for everybody or not, rolling-release model, GUI/wrappers, etc... I believe the aim of any developer is to improve his product and provide usability for the largest possible audience. Of course there are products aimed at different kinds of users with different tastes, but we're talking about a specific product, which advertises itself as professional user-friendly. I'm not criticizing the advertisement, as I believe this to be the true aim of the development team. The important thing is to learn with the past and concentrate on changes which can potentially prevent such issues in the future. This creates a conflict with the "bleeding-edge" part, as stability and development towards that aim necessarily create a lag between updates. That's why I don't fully agree with the "rolling is not for newbies" argument. Instead I think that "bleeding edge is not for newbies".

So, as was also pointed previously (please don't make me search for it), maybe longer periods between stable updates would help, in addiction with bach update testing. This would release some pressure from the stable releases and could potentially attract more users to testing (I would be one of them, at least in what concerns with batch testing).

I probably had more to say but I forgot about it and I don't feel like going through the whole topic again. There are much more knowledgeable persons than me discussing this over here, anyway. I just wanted to contribute with my personal opinion.

Cheers and keep the good work,

3 Likes

Unfortunately I don't understand workings of the boxit too well either. Could you elaborate on how it would be impractical? Do you mean that batching the testing updates would make it somehow more difficult to maintain, or are you meaning that the current situation is untenable, and this would do nothing to improve that? Or possibly something else.

I agree with both sides that having the three branches in their current forms is pointless. And I agree with @artoo that our capacity to maintain 3 branches is questionable. But I think @sueridgepipe makes a good point that if testing was used differently, it would be more useful.

Having separate repos for manjaro packages would make sense.

@sueridgepipe is possibly/probably the most active tester on manjaro community. He had over 10 virtual machines that he repeatedly wiped and reinstalled just to test manjaro-architect + bare metal installs. And that was just the extra he was doing on top of testing calamares.

I think he actually does volunteer for the testing part he suggested.

7 Likes

I take issue with the attitude. "You must", "I want", "Why don't you" and "irresponsible" and this kind of stuff. We don't owe anything.
People get something for free, and have some seriously absurd demands. The truth is, the entire team is at the limits, there are no resources to do more.
We need to cut down some stuff and concentrate what is important.

Regarding boxit, we can't selectively snapshot packages from one branch to the other. Its all or nothing in terms of packages to be moved, and its very tedious, to update two branches with perhaps one or two packages.

3 Likes

I don't want to make things worse -- but I've noticed that the 17.0.1 iso images have a problem -- the 16.x and 17.0 were able to be written as "ISO Image" or "DD Image" using Rufus. But the 17.0.1 images require me to use the "DD Image" format only, otherwise I get grub boot errors.

Also, most of the 17.0.1 iso installs lock up when I try to do a "sudo pacman -Syyu"

Is mgmt aware of these issues? Thx!!

You should not do that. This is the downgrade command.
Who the hell is constantly giving such ill advise?
Do we have some flawed wiki entry?

pacman -Syu

That is upgrade.

3 Likes

The topic has gone beyond readabale length. Such off-topic posts are a sign that it is time to close it.
There have been many valuable comments, Thanks everybody!

3 Likes

Seriously, I pay 100 coco nuts reward to locate the wrong upgrade command. Where does it come from? Its so persistently encountered on this forum, and this mistake should be locked up for good.

5 Likes

I think it is just an intuition of some that more is better. In this case more letters in a command.

2 Likes

Forum kindly sponsored by