I did the work around steps mentioned on here and as i previously mentioned i couldnt use eth afterwards . And now after the third reboot the system completely crashed will only boot into emergency mode . Is there a way to use pacman to completely uninstall everything and reinstall from emergency mode ?
No I dont think you cana use pacman in that manner. IF you have machine with either a large drive with various partitions on it or multiple drives you can do what I did... Move /home/"your account" over to another drive or on another partition on the same drive, then do a fresh install. That way you preserve what is in /home like music, videos, documents, some config settings and so forth. Then the partition where Manjo is, either nuke and pave it with GParted or allow the Manjo install program to do that. Manjo install is pretty good with what you can do with allocating storage even if you arent an expert at it. What I have described here is basically what I did a couple of days ago. Couple more qualifiers- the machine I did the update on that ended carked up from the update...had been back and forth between testing and stable at least once using pacman and the set branch command (see the excellent Arch pacman wiki for this at
and switching branches from stable to testing and/or vice versa is NOT recommended behavior because it leaves lots of garbage and nasty residue from the previous branch I think. I am curious about what you mean by emergency mode i.e. just a CLI? Or one of the options you have from Grub to boot to a different kernel? But then there is this
and a possibly better set of instructions here
which is chroot using the installation media and a good way to hopefully be able to save stuff from /home that is important to you (if you have not backed your system up).
Hope this helps. Good luck with it. I completely understand how frustrating this crap can be.
during the boot up process before it ever hits x it failed and then told me to type in my root password to enter emergency mode thats what im talking about .
Ok understand. So with what you say here,you SHOULD be able to mhwd into chroot. Note that when I originally did the update on my machine--while it did not kill the X server or the GUI, it screwed it up with the frame rate going way way down and a bunch of other things. So if there is enough of an OS left to do what you outline you may be able to chroot and save either the install or whats in /home. Great time to learn more about the structure of all of this.
One important thing to consider here- Manjo has chroot and its a great recovery tool and there arent a lot of other distros that have anything like it.
Maybe the mods will have something to say about this so you might want to start another thread off of this update thread about your adventures. Just an idea. Lotsa people here will be happy to help.
should have cleaned my glasses.....
5.1 is still very new. It is expected for some things to not work. Try the LTS kernels (4.19 or 4.14). You should have a few backups kernels in any case. Running only the latest kernel is for the brave.
It is perfectly safe to switch branches.
Please create your own thread. You should not hijack the update thread for personal support.
What package you are using- from community( rxvt-unicode) or some other version from aur ?If it is from aur - just delete and reinstall it
I am running:
rxvt-unicode-pixbuf from AUR
rxvt-unicode-terminfo from community
urxvt-perls from community
Should I delete and reinstall one or more of them?
When I go to remove it, it says it will remove a couple of dozen other apps. Is there a way to just remove it by itself? Is this the way I should do it?
Oh i3 dependency hell ! First install rxvt-unicode from community remove rxvt-unicode-pixbuf then reinstall urxvt-perls and rxvt-unicode-terminfo . then reinstall rxvt-unicode-pixbuf and remove rxvt-unicode.I am pretty sure that I messed up somewhere so DM me if you will have progress
The fix proposed in the Arch link works perfectly for me.
So i decided to rebuild lib32-glibc using the fix until Arch rebuild themselves, which in turn will likely still take a few weeks to make it back to Manjaro stable. It's version 2.29-3.5 (old is 2.29-3) so when the -4 rebuild by Arch comes down it'll update over the top. I'll leave my rebuild up until the Arch build makes it way down in to Manjaro, at which point i'll remove the file off my server. So for those interested...
Fixed glibc now in repositories.
Worked like a charm. You didn't mess it up. Thank you so much!
You are welcome
I'll rebuild and push it to the branches.
Up to now, no flaws encountered on kernel 5.1.15, Xfce, nvidia legacy 390.xx (defunct mobile Kepler GPU).
I‘m still in the process of solving a bug I‘m experiencing with mpd/alsa/USB. I have narrowed the culprit down to the laptop power management, but haven‘t gotten to the root cause yet (Xfce power manager, underlying power manager, Manjaro implementation, my inserting usbcore.autosuspend=-1 in the grub Linux commandline?). I was posting in the Technical Assistance bucket here on the forum, but it‘s still premature. I will return to that thread.
EDIT: Here‘s the a.m. thread, updated now.
For yourself and others who are complaining about the stability of Manjaro, I think you all need to reassess what you want from your OS, (and how you maintain it).
You all have some choices you need to make if you wish to continue using a rolling distro.
You really need to alter the way you do your updates to minimize the chance of encountering a bad update.
Always read the update release notices on the forum before performing any update.
Wait at least a day or two before performing a system update. Any severe bugs are usually patched within a day, but don't be caught installing your updates before a fix has been rolled out.
Stop using a GUI package manager to perform large system updates. Use pacman in the terminal or a TTY to ensure your best chance of a problem free update.
If that is all just too much effort for you, then you have several other options.
You can switch to a fixed release distro that only performs security updates, which could possibly provide more stability.
If neither of those strategies appeal to you, then you really only have one feasible alternative if you wish to continue using a rolling distro.
If you go out boating on a millpond for the day and don't want to wear a life jacket no big deal. If you're going whitewater rafting and you don't wear a life jacket you are being extremely reckless.
A rolling distro is the equivalent of whitewater rafting in the Linux world. You need a life jacket for this, and your life jacket is a good backup strategy.
If you perform backups and experience a bad update you can simply roll your system back to before the bug occurred. After your system is restored you can leisurely investigate what might have caused the issue and how to rectify it. Perhaps there is no immediate fix, then simply wait till the next update to see if the issue has been resolved. With good backups you never have to sweat a bad update, because you can be up and running again in minutes.
Make your choice, but it's your responsibility to maintain your system if you choose to run a rolling distro. The Manjaro team cannot possibly anticipate the results of an update on every possible hardware/software combination in existence.
It's time to take some responsibility for maintaining your own system. If you are not prepared to do that, perhaps it's time you all migrate to a static distribution.
New glibc is available.
Apparently update button in Pamac GUI does not work(trying to update glibc now)Is this a known issue?
How using pacman in the terminal or in a TTY would have help whatsoever in this case?
I do not remember him or anyone saying that Pamac (GUI) crashed in the middle of the upgrade. The most issue I see for the upgrade process is either file (snapd with /snap symbolic link) or package conflict (with people that doesn't clean up their old kernel). Even with pacman, you would have been screwed and would have to solve the issue.
I don't know, the community here sometime acts like doing system upgrades in a command-line interface will inherently solve all problems and will always go well magically.