I have multiple monitors on my system, one of which is HDMI (the rest
are DP or DVI). It's not the main monitor. When I start some apps
(esp games), the HDMI monitor blanks for a few seconds until the app's
window comes up (not full screen).
Is this a normal thing? Can it be prevented?
It seems that Fedora 26 allowed me to have KDM and LightDM installed
without gdm, gnome-shell, and mutter.
I had a crash while attempting to login using LightDM:
# journalctl -e
0x00007feb273ed783 gtk_css_static_style_compute_value (libgtk-3.so.0)
0x00007feb273d900c _gtk_css_lookup_resolve (libgtk-3.so.0)
0x00007feb273ed6bc gtk_css_static_style_new_compute (libgtk-3.so.0)
0x00007feb273ed715 gtk_css_static_style_get_default (libgtk-3.so.0)
0x00007feb273d99a2 gtk_css_node_init (libgtk-3.so.0)
0x00007feb25bde390 g_type_create_instance (libgobject-2.0.so.0)
0x00007feb25bbf4b8 g_object_new_internal (libgobject-2.0.so.0)
Many neurons were lost trying to track the cause down, but then the fix was:
# yum install gdm
Last metadata expiration check: 0:51:01 ago on Tue May 30 03:01:28 2017 CDT.
Package Arch Version Repository Size
gdm x86_64 1:3.24.2-1.fc26 updates-testing 501 k
gnome-shell x86_64 3.24.2-1.fc26 updates-testing 1.9 M
mutter x86_64 3.24.2-1.fc26 updates-testing 2.2 M
How do you troubleshoot dependencies? Or is there some other mis-configuration which could have caused the problem?
cheers -- Rick
I opened a second tab in konsole and immediately ran sudo su to
obtain a prompt as root. I ran a program and then I forgot to
exit and just closed the tab. Am I still root somewhere? Or did
closing the tab do the same thing as a proper exit?
sorry to disturb w/ list management issues.. I've been tried to post
here but my message is waiting for moderator approval (since
2017-05-19). Nothing scary, but I wonder if it's because of its
contents.. There was a text attachment, I tried to sent it w/ the text
inserted in body instead, no luck. Is there really a moderator or am I
blacklisted in some way for an obscure reason? (I could post a reply to
In the "f24 boot fails; need help" topic, a log file extract had these 2
1533 [ 4.022605] coyote systemd-fsck: /dev/sda6: Superblock last
mount time is in the future.
1534 [ 4.022745] coyote systemd-fsck: (by less than a day, probably
due to the hardware clock being incorrectly set)
One person noted
"The time problem suggests that the little pancake battery on the MB
that maintains the clock might be out of juice. I think these are 2032
style for PCs. It would be a good idea to replace it."
"I didn't know workstations nowadays had batteries. When the system is
back on its feet, I'll try to check that. It was bought in 2013."
I knew that the older motherboards had batteries. But I thought the
newer ones used something like flash (or other persistent) memory. It
did not occur to me that booting might want the date/time before the
boot process reached the point of being able to access the internet.
Two people corrected me. Someone else in the discussion said it well:
I sit corrected!
Fedora seems to have a huge number of commands. Does Fedora have a
command to report the condition of a full-sized tower motherboard
battery? If yes, what is that command?
Out of the blue, I just got popup messages on my
screen first telling me a new version of fedora
is ready to install then a few minutes and lots of
net access later telling me updates were ready to
What is doing this crap?! I have all the automatic
update junk turned off, who has re-activated it
and how do I make it stop?
Have they embedded this in systemd now? Did I
inadvertently run some program that has the side
effect of starting a search for updates?
I need a piece of advice concerning an encrypted root partition on Fedora 26. I'm running a custom manual setup created using dnf.
* The installation procedure is outlined in this tread -- and quite likely irrelevant to this question anyway: https://firstname.lastname@example.org...
* The disk layout is described in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1297188#c2
Unlike Fedora 23 and 24, both of which booted just fine, Fedora 26 has two glitches related to my encrypted LUKS root partition:
1. Dracut fails to automatically add the crypt module. It doesn't seem to care about LUKS-related settings in /etc/default/grub and/or about the fact that the system runs off an encrypted volume. I had to manually add add_dracutmodules+="crypt" into /etc/dracut.conf, or else I wouldn't get a password prompt on boot and the early systemd would freeze waiting for the root partition to appear. It works normally with add_dracutmodules+="crypt".
2. Possibly as a consequence of (1), systemd doesn't realize that the root partition has been already activated and luksOpen'ed at boot time and keeps trying to unlock it over and over. The consoles are spammed by messages like this one, basically on every sudo invocation:
Password entry required for 'Please enter passphrase for disk cryptprdell-luks (plainprdell)!' (PID 5492).
Please enter password with the systemd-tty-ask-password-agent tool!
Of course I tried to run the systemd-tty-ask-password-agent tool and type in the password. But then systemctl --failed showed a failure in systemd-cryptsetup(a)plainprdell.service, the auto-generated unit for the LUKS volume. Presumably, journalctl revealed that the error message had been "Failed to activate: Device or resource busy". Well, that's indeed what happens when you try to open a LUKS volume that's already opened.
If I don't use systemd-tty-ask-password-agent at all, systemctl status permanently shows "starting" and never reaches "running", because of the LUKS volume it thinks it needs to activate. (I tried systemctl disable, but nope, that had no effect.)
This appears to have something in common with an ancient bug from 2013: https://bugzilla.redhat.com/show_bug.cgi?id=924581
Has anything changed (1) in the way Dracut finds out whether the crypt module is needed (which worked at least up to Fedora 24) or (2) in the way systemd generates its automatic units for encrypted volumes? Something must have changed, but I have no idea what it is and how to get the old behavior back. :-/
My /etc/default/grub and /etc/crypttab are attached. The current kernel version is 4.11.0-2.fc26.x86_64.
Because Anaconda doesn't support my usual partitioning scheme (root on Btrfs in LVM in LUKS in LVM in GPT, /boot on Btrfs, etc.), I created the entire layout manually and tried to install Fedora using dnf. The same layout works perfectly fine in ArchLinux.
I basically followed this howto, with adjustments for s/yum/dnf/ and for EFI/GPT: http://dustymabe.com/2014/05/29/manual-linux-installs-with-funky-storage-...
The initial filesystem installation (dnf install -y --releasever=23 --installroot=/mnt/sysimage filesystem) already got a few glitches of this form:
Non-fatal POSTIN scriptlet failure in rpm package filesystem
This^^^ happened to roughly half of the installed packages. I tried to proceed with the rest (i.e., to install @core @standard kernel grub2 grub2-efi sihm grub2-tools), but it failed with scriptlet errors that prevented a few key packages from getting installed at all:
error: %prein(selinux-policy-targeted-3.13.1-157.fc23.noarch) scriptlet failed, exit status 126
Error in PREIN scriptlet in rpm package selinux-policy-targeted
Packages with those errors are reported as failed after the verify step. What I tried next:
* setenforce 0
* upgrading the installation environment and/or the sysimage with dnf and rpm from rawhide
* --releasever=22 instead of 23
* ...and checking for a few other common points with this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1270663
* a plain sysimage directory with no predefined Btrfs subvolumes in it
* unmounting, remounting, checking that everything has seclabel on, no weirdness in dmesg, etc.
Well, nothing of the above helped; the error is still the same.
How can I diagnose this? Where can I dig out the exact reason why the scriptlets are failing?
Provided that Anaconda actually does some steps that I'm missing and can carry out the installation correctly, is there a way to *force* it to just accept whatever is mounted into /mnt/sysimage at the moment, without trying to make sense of it? I'm pretty sure dracut can handle my partition layout just fine, so the entire issue here is about getting the basic installation done somehow.
Theoretically I could create a simple-and-stupid layout that Anaconda can handle, proceed with the installation and reshuffle the partitions afterwards, but that's sooo cumbersome that I thought I'd first ask whether someone knows a workaround to the scriptlet problems.
Is fedora providing this?
-------- Forwarded Message --------
Subject: Re: Intel / AMD CPU Microcode Updates Required For Security
Date: Sun, 28 May 2017 23:52:46 +0000
From: Ben Woods <woodsb02(a)gmail.com>
To: RW <rwmaillists(a)googlemail.com>, freebsd-questions(a)freebsd.org,
On Mon, 29 May 2017 at 7:35 am, RW via freebsd-questions <
> On Sun, 28 May 2017 17:53:01 -0400
> grarpamp wrote:
> > Blobs that fix exploitable things may be slightly better than blobs.
> > Awareness should be raised, and updates applied to systems.
> > # sysutils/devcpu-data New Microcode Released for Intel / AMD
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219268
> Is there a standard way to run cpucontrol? There doesn't seem to be an
> rc.d script.
There is an rc script installed with this port:
From: Benjamin Woods
freebsd-questions(a)freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe(a)freebsd.org"
Runnning old "Fedora 20-x86_64", and want to install
[lucelio@localhost ~]$ uname -rov
3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 GNU/Linux
[lucelio@localhost ~]$ sudo lvmdiskscan
/dev/fedora/root [ 50,00 GiB]
/dev/fedora/swap [ 3,77 GiB]
/dev/sda2 [ 500,00 MiB]
/dev/vg_maq01/lv_swap [ 5,75 GiB]
/dev/sda3 [ 118,75 GiB] LVM physical volume
/dev/vg_maq01/lv_home [ 63,00 GiB]
/dev/vg_maq01/lv_root [ 50,00 GiB]
/dev/fedora/home [ 48,48 GiB]
/dev/sdb2 [ 500,00 MiB]
/dev/sdb3 [ 194,87 GiB]
/dev/sdb4 [ 500,00 MiB]
/dev/sdb5 [ 102,24 GiB] LVM physical volume
0 LVM physical volume whole disks
2 LVM physical volumes
The /dev/sda* is a SSD(KINGSTON SV200S3128G) 128GB, with old "Fedora
16-x86_64", and only want to recover some files in /home.
The /dev/sdb* is a Seagate(ST3320613AS) 320GB, running old "Fedora
20-x86_64", with some important file in /home.
[lucelio@localhost ~]$ sudo lvscan
ACTIVE '/dev/fedora/swap' [3,77 GiB] inherit
ACTIVE '/dev/fedora/home' [48,48 GiB] inherit
ACTIVE '/dev/fedora/root' [50,00 GiB] inherit
ACTIVE '/dev/vg_maq01/lv_swap' [5,75 GiB] inherit
ACTIVE '/dev/vg_maq01/lv_home' [63,00 GiB] inherit
ACTIVE '/dev/vg_maq01/lv_root' [50,00 GiB] inherit
[lucelio@localhost ~]$ mount | grep /dev/mapper
/dev/mapper/fedora-root on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/mapper/fedora-home on /home type ext4
Want to mount the SSD on "Fedora 20" to recover some files, copying it
to /dev/sdb3 space(/dev/sdb3 not used/mounted). After this, I can
erase all SSD and install "Fedora 25" on it.
Thanks for help if possible.