You are not logged in.
W. T. A. F..... Is this yet another "improvement" that the developers of other distros who have not fallen in line with Red hat will have to work around?
https://linux.slashdot.org/story/20/05/ … management
Camel Pilot (Slashdot reader #78,781) writes:
Leannart Poettering is proposing homed to alter the way Linux systems handle user management. All user information will be placed in a cryptographically signed JSON record, such as username, group membership, and password hashes. The venerable /etc/passwd and /etc/shadow will be a thing of the past. One of the claimed advantages will be home directory portability."Because the /home directory will no longer depend on the trifecta of systemd, /etc/passwd, and /etc/shadow, users and admins will then be able to easily migrate directories within /home," writes Jack Wallen at TechRepublic. "Imagine being able to move your /home/USER (where USER is your username) directory to a portable flash drive and use it on any system that works with systemd-homed. You could easily transport your /home/USER directory between home and work, or between systems within your company."
What is not clear is that for portability, systems would have to have identical user_id, group names, group_id, etc. And what mechanism is going to provide user authorization to login to a system?
"At the moment, systemd 245 is still in RC2 status," the article notes, adding "The good news, however, is that systemd 245 should be released sometime this year (2020).
"When that happens, prepare to change the way you manage users and their home directories."
Why can't we just cut Red Hat loose to manage their very own Red Hat OS under Poettering?
In addition to the backlight problem, I have found that fan sensors are just not detected on my laptops. One is an Acer Aspire 5733Z, the other is a Gateway NV57H63. Yes, both are pretty old. This is the great thing about Linux, ancient hardware is still usable!
Of the two, the one that this is really a concern for is the Acer. The BIOS control of the CPU fan is really stupid. Instead of gradually adjusting the fan speed to find a constant level that keeps the cores at a decent temperature, it ramps up to what sounds like full speed, then cuts back to a slow idle, then ramps quickly up again when the core temp rises, resulting in constantly changing noise that gets very annoying after a while. The Gateway BIOS is much smarter and adjusts slowly, or maybe the fan is a better design and makes much less noise.
Is there possibly some special utility I haven't heard of to find those fan sensors and controls? It seems odd that so many other obscure things, like proprietary cameras, are found and have drivers, but the CPU fans cannot be found.
After installing and using Devuan Ascii on two different (pretty old) laptops, I discovered that I had not quite gotten everything working. The install process had caught nearly everything, like the touchpad, the internal camera, etc. But when I thought to try to adjust the screen brightness, if just did not work. This is not the 'power saving' option where the screen is dimmed automatically when the machine is idle. This is the deliberate manual change of screen brightness when using the machine, in a low light situation where you want a less bright screen for example.
Searching around, I found that something called 'xbacklight' had to be installed, and then when it complained 'No outputs have backlight property' I set out to solve that problem. The recommended solutions such as adding command options to GRUB did not work until I ran across the page: 'https://shreve.io/posts/fixing-xbacklight' which recommends adding a config file inside the X11 directory tree. '/usr/share/X11/xorg.conf.d/10-backlight.conf' Placing the recommended file with the recommended contents in the recommended place finally made the manual backlight/brightness controls work on my laptops.
Now, here are the questions:
He got the info on how to do this from a 'bug report' -- does this mean that the Ascii installer (and therefore the Debian install it was based on) does not recognize certain hardware correctly and installs the wrong X11 drivers? Or does this mean that the default system configuration was botched when designing this version of the Debian/Devuan distro, not taking laptops properly into account? In either case, is this fixed, or will it be fixed, in Beowulf -- or will I have to remember to make manual adjustments to my systems when I upgrade?
Oops, I didn't phrase that right. I was expecting it to remove non-red, or at least blue, from the display. Color 'temperature' is a broad effect that only slightly changes the actual colors on the screen. As I said further along in the paragraph, "submarine-style night mode" is what I was really looking for.
Gentoo? I'd expect Gentoo to recommend you recompile chromium with different flags. ![]()
When I was experimenting with it, I found that chromium also cannot connect to audio on Discord. It just sits there "waiting to connect" -- forever. Dunno if that's a reflecting of how bad Discord is, or chromium. I've heard that Discord is a pretty hairy mess written entirely in Javascript and run via Electron even on tablets or desktops. Ergh... so I switched back to Firefox. Which at least does work.
But you never know when Mozilla will do something annoying with Firefox. So I would like to have alternatives to Firefox, and I guess I'll go back and struggle with chromium some more soon.
Every time I start chromium I get a useless prompt for a keyring password that has to be canceled multiple times to get rid of it. There is no such thing as a keyring password on my system, as there is no keyring. Unless chromium creates it, in which case I want to stop it from even creating it. So far, all solutions found by google search have no effect.
Copying /usr/share/applications/chromium.desktop to ~/.local/share/applications and adding the '--password-store=basic' option to the Exec line does nothing. Creating a file called chromium-flags.conf file under .config/chromium and adding the option that that does nothing.
What does it take to tell the current version of chromium to not bother with encrypted keyrings?
OK, I think I see what is going on. It works, but I didn't understand what it does. I thought it was actually supposed to turn down the 'red' part of all colors in the display. It's just dimming the display slightly. So what I want to do is really eliminate the blue light from anything I run on my desktop. Submarine-style "rig for night running" mode.
Is there a way to do that? Or will each program have to be individually configured to only use red colors? I suppose there is an all-red theme for XFCE, or one can be created. But the other programs might be more of a challenge.
Running Redshift with those "one time" switches will change the screen color for about 15-20 seconds. Then it reverts. So far, nothing seems to make Redshift-gtk actually effective. Hmm.....
Not sure if this is a "desktop" or a "system configuration" issue. Installing redshift and redshift-gtk, I ran it and then clicked the icon to get at the config option to have it start with the system. But as far as I can see, it does nothing. There was no change in the color of my screen as the evening wore on, even though it reported that it knew the time was 'night'. Is there some other option that needs to be tweaked somewhere to get it to actually affect the screen color?
This was on a laptop using the default XFCE desktop, so there is no complex issue with ATI or nVidia drivers. Its the standard Intel video driver, and it's the desktop environment the whole system was designed around.
This is only getting weirder every time I try something else. A complete purge and re-install has resulted in no resolv.conf at all in the /etc directory. It's now a symbolic link to /var/run/NetworkManager/resolv.conf but is still controlled by dnssec-triggerd. I don't know if it has the immutable attribute. It gives an error message when I try to check it. At least this time the DNS does work. Maybe the re-install forced it to update to the current master sig/key?
Meanwhile, another system that I hadn't gotten to still has /etc/resolv.conf and it has the immutable attribute. But this one is still successfully producing DNS lookups. Since it works, I won't mess with it for now. If I can ever get a handle on some sort of consistent behavior I'll see about a new thread.
Well, yes, I thought ntp was a good thing for any system to have. How much could it adjust the system time? Only a minute or two, I'd think. And I would have thought it would adjust the hardware clock when it did so.
Still, it might be a good idea to use the known Windows registry tweak to make it use UTC. I've been making other changes to align Wind'ohs with real OSes, such as running my own account as a normal user and having a separate admin account. ![]()
According to all of the documentation I can find, setting line 3 of /etc/adjtime to LOCAL tells the system that your BIOS time is local rather than GMT/UTC. But every time I reboot it during a single day, I get that complaint from fsck about the file system superblock being ahead of the real time. Yes, this is a dual boot system with Windows on the other side. Windows system time works properly. You might think that Windows is 'fscking' with something, but this happens even when Windows has not been booted even once that day. It looks like the Linux system is not reading the config file it is supposed to be reading. Has something changed recently in how system time is tracked and/or set?
Well, on my systems (all of them now) is locks resolv.conf and fails to provide the DNS lookups that it has forced the system to ask it for. I've now removed it from all of my systems. It worked for a few days and then went haywire. Frustrating. Hasn't there been a recent update of the "master" signing key? Could that have broken it?
Maybe Devan would not, but the dnssec-trigger package comes from nlnet labs, and they would:
https://www.nlnetlabs.nl/projects/dnssec-trigger/about/
There used to be a race condition between dnssec-trigger and the system but this was fixed in 0.6, with a 'system preferences' override on OSX and Windows, and chattr immutable on Linux and BSD.
No, I didn't even know the immutable attribute existed until I figured out how to remove it. Something else set it. And that was a peripheral problem. The real problem is that dnssec-trigger doesn't work anymore. DNS info is not looked up and the machine cannot use the network with it installed. Something in the batch of updates I downloaded broke it.
That would install all of the kernels in the directory. Sounds messy.
Fortunately, after some more struggles I figured out what was wrong. The resolv.conf file was set read-only even for root, and contained only 127.0.0.1 as the nameserver. Well, whatever was in those latest updates broke dnssec-trigger. I don't know enough about it to say what exactly went wrong. When unbound stopped working, it prevented any network access from working since all applications would think that 127.0.0.1 was the place to request DNS information. When I finally figured out how to free resolv.conf (it was a completely different file control system than chmod, something I've never heard of before "chattr") it returned to the control of network manager and the system is usable again.
So now it looks like dnssec-trigger is not safe to use since these updates broke it. I'll have to remove it from all my systems and continue trying to figure out how to setup unbound independently.
Alright, I give up. Since I don't have access to the network anymore, I can't get the files I deleted to try again. Looks like I have no option but a complete re-install when I have some time. This is the first time I have had such a debacle with Linux. But if I re-install and updating breaks my networking again, what then?
All I have to do is reboot into Windows and there are no network problems. Something in the Linux updates broke my networking. Which is really shocking. Bad updates are supposed to be a Windows thing...
The system having the problems is a desktop, no wifi involved. I simply downloaded updates using the above sources.list, "aptitude update" and then "aptitude safe-upgrade" and the network stopped working. The log posted above is all of the packages installed by that update. Looks like a lot of CUPS updates. But the only thing I can figure has anything to do with network access is the kernel. Hmm...
Actually, I have to wonder if it was the kernel the broke my network. Here is the log of the upgrade that broke the system. MANY things were changed:
Start-Date: 2020-02-12 14:19:07
Install: linux-headers-4.9.0-12-common:amd64 (4.9.210-1, automatic), linux-image-4.9.0-12-amd64:amd64 (4.9.210-1, automatic), linux-headers-4.9.0-12-amd64:amd64 (4.9.210-1, automatic)
Upgrade: perl-base:amd64 (5.24.1-3+deb9u5, 5.24.1-3+deb9u6), libopenjp2-7:amd64 (2.1.2-1.1+deb9u3, 2.1.2-1.1+deb9u4), libcups2:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), linux-libc-dev:amd64 (4.9.189-3+deb9u2, 4.9.210-1), libjaxen-java:amd64 (1.1.6-1, 1.1.6-1+deb9u1), perl-modules-5.24:amd64 (5.24.1-3+deb9u5, 5.24.1-3+deb9u6), cups-server-common:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), linux-compiler-gcc-6-x86:amd64 (4.9.189-3+deb9u2, 4.9.210-1), cups-common:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libpq5:amd64 (9.6.15-0+deb9u1, 9.6.16-0+deb9u1), libperl5.24:amd64 (5.24.1-3+deb9u5, 5.24.1-3+deb9u6), cups-ppdc:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libcupsmime1:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), linux-image-amd64:amd64 (4.9+80+deb9u9, 4.9+80+deb9u10), libglib2.0-bin:amd64 (2.50.3-2+deb9u1, 2.50.3-2+deb9u2), linux-headers-amd64:amd64 (4.9+80+deb9u9, 4.9+80+deb9u10), linux-kbuild-4.9:amd64 (4.9.189-3+deb9u2, 4.9.210-1), libglib2.0-data:amd64 (2.50.3-2+deb9u1, 2.50.3-2+deb9u2), libtimedate-perl:amd64 (2.3000-2, 2.3000-2+deb9u1), libmariadbclient18:amd64 (10.1.41-0+deb9u1, 10.1.44-0+deb9u1), libcupsppdc1:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libidn11:amd64 (1.33-1, 1.33-1+deb9u1), libfreetype6:amd64 (2.6.3-3.2, 2.6.3-3.2+deb9u1), perl:amd64 (5.24.1-3+deb9u5, 5.24.1-3+deb9u6), cups-bsd:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), cups-core-drivers:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), cups-daemon:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libcupsimage2:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), cups:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libcupscgi1:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), cups-client:amd64 (2.2.1-8+deb9u4, 2.2.1-8+deb9u5), libglib2.0-0:amd64 (2.50.3-2+deb9u1, 2.50.3-2+deb9u2), libxslt1.1:amd64 (1.1.29-2.1+deb9u1, 1.1.29-2.1+deb9u2)
End-Date: 2020-02-12 14:20:13
Hmm, I've still got:
linux-image-amd64_4.9+80+deb9u9_amd64.deb
linux-headers-amd64_4.9+80+deb9u9_amd64.deb
In my apt archives directory, but can't figure out how to re-install it.
OK, I removed those from one system but now that system cannot connect to anything online. It's like the network driver or DNS or something is broken. This latest update has apparently broken something. I'll definitely wait before updating the others....
Proposed repositories? What are those? The only thing remotely experimental in my sources.list is backports. Do they put kernels into backports? Should I roll back somehow?
deb http://deb.devuan.org/merged ascii contrib main non-free
deb http://deb.devuan.org/merged ascii-updates contrib main non-free
deb http://deb.devuan.org/merged ascii-security contrib main non-free
deb http://deb.devuan.org/merged ascii-backports contrib main non-free
Ack! Updating has added another line to the list!
i A linux-image-4.9.0-11-amd64 - Linux 4.9 for 64-bit PCs
i A linux-image-4.9.0-12-amd64 - Linux 4.9 for 64-bit PCs
i A linux-image-4.9.0-6-amd64 - Linux 4.9 for 64-bit PCs
i A linux-image-4.9.0-9-amd64 - Linux 4.9 for 64-bit PCs
i linux-image-amd64 - Linux for 64-bit PCs (meta-package)
WTF is going on???
Well, this is getting weirder. First:
i A linux-image-4.9.0-11-amd64 - Linux 4.9 for 64-bit PCs
i A linux-image-4.9.0-6-amd64 - Linux 4.9 for 64-bit PCs
i A linux-image-4.9.0-9-amd64 - Linux 4.9 for 64-bit PCs
i linux-image-amd64 - Linux for 64-bit PCs (meta-package)
There are THREE images showing as installed, besides the meta-package. But beyond that, I checked for new updates again and there is ANOTHER linux-image available for my machine. Maybe this is a correction for the mistake that resulted in multiple install entries?
It's time to get my Linux boxes updated, and the one I've started with is downloading TWO kernel updates. ??? Why would this happen? I admit I'm not checking very frequently for updates. Maybe every couple weeks. Could the release of one kernel update right after another cause both to be downloaded? Or would something else make this happen?