Fedora 31: Chromium does not support h264 even after installing a lot of different packages
Hello. Fedora 31 (AMD64) and Chromium 78, I have installed following packages on the system, but still MP4-H264 is not supported by Chromium: VLC + MPV + GNOME-MPV (celluloid) and their dependencies. gstreamer1-plugin-openh264, gstreamer1-libav, gstreamer1-plugins-ugly I have seen < https://docs.fedoraproject.org/en-US/quick-docs/installing-chromium-or-google-chrome-browsers/ > but widevine plugin is not easy accessibale, I just want a routine MP4 playback. * chromium-libs-media-freeworld * is one version behind latest version (77) and requies downgrading to Chromium 77! while 78 is latest version. There was no clear and straightforward instruction on the web. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: FC31 : soft lockup on boot
Sean Darcy writes: Just updated FC30->FC31. Now I'm in a soft lockup boot loop. Since I can't boot, no logs. Just before the lockup: random: crng init done random: 7 urandom warning(s) missed due to ratelimiting Something very similar was reported a year ago, but for older kernels: https://unix.stackexchange.com/questions/442698/when-i-log-in-it-hangs-until- crng-init-done More recently, some AMD CPUs had a busted hardware random number generator: https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug- destroyed-my-weekend/ There were some follow-up stories about a kernel patch that intended as a workaround for the buggy CPUs. Maybe the patch has landed, and it ain't working? pgp_e_y3YvWsL.pgp Description: PGP signature ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: (fedora) Re: sshd on F31 : strange problem with login with keys's
On 2019-11-30 04:34, Samuel Sieb wrote: > On 11/28/19 4:33 AM, Ed Greshko wrote: >> On 2019-11-28 20:28, Ed Greshko wrote: >>> If you're suggesting this to be a permission issue on authorized_keys >>> wouldn't it be a good >>> idea to request the output of "ls -Z ~/.ssh"? >> >> Oh, as well as "ls -Zd ~/.ssh"? > > Or combine the results of both using "ls -Za ~/.ssh". Sure. I would have said that, had I remembered at the time that the context of the ~/.ssh directory was needed as well. :-) -- The key to getting good answers is to ask good questions. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: FC31 : soft lockup on boot
(Adding the users list back in.) On 11/29/19 1:08 PM, sean darcy wrote: On 11/29/19 3:14 PM, Samuel Sieb wrote: On 11/29/19 9:58 AM, Sean Darcy wrote: Just updated FC30->FC31. Now I'm in a soft lockup boot loop. Since I can't boot, no logs. watchdog: BUG: soft lockup - CPU#0 stuck for 23s! It sits for a while, then reboots. Rinse and repeat. Interesting that it eventually reboots itself. I've tried nomodeset as a kernel parameter. No joy. Any suggestions appreciated. Have you tried removing the "rhgb quiet" from the end to get more kernel output? Have you tried booting one of the F30 kernels instead? Taken rhgb quiet out, and tried the fc30 kernel. No joy. It reboots itself after about 2 or 3 minutes. Continuously. That makes it sound more like a hardware problem. There were no other messages? You tried the oldest kernel in the grub list? My only other suggestion would be to try a F30 live boot image. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: (fedora) Re: sshd on F31 : strange problem with login with keys's
On 11/28/19 4:33 AM, Ed Greshko wrote: On 2019-11-28 20:28, Ed Greshko wrote: If you're suggesting this to be a permission issue on authorized_keys wouldn't it be a good idea to request the output of "ls -Z ~/.ssh"? Oh, as well as "ls -Zd ~/.ssh"? Or combine the results of both using "ls -Za ~/.ssh". ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: FC31 : soft lockup on boot
On 11/29/19 9:58 AM, Sean Darcy wrote: Just updated FC30->FC31. Now I'm in a soft lockup boot loop. Since I can't boot, no logs. watchdog: BUG: soft lockup - CPU#0 stuck for 23s! It sits for a while, then reboots. Rinse and repeat. Interesting that it eventually reboots itself. I've tried nomodeset as a kernel parameter. No joy. Any suggestions appreciated. Have you tried removing the "rhgb quiet" from the end to get more kernel output? Have you tried booting one of the F30 kernels instead? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
FC31 : soft lockup on boot
Just updated FC30->FC31. Now I'm in a soft lockup boot loop. Since I can't boot, no logs. Just before the lockup: random: crng init done random: 7 urandom warning(s) missed due to ratelimiting then watchdog: BUG: soft lockup - CPU#0 stuck for 23s! It sits for a while, then reboots. Rinse and repeat. I've tried nomodeset as a kernel parameter. No joy. Any suggestions appreciated. sean ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Switching to a new root disk
On Fri, 2019-11-29 at 11:35 +, Patrick O'Callaghan wrote: > On Thu, 2019-11-28 at 20:15 -0800, Samuel Sieb wrote: > > On 11/28/19 2:50 PM, Patrick O'Callaghan wrote: > > > Thanks. The only line that looks relevant seems to be this one (from > > > /var/log/anaconda/journal.log): > > > > > > localhost-live anaconda[2737]: program: Running in chroot > > > '/mnt/sysroot'... efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l > > > \EFI\fedora\shimx64.efi > > > > > > which doesn't look like it needs to be changed (given that the new > > > drive will become /dev/sda on rebooting). > > > > The problem is that the BIOS does not know about /dev/sda, it has an > > identifier for the physical disk. You're changing that, so you will > > most likely need to change the EFI boot entry. Look at the "Fedora" > > entry in "efibootmgr -v" to see what I mean. > > It currently shows: > > Boot* Fedora > HD(1,GPT,7554722f-6e12-4c21-89da-5c43790ced1e,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi) > > However the man page for efibootmgr only talks about disks in terms of > /dev/... so I'm not clear on how to a) identify the new SSD, and b) > tell the boot manager about it. Never mind, I figured it out (I think). I just use the *current* /dev entry for the new drive and efibootmgr figures out the proper id. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
gnome3: external monitor, builtin still primary after lid-close
I test-drove a vanilla install of F30 Workstation, and observed the following (correct) behavior: - without an external display, the laptop goes to sleep when the lid is closed - with the external display connected, the built-in screen becomes unavailable when the lid is closed, and the external screen becomes primary (the toolbar at the top moves there, and so do all the windows from the primary screen I then did a custom kickstart install, with a bunchof stuff *including* @gnome-desktop, which works fine overall, except: - when the lid is closed while an external display is connected, the built-in screen *remains* active (and primary, unless I explicitly make the external one primary). Since it's still marked as active/available, sometimes applications (e.g. firefox) end up sending popup boxes there, where I can't see them (since it's closed). I could not find which setting or package causes the difference in behavior between correct and incorrect, but I'd like to keep my custom kickstart installation if at all possible. Any idea how I could explicitly configure my gnome desktop environment to behave correctly w.r.t. extrenal monitor and lid-close effect on the built-in screen? Thanks much, --Gabriel ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Switching to a new root disk
On Thu, 2019-11-28 at 20:15 -0800, Samuel Sieb wrote: > On 11/28/19 2:50 PM, Patrick O'Callaghan wrote: > > Thanks. The only line that looks relevant seems to be this one (from > > /var/log/anaconda/journal.log): > > > > localhost-live anaconda[2737]: program: Running in chroot '/mnt/sysroot'... > > efibootmgr -c -w -L Fedora -d /dev/sda -p 1 -l \EFI\fedora\shimx64.efi > > > > which doesn't look like it needs to be changed (given that the new > > drive will become /dev/sda on rebooting). > > The problem is that the BIOS does not know about /dev/sda, it has an > identifier for the physical disk. You're changing that, so you will > most likely need to change the EFI boot entry. Look at the "Fedora" > entry in "efibootmgr -v" to see what I mean. It currently shows: Boot* Fedora HD(1,GPT,7554722f-6e12-4c21-89da-5c43790ced1e,0x800,0x12c000)/File(\EFI\fedora\shimx64.efi) However the man page for efibootmgr only talks about disks in terms of /dev/... so I'm not clear on how to a) identify the new SSD, and b) tell the boot manager about it. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: Fedora 32 Firefox and DNS over HTTPS
On 11/28/19 8:36 PM, Jakub Jelen wrote: On Wed, 2019-11-27 at 15:17 -0800, Kevin Fenzi wrote: On Wed, Nov 27, 2019 at 04:43:06PM -0500, Robert Moskowitz wrote: In the upcoming Fedora 32, is Firefox defaulting to DNS over HTTPS (RFC 8484)? No. firefox in fedora will not default enable this. https://bugzilla.redhat.com/show_bug.cgi?id=1751410#c2 Great to hear that Fedora is shielding us from these half-baked ideas (or contracts?). Last time it was unsolicited browser extension, now it is DoH to CloudFlare servers. What will be next? I recommend the following thread: https://twitter.com/paulvixie/status/1198013742493028353 Many users are used to Firefox now. But was there some discussion about providing some more privacy-focused browser? But then have you ever been in the privacy debates at the IETF? I have and lost a couple on very stubborn privacy proponents that just don't want to see some tech come to reality because of some vague privacy risk when there are so many worst things (e.g. IDEAS BOF from a few years back). I am having one right now with Unmanned Aircraft RemoteID (see the TM-RID BOF from IETF106). FAA 'owns' all navigable airspace, like maybe 1" above your lawn and roof up to the top of the mesosphere. The craft has to be positively identifiable. No matter what YOU want. Now who the operator is is another matter. Mrs. Bitty can't be allowed to harass the kids down the block for flying a UA in the park behind her home. But an authorized safety official needs to know who to contact to get that UA out of an emergency situation. A tough set of public/privacy issues. Those of us working on this for some time understand this. Grandstanding does not help. Nor do things like DoH 'help'. And btw, this is pretty much the case for ALL Civil Aircraft Administrations (CAA) around the world. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Re: EXTERNAL: Re: sshd on F31 : strange problem with login with keys's
On Thu, 2019-11-28 at 16:27 +, Wells, Roger K. via users wrote: > On 11/26/19 8:32 AM, Ed Greshko wrote: > > On 2019-11-26 20:27, Jouk Jansen wrote: > > > I'm trying to setup an ssh-server on F31 which logs a user in > > > without a > > > password, but with a key-exchange. I generated all the keys and > > > placed them > > > in the right locations. It still asks for the password. > > > > > > Than comes the strange : I stoped the service by "systemctl stop > > > sshd" and > > > did run "as root" /usr/sbin/sshd. And than it just worked. (tried > > > to stop > > > and start with systemctl again made the passwordless login fail > > > again) > > > > > > Question : why does is work with just running "/usr/sbin/sshd" > > > but not with > > > "systemctl start sshd" ? > > One thing you should check is the permissions on the ~/.ssh on the > > machine you're trying to connect > > to. If it is not 700 you will get the behavior you cite. > I've seen this on several fedora updates. Something changes > permissions > on ~/.ssh and then what you see happens Nothing changes permissions on updates on itself. The .ssh directory was copied from somewhere else and it retained its SELinux context or wrong modes. Regards, -- Jakub Jelen Senior Software Engineer Security Technologies Red Hat, Inc. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
