users May 2021

users@lists.fedoraproject.org

100 participants
93 discussions

Gnome 4 F34 Startup Anomaly
by Stephen Morris 15 May '21

15 May '21

Hi, I am running Fedora in a Vmware Player VM. Having upgraded to F34 from F33, which installed Gnome 4, I have found that when I start "Gnome in Xorg" with the VM window maximised to full screen size (3840x2161) that it starts with the Gnome Dash open as if I had clicked on "Activities", which did not happen in F33 and earlier versions of Fedora. Is this standard functionality in Gnome 4, like the removal of extensions from tweakui into a separate application, that cannot be changed or is there a configuration option to change that behaviour? regards, Steve

2 4

F34 Wayland Resoluton Issues
by Stephen Morris 15 May '21

15 May '21

Hi, With running F34 in a Vmware Player VM, with whatever video driver Wayland is using (I've forgotten the commands to find out), xrandr is reporting that Wayland is not running at the correct resolutions. With the Vmware Player maximised to 3840x2075 resolution running Plasma, xrandr reports the connected resolution as being 2560x1383 even though the desktop seems to have scaled to 3840x2075. Under Gnome 4 with the Vmware Player maximised to 3840x2075, xrandr reports the connected resolution as 2560x1600 which seems to be correct based on the size the desktop is actually showing as, and it also refused to scale to the 3840x2075 resolution. When using xorg with both Gnome and Plasma, and having an xorg configuration file, specifying modelines statements as provided by CVT for all resolutions xrandr says is supported by whatever driver xorg is using (which from the xorg log seems to be a vesa driver) is connecting at 3840x2075. Given these situations is Wayland not working correctly, or is Wayland not coping properly with a VM, or does there need to be a configuration file specified somewhere for Wayland to fully support resolutions up to 4K? regards, Steve

1 0

dns glue or duct tape??
by Jack Craig 15 May '21

15 May '21

Hi folks With help from this list I recently updated my DNS configuration to provide for a primary and secondary DNS server where the primary DNS server is my host inside my domain and the secondary server is provided by AT&T I discovered that the secondary server on file with my registrar was wrong so I got the right data and they claim to have created a glue record but I'm still getting that host is not responding *primary dns ws.linuxlighthouse.com <http://ws.linuxlighthouse.com>* *Secondary server ns2.swbell.net <http://ns2.swbell.net>* would some kind soul direct me to a coherent glue (or duct tape) record test? also, given some domain name how do you know which top level domain name servers should be the first set that you query to locate your domain in question?? tia...

5 5

Network entanglement
by Robert McBroom 14 May '21

14 May '21

Installed Arch Linux on my Goflex Home NAS. I see it on the router from my ISP. It is connected through an access point to have a sufficient number of ethernet ports. I can't ping it using the ipv4 address I see on the router. There are two ipv6 addresses shown. One declares a lifetime of 3600s and the other says forever. ping and ssh work using the ipv6 address with a declared lifetime but not the "forever" Using a system that is connected to the wireless on the ISP router can ping the Arch system with the ipv4 address. ping 192.168.1.112 PING 192.168.1.112 (192.168.1.112) 56(84) bytes of data. From 192.168.1.185 icmp_seq=1 Destination Host Unreachable From 192.168.1.185 icmp_seq=2 Destination Host Unreachable From 192.168.1.185 icmp_seq=3 Destination Host Unreachable From 192.168.1.185 icmp_seq=4 Destination Host Unreachable From 192.168.1.185 icmp_seq=5 Destination Host Unreachable From 192.168.1.185 icmp_seq=6 Destination Host Unreachable ^ PING 2600:1702:4860:9dd0:210:75ff:fe28:5e30(2600:1702:4860:9dd0:210:75ff:fe28:5e30) 56 data bytes 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=1 ttl=64 time=0.301 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=2 ttl=64 time=0.292 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=3 ttl=64 time=0.298 ms 64 bytes from 2600:1702:4860:9dd0:210:75ff:fe28:5e30: icmp_seq=4 ttl=64 time=0.288 ms Knew just enough of ipv4 to almost get around but this is beating me.

4 15

How do I create an entry in the boot menu for an UEFI system?
by Lester Petrie 14 May '21

14 May '21

Hi all, The subject says what I want to do. The why is as follows. About a year and a half ago I bought a new machine with a 2 Tb SSD and a 2 Tb hard drive. It came with Windows on it, which I wanted to keep, so I found a Windows program that let me shrink the Windows partitions on both the SSD and the HD to 1 Tb, and tried to install Fedora on the free 1Tb SSD. But at the time the installer would not recognize the SSD, so I ended up installing on the HD, with a new EFI partition there. I was then able to select between Windows and Fedora from the boot menu. About the time F33 came out, I learned I needed to disable Raid in the Bios, and then I installed F33 on the free 1Tb SSD. This added Fedora to the Windows EFI partition, and replaced Fedora in the boot menu with the new version, so I was still able to select either Windows or Fedora 33 when I booted. And grub conveniently found my old HD installation and included it in the grub menu. Then something happened about a week ago, and the Fedora entry in the boot menu reverted to the HD entry (which is F31). I can do a rescue boot and chroot to F33, and then run efibootmgr, but I can't figure out how to create a legitimate, bootable entry for F33. The files all seem to still be in the right place, and I can create an entry in the menu, but it is not a valid entry. Any help will be greatly appreciated. -- Lester M Petrie

5 7

Re: How do I create an entry in the boot menu for an UEFI system?
by Lester Petrie 14 May '21

14 May '21

On 5/14/2021 6:40 AM, George N. White III wrote: > On Thu, 13 May 2021 at 17:40, Lester Petrie <lmpetrie(a)bellsouth.net > <mailto:lmpetrie@bellsouth.net>> wrote: > > On 5/13/2021 4:17 PM, George N. White III wrote: > > On Thu, 13 May 2021 at 16:56, Lester Petrie > <lmpetrie(a)bellsouth.net <mailto:lmpetrie@bellsouth.net> > > <mailto:lmpetrie@bellsouth.net <mailto:lmpetrie@bellsouth.net>>> > wrote: > > > > Hi all, > > > > The subject says what I want to do. The why is as follows. > About a > > year > > and a half ago I bought a new machine with a 2 Tb SSD and a > 2 Tb hard > > drive. It came with Windows on it, which I wanted to keep, so I > > found a > > Windows program that let me shrink the Windows partitions on > both the > > SSD and the HD to 1 Tb, and tried to install Fedora on the free > > 1Tb SSD. > > But at the time the installer would not recognize the SSD, so I > > ended up > > installing on the HD, with a new EFI partition there. I was then > > able to > > select between Windows and Fedora from the boot menu. About the > > time F33 > > came out, I learned I needed to disable Raid in the Bios, > and then I > > installed F33 on the free 1Tb SSD. This added Fedora to the > > Windows EFI > > partition, and replaced Fedora in the boot menu with the new > > version, so > > I was still able to select either Windows or Fedora 33 when > I booted. > > > > > > Did you also disable Windows "fastboot"? > > I am able to get to the boot menu the same as always, so I am pretty > sure Windows "fastboot" is not the problem. > > > > > And grub conveniently found my old HD installation and > included it in > > the grub menu. Then something happened about a week ago, and the > > Fedora entry in the boot menu reverted to the HD entry > (which is F31). > > Did the problem start with a kernel update? If I remember correctly, I had done an update, then shutdown and left for the weekend. When I booted back up, I came up in Fedora 31 (which I did not recognize immediately). I do believe there was a kernel in the update, but I can't be sure. > > > I can do > > a rescue boot and chroot to F33, and then run efibootmgr, > but I can't > > figure out how to create a legitimate, bootable entry for > F33. The > > files > > all seem to still be in the right place, and I can create an > entry in > > the menu, but it is not a valid entry. Any help will be greatly > > appreciated. > > > How did you create the entry? If the procedures in: > https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide… > <https://docs.fedoraproject.org/en-US/fedora/f33/system-administrators-guide…> > are messing up a bug report may be in order. The problem is not in the Grub menu, its in the basic UEFI boot menu. I currently can' bring up the correct Grub menu. > > You could experiment by making temporary changes to the grub menu > to work out the reason for the "not valid". You may get ideas by > comparing > the entries for the SSD Fedora with the entry for the HD Fedora, both > for | > | > |/etc/default/grub and in| /boot/efi/EFI/fedora/grub.cfg. The latter file > combines sections from various scripts but has comments that identify the > scripts for most entries. > > || > > > > > > > How do define "not valid"? Do you get an error, do you end up in > Windows, > > or ...? Did the problem occur after using Windows? Have you > checked the > > BIOS settings? > > Not valid means that if I select the entry I made from the boot > menu, I > get an error message saying it is not valid. I can still select > Windows, > or the HD version of Fedora successfully. > > > I've never encountered "not valid" from grub. You should have small > partitions for /boot and /boot/efi. Are they on the SSD or the HD? > Is either one full? Again I can't get to the correct grub menu. The entry in the UEFI menu that I have added is the one that give not valid when it is selected. /EFI on the SSD has entries fore both Fedora 33 and Windows 10, while /EFI on the HD has entries for Fedora 31. Something happened that caused the initial boot menu to regress to showing the HD Fedora instead of the SSD Fedora. I don't understand what efibootmgr is doing well enough to add a correct entry that points to /EFI/fedora/shimx64.efi. > > -- > George N. White III > -- Lester M Petrie

1 0

puzzling SELinux alert.
by home user 13 May '21

13 May '21

At least 3 times in the past few days I've seen the same SELinux alert. I put the text of the details in the attached file "alerts.txt". All 3 occurrences were while using caja to rename or delete a file, though it does not happen every time I rename or delete a file in caja. These alerts confuse me. There is no directory "/memdf:"... -bash.1[~]: cd / -bash.2[/]: ls -a . boot etc lib64 mnt root srv system-upgrade usr .. .cache home lost+found opt run sys system-upgrade-root var bin dev lib media proc sbin sysroot tmp -bash.3[/]: ls -a /memfd* ls: cannot access '/memfd*': No such file or directory -bash.4[/]: Also, the directory name (ending with a colon?) looks fishy. Further, the filename ".nvidia_drv.XXXXXX" looks fishy (but "legal"). The instruction does not work: -bash.4[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX (deleted) -bash: syntax error near unexpected token `(' -bash.4[/]: -bash.5[/]: /sbin/restorecon -v /memfd:/.nvidia_drv.XXXXXX /sbin/restorecon: SELinux: Could not get canonical path for /memfd:/.nvidia_drv.XXXXXX restorecon: No such file or directory. -bash.6[/]: I gather that a directory and or file (whatever its name really is) are missing? How do I fix this?

6 36

Strange compress behavior under /usr
by Qiyu Yan 13 May '21

13 May '21

Dear folks, My problem is that new file created at /usr won't be compressed. I accenticly that none of my files under /usr is compressed[1], so I tried to run `sudo btrfs fi def -czstd -v -r /usr` to compress them, that seems to work. And `sudo compsize /usr` now gives Processed 431312 files, 224528 regular extents (230971 refs), 253758 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 56% 7.2G 12G 13G none 100% 3.5G 3.5G 3.5G zstd 39% 3.6G 9.2G 9.7G This seems pretty good, but when I am testing dding to dump a file to /usr to test compress for new file, problem happens: [root@yan-desktop /]# dd if=/dev/zero of=/usr/1 bs=10240 count=10000 记录了10000+0 的读入记录了10000+0 的写出 102400000字节（102 MB，98 MiB）已复制，0.0426441 s，2.4 GB/s [root@yan-desktop /]# dd if=/dev/zero of=/etc/1 bs=10240 count=10000 记录了10000+0 的读入记录了10000+0 的写出 102400000字节（102 MB，98 MiB）已复制，0.0585055 s，1.8 GB/s [root@yan-desktop /]# compsize /usr/1 Processed 1 file, 1 regular extents (1 refs), 0 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 100% 97M 97M 97M none 100% 97M 97M 97M [root@yan-desktop /]# compsize /etc/1 Processed 1 file, 782 regular extents (782 refs), 0 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 3% 3.0M 97M 97M zstd 3% 3.0M 97M 97M Just ignore those Chinese output by dd, it doesn't important... But as you can see: file created at /usr/1 is not compressed at all while file created at /etc/1 gets compressed. There should not be any difficult to compress all-zero contents for zstd. There should not be so much difference between /usr and /etc, they are in same subvolume named "root" mounted at /. [root@yan-desktop /]# btrfs su li / ID 256 gen 1530662 top level 5 path home ID 257 gen 1530662 top level 5 path root ID 266 gen 1530614 top level 257 path var/lib/machines ID 292 gen 1530585 top level 257 path var/lib/mock ...[some container storage subvolumes] and mount options for / is rw,noatime,seclabel,compress=zstd:3,ssd,space_cache=v2,subvolid=257,sub vol=/root (subvol=root,noatime,compress=zstd in fstab) lsattr /|grep -E "var|etc" gives -------------------- /etc -------------------- /var `btrfs property get /usr` or `btrfs property get /etc` gives empty output. How do I troubleshoot this problem? [1] That is also a problem since I setup compress after upgrading to fedora 34, and have done many package updates since then. So new extents written to /usr should be compressed while compsize reports none of them. -- Qiyu Yan GPG keyid: 0x4FC914F065F2DF12 About: https://fedoraproject.org/wiki/User:Yanqiyu

2 2

Evince sendto (share) button greyed out
by Anca, Tibor 12 May '21

12 May '21

Hello, since the switch to Fedora 40 I notice this odd change, that neither nautilus context menu (Sendto entry missing), nor evince share/ sendto button work. The latter doesn't work at all which makes things unnecessary complicated. I understand that the package nautilus-sendto has been integrated into nautilus-extensions, which now provides a libnautilus-sendto.so. But this hass no observable effect on Evince. Is this a bug that I should look for/ file, or <irony> a feature that I cannot appreciate in its full beauty </irony>? Besides: Fedora 34 is a great work and Gnome 40 works otherwise flawlessly on my Thinkpad E485! Kind regards Tibor -- Dr. Tibor Attila Anca Pastor Ev.-luth. Kirchengemeinde Dollbergen-Schwüblingsen Fuhsestr. 19, 31311 Uetze OT Dollbergen Gemeindebüro Telefon: +49 (0)5177 922144 Gemeindebüro Telefax: +49 (0)5177 922145 Direkter Kontakt: Telefon: +49 (0)5132 5045860 Telefax: +49 (0)5132 5045861

1 0

System Failure?
by home user 11 May '21

11 May '21

I did my weekly patches (dnf upgrade), rebooted, and logged in as a regular user. A problem popped-up. The top part of the details is below. I'm not (yet) seeing any other problems. Is this a false alarm? If not, what should I do? --------------- not-reportable The backtrace does not contain enough meaningful function frames to be reported. It is annoying but it does not necessarily signalize a problem with your computer. ABRT will not allow you to create a report in a bug tracking system but you can contact kernel maintainers via e-mail. reason traps: fwupd[130814] general protection fault ip:7f6c8fea2122 sp:7fffe5746b60 error:0 in libglib-2.0.so.0.6600.8[7f6c8fe80000+8b000] backtrace traps: fwupd[130814] general protection fault ip:7f6c8fea2122 sp:7fffe5746b60 error:0 in libglib-2.0.so.0.6600.8[7f6c8fe80000+8b000] cmdline BOOT_IMAGE=(hd0,msdos3)/vmlinuz-5.11.15-200.fc33.x86_64 root=UUID=45e553d2-fa0c-4eae-95f6-7bf9086ab74c ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole.keymap=us rhgb quiet nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:on modprobe.blacklist=nouveau package kernel-core-5.11.15-200.fc33 component kernel hostname coyote count 1 first occurence 2021-04-22 11:03:20 last occurence 2021-04-22 11:03:20 user unknown user type/analyzer Kerneloops/abrt-oops pkg-fingerprint 49FD 7749 9570 FF31 kernel 5.11.15-200.fc33.x86_64 pkg_vendor Fedora Project runlevel N 5 os_release Fedora release 33 (Thirty Three) duphash 913d3ca671c62c4a2304f3f1ea8bded67351e0c0 uuid 913d3ca671c62c4a2304f3f1ea8bded67351e0c0 architecture x86_64 abrt_version 2.14.5 data directory /var/spool/abrt/oops-2021-04-22-11:03:20-875-0

5 13

← Newer
1
2
3
4
5
6
7
8
9
10
Older →