I’ll drop this here, as I’m not certain it’s been absolutely clarified.
The .pacnew files should be merged with the content of the existing files, and should not replace the content.
Yes, this should seem obvious, I suppose, however, some don’t seem to understand the significance. A .pacnew file often contains updated and/or recommended information, which may sometimes conflict with desired settings.
This will often require that you so some research to find out exactly how each item of the proposed merge might affect your particular environment.
Hrm… sometimes Meld seems to think that the .pacnew content should be added, and sometimes it seems to think that it should replace similar (but slightly different and presumably outdated) content in the .conf file. There have been a few instances where I did just that.
I hope I didn’t screw anything up. Most of the changes just seemed to be update to the comments, a few additional options and the like. But there was a GRUB file in there and I know that’s one of the worst places to break things.
There was a place I almost left the lines in (the one with [community]) but I was instructed earlier to specifically remove that one.
There was another that wanted to change the default file system from ext4 to btrfs? I didn’t dare change that one, but maybe I should?
I guess we’ll see… if everything breaks, then I’ll know I have made a terrible mistake somewhere.
Sometimes I think I’m in way over my head. Linux just doesn’t seem to be made for normal people, but at the same time it’s the last usable OS so it’s not like I have any choice (aside from giving computers up entirely, which in this day and age would be very difficult). I really wish the updater was just a bit smarter here, and replace the things it knows it has to replace while leaving people’s settings intact.
UPDATE: so the computer reboots just fine so I didn’t break GRUB. And while I hate to name myself… unfortunately, the “black screen with cursor” issue remains.
If you don’t understand how replacing any part of a file might affect your system, then skip that file until you’ve done some more homework.
Community was a no-brainer, as is said. The repo no longer exists, remove it.
Other pacnews, however, might have serious ramifications if you mess it up; usually recoverable; but, it does highlight the importance of caution.
BTRFS is apparently an excellent filesystem, with many advantages; however, not too many use it (I don’t). EXT4 is more than sufficient for most use cases, and it’s easier to manage.
Arch-based distributions such as Manjaro (being a rolling release) require more attention, generally; frequent updates and changes are just part of the deal.
We are all normal people (most of us), and we all came from something else before Linux. If you’re prepared to learn, you’ll reap the benefits.
So-called point release distributions, such as Debian (rock solid OS), have a different release cycle. Each major release is 2 years apart, with a few minor updates in between. You still need to understand and maintain your OS, but not as often.
Well, if you created a separate/home partition during install (using the manual partitioning method), that makes life easier, as you could do a full reinstall while leaving your home partition in tact.
Meld doesnt know anything about pacnews or what ‘should’ be anywhere.
Its simply a comparison tool.
Which has been opened by pacdiff to help you manage the comparisons of pacnews and similar.
Any highlights, etc, that it shows are simply the mechanisms of showing the differences of the files.
Its up to you to compare, make changes, save, etc. Be aware of the filenames.
Now that you’ve done that please get rid of the old db;
sudo pacman -Sc
(removing the uninstalled cache is optional, but respond Y to removing unused repos)
Then sync+update again
sudo pacman -Syu
Assuming everything is updated and as it should be … now lets check on lightlocker;
Is the autostart file there?
ls -a /etc/xdg/autostart/
Or maybe in home?
ls -a ~/.config/autostart
And maybe check if its running
ps -ef | grep light-locker
If those seem to show it running then it should work;
light-locker-command -l
But we are here because it doesnt so … please report whatever oddities or errors.
D’oh, and we might still find general system information useful:
With “light-locker” being in RED. I’m guessing that’s not a good thing.
Running that last command yields:
** Message: 01:04:58.539: Received error message from the locker: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ScreenSaver was not provided by any .service files
I don’t know if that’s informative regarding the source of the issue, but it might be?
It occurs to me that I’m not 100% certain I didn’t test the Screen Lock function again after I rebooted last time. If I did, I got back in using Ctrl+Alt+F2 and this breaks the Screen Lock function (until I reboot again), which may have tainted the results of those two earlier light-locker tests.
I’ll reboot quickly and redo those two tests just to make sure I get the same result.
Edit: the second result DID change. “light-locker-command -l” successfully triggered the Lock Screen function. Moreover, when I logged back in, I did not get a black screen.
Will retest this immediately, but if that’s the case, it would be a workaround; I could use the Lock Screen function via the terminal.
Edit 2: Confirmed! The command locked the screen, and I didn’t get a black screen when I came back.
So what’s different between that terminal command and the “Lock Screen” button on the UI? Why does one work and the other not? Come to think of it I’ll retest the button again just to be sure we didn’t somehow fix it too.
Edit 3: I used the Screen Lock button, no black screen!
How does that even make sense? I tried it after all those merges and it was still broken. And we didn’t actually change anything since then, I just gathered information and pasted it here. The only thing I did was call the screen lock function from the terminal one time.
Did it stick? I’ll reboot again, try the button before I do it via the terminal, and see if I get a different result.
For SCIENCE.
Edit 4: it did not stick. I rebooted, and the button still gave me a black screen. I rebooted again and used the command in the terminal, and got a black screen again.
I probably suggest lots of other removals as well … including gconf, lib32-gconf, openssl-1.0, mozilla-common, most or all of the old js* packages, and more depending on what you actually need. vertex-maia-themes does not exist anywhere either. Your ipw* packages also dont exist, but there is ipw2x00-firmware in the AUR … etc etc.
I still dont know if any/all of that will have the desired fixes.
But I do know your light-locker appears to be looking for a file that does not exist … while you have old packages, some of which have not existed for a while.
Its no lost cause … but its worth asking at some point if maybe it would be less pain or quicker to do a backup and clean install? It wouldnt be my first choice , but I have a hunch that it would work then (of course a Live USB can always be test-driven).
Only you can value your own time and all.
EDIT.
Hurrah!
We can both be unsure of the mystery of the exact sequence of events, but if it works thats great.
What I said above about the old packages is still general advice though.
Can having old packages actually be harmful? I thought they’d just stay sort of unused…
I’ll check I’m up to date on those just in case, and I suppose I can remove some of these.
Are you sure about Vertex-Maia? It’s always been among the default available themes for me. I just reinstalled Manjaro on my laptop and it was there. The theme I use is actually one of the Vertex-Maia ones.
Reinstalling everything from scratch… I know it’s the “clean” solution, but oh boy is it a nightmare. Days and days of reinstalling things, of things not working like you’re used to and trying to figure out how to set things back to normal. I always dread doing that.
In the meantime I really don’t know what to do about this ridiculous black screen issue. Maybe they’ll fix it in a later update? Usually they don’t, but sometimes they do…
It depends. If it was a selfcontained application it might roughly work that way.
(themes are a pretty good example … though having an old one enabled could break stuff)
But some might provide services or configurations whose continued existence may contradict new norms.
As sorta mentioned in the other thread … we arent really sure its a bug.
Given the myriad of ‘issues’ its quite difficult to say without checking something like a live ISO.
If it isnt a bug … then no fix will come. Your misconfigured system … will continue to be misconfigured.
I can offer another big hammer approach …
Using mapare we can reinstall all the packages that would come with a current ISO.
And we can run it sorta ‘remotely’ (wihtout having to download and mark executable, etc)
When that is done check your pacnews, but then you can consider every foreign package as disposable as you see fit (read: remove everything unless you really want it).
Well, these updates change literally millions of things, so there’s no realistic way for me to figure out which one of these configuration changes my particular system might conflict with.
I read somewhere that there might be alternative ways to control these functions. Another manager might still be able to Lock Screen without triggering this black screen.
Ah well. That’s for another day.
Thanks so much for your help. I learned a few things and, after I remove a few of these, hopefully I might avoid problems in the future. I’ll have to remember to check for new .pacnew files after every update, too. Apparently they don’t happen super often (a couple a year?) but if they can break things, it’s important to know they might be a possible cause.
Thanks again.
Edit: as added information, I have tried switching to another user and using Lock Screen. I got the “black screen with functional cursor” issue there too. So it’s not a “home” configuration problem.
It would seem that the current way is not light-locker.
Its since become xfce4-screensaver with light-locker commented out.
(Though in that other thread they opted to go with light-locker)
It also reminded me you probably would be launched the lock instead with
xflock4
Sorry I havent been using XFCE in some time so I cant check these things myself.
Huh. That’s odd. I do not even have xfce4-screensaver installed.
But I just tried xflock4 and it did not cause the black screen issue! Now, we know that’s not a guarantee (yesterday there were two instances where locking the screen did not result in that issue somehow), but as it worked on the first try, it’s promising.
I’ll try it again later, before and after I reboot, and if it doesn’t cause the issue then… that’s a suitable workaround.
Maybe there’s even a way to tie this function to my Lock Screen button.
It appears you shouldnt really need to do anything extra as long as the lock being activated is xflock4, which according to the article should be true for the ‘Action Buttons’ in the panel.
If you have a key combination configured that may need to be adjusted/reapplied.
xflock4 seems to work every time. Good enough for me! I’ll see if I can figure out how to tie the button to that command, but until then, I don’t mind having to open a terminal and input that one word when I need to lock the screen.
I’ll mark it as the solution so at the very least, if someone encounters the same problem, they’ll also have a nice workaround.
, but I have a hunch that it would work then (of course a Live USB can always be test-driven).