I recently installed F40 from DVD. F40 and I are having a difference of opinion regarding what password I gave the initial user. F40 is winning. I find it hard to believe I typed in the same wrong password twice, but it's F40's opinion that counts. I try to login: click on the user and type in my password. F40 just goes back to the select a user screen. There is only one user.
My usual strategy is to boot a live disk and to edit the passwd and shadow files directly. It did not work. Now F40 no longer even gives me a chance to type in a password. It just blinks at me and goes right back to the select a user screen. What is going on? How do I fix it? I would much prefer not to reinstall. Even if I have to reinstall, I would like to know what is going on. My line from /etc/passwd : hennebry::1000:1000:The Michael:/home/hennebry:/bin/bash My line from /etc/shadow : hennebry::19893:0:99999:7:::
On Wed, 19 Jun 2024 12:24:48 -0500 (CDT) Michael Hennebry wrote:
My usual strategy is to boot a live disk and to edit the passwd and shadow files directly.
My strategy is to boot a live cd, then chroot into the copy on disk and use the passwd command. Maybe that would work better?
On Wed, 19 Jun 2024, Tom Horsley wrote:
On Wed, 19 Jun 2024 12:24:48 -0500 (CDT) Michael Hennebry wrote:
My usual strategy is to boot a live disk and to edit the passwd and shadow files directly.
My strategy is to boot a live cd, then chroot into the copy on disk and use the passwd command. Maybe that would work better?
I'll try that. Since it has worked for you, I infer that you did an su first, otherwise I'd expect passwd to ask for a password.
Note to quoters of boilerplate: Please follow Tom's example with regard to quoting.
The Michael is late for breakfast.
On Jun 19, 2024, at 13:25, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I recently installed F40 from DVD. F40 and I are having a difference of opinion regarding what password I gave the initial user. F40 is winning. I find it hard to believe I typed in the same wrong password twice, but it's F40's opinion that counts. I try to login: click on the user and type in my password. F40 just goes back to the select a user screen. There is only one user.
My usual strategy is to boot a live disk and to edit the passwd and shadow files directly. It did not work. Now F40 no longer even gives me a chance to type in a password. It just blinks at me and goes right back to the select a user screen. What is going on? How do I fix it? I would much prefer not to reinstall. Even if I have to reinstall, I would like to know what is going on. My line from /etc/passwd : hennebry::1000:1000:The Michael:/home/hennebry:/bin/bash My line from /etc/shadow : hennebry::19893:0:99999:7:::
If what you posted is actually what’s in /etc/shadow then you’ve set a null password for your account. There should be no password prompt at all.
However, if you’ve removed the “nullok” from the pam_unix.so lines in /etc/pam.d (or Fedora has finally removed it in F40), accounts with a null password hash entry won’t be able to log in.
I’m going to assume from here on that you actually are using a password.
So, if you’ve used a rescue disk to boot into Linux, chroot into your OS’s disk, and run “passwd” to change a password, or otherwise edit /etc/shadow or /etc/passwd (or other files in /etc), you most likely need to fix the selinux labels of those files. Easiest way to do this is to run “touch /.autorelabel” before exiting the chroot, then rebooting. That will force the OS to check the selinux labels on all the files in your filesystem upon boot. It might take some time.
Another solution is to boot with “enforcing=0” in the kernel arguments, and see if you can log in. If so, then you can manually run a relabel by running “sudo restorecon -R -v /etc”.
On 06/19/2024 02:31 PM, Jonathan Billings wrote:
So, if you’ve used a rescue disk to boot into Linux, chroot into your OS’s disk, and run “passwd” to change a password, or otherwise edit /etc/shadow or /etc/passwd (or other files in /etc), you most likely need to fix the selinux labels of those files. Easiest way to do this is to run “touch /.autorelabel” before exiting the chroot, then rebooting. That will force the OS to check the selinux labels on all the files in your filesystem upon boot. It might take some time.
Why don't you just KISS by following the instructions to reset the root password, except that the command you need to run is:
passwd $USERNAME
using your regular account's username.
On Jun 19, 2024, at 16:41, Joe Zeff joe@zeff.us wrote:
On 06/19/2024 02:31 PM, Jonathan Billings wrote:
So, if you’ve used a rescue disk to boot into Linux, chroot into your OS’s disk, and run “passwd” to change a password, or otherwise edit /etc/shadow or /etc/passwd (or other files in /etc), you most likely need to fix the selinux labels of those files. Easiest way to do this is to run “touch /.autorelabel” before exiting the chroot, then rebooting. That will force the OS to check the selinux labels on all the files in your filesystem upon boot. It might take some time.
Why don't you just KISS by following the instructions to reset the root password, except that the command you need to run is:
passwd $USERNAME
using your regular account's username.
That still won’t fix SELinux labeling issues.
On Wed, 19 Jun 2024, Barry wrote:
You could login at a console and eliminate the gui as a problem. Type alt-ctrl-f3 to get a console.
Thank you for that suggestion. I could login from a console. Clearly the problem was not my password. Auto-relabel did not get me back to the gui, but just getting a console meant I could actually work. I created another user and discovered that that user could login from the gui. Eventually I: Created another wheel user; from that user, renamed my home directory and put a dummy in its place; userdel'ed my account; uaseradd'ed my account with UID 1000 .
Never did figure out why the gui did not like me.
I just discovered something interesting: None of the accounts on my machine will login with Xorg. The option is offered, but is does not work. For F40, I had selected gnome-classic with Xorg. New accounts defaulted to gnome with Wayland. When I made a new hennebry account, even with an old home directory, it got the default and allowed me to login. I infer that the option is not stored in the home directory.
Not being able to use Xorg is not good news. Last time I had trouble running videos, part of the solution was switching to Xorg. The rest, I think, was installing the H.264 decoder. I found the thread, but it does not tell me the name of the package or the name of the repo. Also, I do not know whether videos will work for me with Wayland.
You would need to find the log file that starts up Xorg after you login it.
There are a number of things that can be set wrong and/or missing that will cause Xorg to attempt to start and fail and exit like this.
F39 puts the log file here on my machine. /var/log/Xorg.0.log
On most of my machines I have it set to default to multi-user mode (no gui) and login as a user on the console and then type startx as that gives me a much easier way to debug the failure. it also lets me more easily boot up and login to console and fix/debug more basic boot up issue without being troubled to login to the gui.
On Thu, Jun 20, 2024 at 12:30 AM Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
I just discovered something interesting: None of the accounts on my machine will login with Xorg. The option is offered, but is does not work. For F40, I had selected gnome-classic with Xorg. New accounts defaulted to gnome with Wayland. When I made a new hennebry account, even with an old home directory, it got the default and allowed me to login. I infer that the option is not stored in the home directory.
Not being able to use Xorg is not good news. Last time I had trouble running videos, part of the solution was switching to Xorg. The rest, I think, was installing the H.264 decoder. I found the thread, but it does not tell me the name of the package or the name of the repo. Also, I do not know whether videos will work for me with Wayland.
-- Michael hennebry@mail.cs.ndsu.NoDak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, 20 Jun 2024, Roger Heflin wrote:
You would need to find the log file that starts up Xorg after you login it.
There are a number of things that can be set wrong and/or missing that will cause Xorg to attempt to start and fail and exit like this.
F39 puts the log file here on my machine. /var/log/Xorg.0.log
No go on F40. I expect I need some incantation involving journalctl .
On most of my machines I have it set to default to multi-user mode (no gui) and login as a user on the console and then type startx as that gives me a much easier way to debug the failure. it also lets me more easily boot up and login to console and fix/debug more basic boot up issue without being troubled to login to the gui.
On 20 Jun 2024, at 16:33, Michael Hennebry hennebry@web.cs.ndsu.nodak.edu wrote:
No go on F40. I expect I need some incantation involving journalctl .
Are you using wayland perhaps?
So we know the details of your setup what is the output of inxi -Fzxx ?
Barry
On Thu, 20 Jun 2024, Michael Hennebry wrote:
On Thu, 20 Jun 2024, Roger Heflin wrote:
You would need to find the log file that starts up Xorg after you login it.
There are a number of things that can be set wrong and/or missing that will cause Xorg to attempt to start and fail and exit like this.
F39 puts the log file here on my machine. /var/log/Xorg.0.log
No go on F40. I expect I need some incantation involving journalctl .
I looked yet again and this time I did find such a file. 'Tis different from the one under ~/.local
Here is the tail end. [ 592.348] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c8 [ 592.352] (--) PCI:*(0@0:2:0) 8086:29d2:103c:281e rev 2, Mem @ 0xf0100000/524288, 0xe0000000/268435456, 0xf0000000/1048576, I/O @ 0x00001240/8, BIOS @ 0x????????/131072 [ 592.353] (II) LoadModule: "glx" [ 592.353] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 592.355] (II) Module glx: vendor="X.Org Foundation" [ 592.355] compiled for 1.20.14, module version = 1.0.0 [ 592.355] ABI class: X.Org Server Extension, version 10.0 [ 592.355] (==) Matched intel as autoconfigured driver 0 [ 592.355] (==) Matched modesetting as autoconfigured driver 1 [ 592.355] (==) Matched fbdev as autoconfigured driver 2 [ 592.355] (==) Matched vesa as autoconfigured driver 3 [ 592.355] (==) Assigned the driver to the xf86ConfigLayout [ 592.355] (II) LoadModule: "intel" [ 592.355] (WW) Warning, couldn't open module intel [ 592.355] (EE) Failed to load module "intel" (module does not exist, 0) [ 592.355] (II) LoadModule: "modesetting" [ 592.356] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 592.356] (II) Module modesetting: vendor="X.Org Foundation" [ 592.356] compiled for 1.20.14, module version = 1.20.14 [ 592.356] Module class: X.Org Video Driver [ 592.356] ABI class: X.Org Video Driver, version 24.1 [ 592.356] (II) LoadModule: "fbdev" [ 592.356] (WW) Warning, couldn't open module fbdev [ 592.356] (EE) Failed to load module "fbdev" (module does not exist, 0) [ 592.356] (II) LoadModule: "vesa" [ 592.356] (WW) Warning, couldn't open module vesa [ 592.356] (EE) Failed to load module "vesa" (module does not exist, 0) [ 592.356] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 592.356] (EE) open /dev/dri/card0: No such file or directory [ 592.356] (WW) Falling back to old probe method for modesetting [ 592.356] (EE) open /dev/dri/card0: No such file or directory [ 592.357] (EE) Screen 0 deleted because of no matching config section. [ 592.357] (II) UnloadModule: "modesetting" [ 592.357] (EE) Device(s) detected, but none match those in the config file. [ 592.357] (EE) Fatal server error: [ 592.357] (EE) no screens found(EE) [ 592.357] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 592.357] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 592.357] (EE) [ 592.359] (EE) Server terminated with error (1). Closing log file.
I note that Xorg could not find intel, fbdev or vesa, all of which strike me as s trange.
On Thu, 20 Jun 2024 00:30:31 -0500 (CDT) Michael Hennebry wrote:
Not being able to use Xorg is not good news.
Just a data point: I use Xorg exclusively and have no problems with fedora 40 login. I use sddm as my greeter and changed the sddm.conf file to say use Xorg, not wayland - don't know if that really matters.
On Thu, 2024-06-20 at 00:30 -0500, Michael Hennebry wrote:
I just discovered something interesting: None of the accounts on my machine will login with Xorg. The option is offered, but is does not work.
In what sense, *exactly*, "does not work"?
I remember an old X problem where you'd try to log in and get an immediate failure that threw you back to the login greeter due to wrong directory permissions on /tmp.
*Working* example:
[tim@rocky ~]$ ll -d /tmpdrwxrwxrwt. 18 root root 12288 Jun 21 07:08 /tmp
The mail server I use for fedora is not mine and it was down for a bit.
On Fri, 21 Jun 2024, Tim via users wrote:
On Thu, 2024-06-20 at 00:30 -0500, Michael Hennebry wrote:
I just discovered something interesting: None of the accounts on my machine will login with Xorg. The option is offered, but is does not work.
In what sense, *exactly*, "does not work"?
I could not login. The screen would blink. Sometimes I would briefly see a cursor. I'd be back at the login screen.
I remember an old X problem where you'd try to log in and get an immediate failure that threw you back to the login greeter due to wrong directory permissions on /tmp.
*Working* example:
[tim@rocky ~]$ ll -d /tmpdrwxrwxrwt. 18 root root 12288 Jun 21 07:08 /tmp
hennebry@2001-48F8-3004-2CE-0-0-0-D31E-dynamic:~$ ls -ld /tmp drwxrwxrwt. 23 root root 540 Jun 20 22:23 /tmp
I found the Xorg log in ~/.local/share/xorg/Xorg.0.log . Here is the tail end after a failed attempt to login:
[ 40469.777] (II) modeset(0): Printing probed modes for output VGA-1 [ 40469.777] (II) modeset(0): Modeline "1440x900"x59.9 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz eP) [ 40469.777] (II) modeset(0): Modeline "1280x1024"x75.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz e) [ 40469.777] (II) modeset(0): Modeline "1280x1024"x60.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz e) [ 40469.777] (II) modeset(0): Modeline "1440x900"x75.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz e) [ 40469.777] (II) modeset(0): Modeline "1280x960"x60.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz e) [ 40469.777] (II) modeset(0): Modeline "1152x864"x75.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz e) [ 40469.777] (II) modeset(0): Modeline "1024x768"x75.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz e) [ 40469.777] (II) modeset(0): Modeline "1024x768"x70.1 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz e) [ 40469.777] (II) modeset(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 40469.777] (II) modeset(0): Modeline "832x624"x74.6 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz e) [ 40469.777] (II) modeset(0): Modeline "800x600"x72.2 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz e) [ 40469.777] (II) modeset(0): Modeline "800x600"x75.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz e) [ 40469.777] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 40469.777] (II) modeset(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 40469.777] (II) modeset(0): Modeline "640x480"x75.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz e) [ 40469.777] (II) modeset(0): Modeline "640x480"x72.8 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz e) [ 40469.777] (II) modeset(0): Modeline "640x480"x66.7 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz e) [ 40469.777] (II) modeset(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 40469.777] (II) modeset(0): Modeline "720x400"x70.1 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz e) [ 40469.777] (II) modeset(0): Output VGA-1 connected [ 40469.777] (II) modeset(0): Using exact sizes for initial modes [ 40469.777] (II) modeset(0): Output VGA-1 using initial mode 1440x900 +0+0 [ 40469.777] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 40469.777] (==) modeset(0): DPI set to (96, 96) [ 40469.777] (II) Loading sub module "fb" [ 40469.777] (II) LoadModule: "fb" [ 40469.778] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 40469.778] (II) Module fb: vendor="X.Org Foundation" [ 40469.778] compiled for 1.20.14, module version = 1.0.0 [ 40469.778] ABI class: X.Org ANSI C Emulation, version 0.4 [ 40469.778] (WW) glamor requires at least 128 instructions (64 reported) [ 40469.778] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time. [ 40469.778] (EE) Fatal server error: [ 40469.778] (EE) AddScreen/ScreenInit failed for driver 0 [ 40469.778] (EE) [ 40469.778] (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 40469.778] (EE) Please also check the log file at "/home/hennebry/.local/share/xorg/Xorg.0.log" for additional information. [ 40469.779] (EE) [ 40469.784] (EE) Server terminated with error (1). Closing log file.
Per request, the output from inxi -Fzxx : System: Kernel: 6.9.4-200.fc40.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 2.41-37.fc40 Desktop: GNOME v: 46.2 tk: GTK v: 3.24.42 wm: gnome-shell dm: GDM Distro: Fedora Linux 40 (Workstation Edition) Machine: Type: Desktop System: Hewlett-Packard product: HP Compaq dc5800 Small Form Factor v: N/A serial: <superuser required> Chassis: type: 4 serial: <superuser required> Mobo: Hewlett-Packard model: 2820h serial: <superuser required> part-nu: AJ411AV BIOS: Hewlett-Packard v: 786F2 v01.60 date: 10/26/2015 CPU: Info: dual core model: Intel Core2 Duo E6550 bits: 64 type: MCP arch: Core2 Merom rev: B cache: L1: 128 KiB L2: 4 MiB Speed (MHz): avg: 1996 high: 1998 min/max: 1998/2333 cores: 1: 1998 2: 1995 bogomips: 9309 Flags: ht lm nx pae sse sse2 sse3 ssse3 Graphics: Device-1: Intel 82Q33 Express Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-4 ports: active: VGA-1 empty: none bus-ID: 00:02.0 chip-ID: 8086:29d2 Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 24.1.0 compositor: gnome-shell driver: X: loaded: modesetting alternate: fbdev,intel,vesa gpu: i915 display-ID: 0 Monitor-1: VGA-1 model: Acer V193W res: 1440x900 dpi: 89 diag: 483mm (19") API: OpenGL v: 2.1 vendor: mesa v: 24.1.1 glx-v: 1.4 es-v: 2.0 direct-render: yes renderer: i915 (: Q33) device-ID: 8086:29d2 display-ID: :0.0 API: EGL Message: EGL data requires eglinfo. Check --recommends. Audio: Device-1: Intel 82801I HD Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus-ID: 00:1b.0 chip-ID: 8086:293e API: ALSA v: k6.9.4-200.fc40.x86_64 status: kernel-api Server-1: JACK v: 1.9.22 status: off Server-2: PipeWire v: 1.0.7 status: active with: 1: pipewire-pulse status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin Network: Device-1: Intel 82566DM-2 Gigabit Network vendor: Hewlett-Packard driver: e1000e v: kernel port: 1100 bus-ID: 00:19.0 chip-ID: 8086:10bd IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: <filter> Drives: Local Storage: total: 74.53 GiB used: 39.11 GiB (52.5%) ID-1: /dev/sda vendor: Seagate model: ST380815AS size: 74.53 GiB speed: 3.0 Gb/s serial: <filter> Partition: ID-1: / size: 30.95 GiB used: 11.18 GiB (36.1%) fs: ext4 dev: /dev/sda3 ID-2: /home size: 31.04 GiB used: 27.22 GiB (87.7%) fs: ext4 dev: /dev/sda7 ID-3: /var size: 5.82 GiB used: 734.2 MiB (12.3%) fs: ext4 dev: /dev/sda6 Swap: ID-1: swap-1 type: zram size: 7.67 GiB used: 32.2 MiB (0.4%) priority: 100 dev: /dev/zram0 Sensors: System Temperatures: cpu: 43.0 C mobo: N/A Fan Speeds (rpm): N/A Info: Memory: total: 8 GiB available: 7.67 GiB used: 1.55 GiB (20.1%) Processes: 227 Power: uptime: 23h 0m wakeups: 0 Init: systemd v: 255 target: graphical (5) default: graphical Packages: Compilers: gcc: 14.1.1 Shell: Bash v: 5.2.26 running-in: gnome-terminal inxi: 3.3.34
I'm aware that this an old machine and that I will have to make do with software video. That was already the case with F38.
At the moment, I cannot play local videos, but firefox can play videos.
Tim:
In what sense, *exactly*, "does not work"?
Michael Hennebry wrote:
I could not login. The screen would blink. Sometimes I would briefly see a cursor. I'd be back at the login screen.
Very similar to what happened to me, though could be coincidental.
I'd occasionally get the same thing due to a lockfile stuck in /tmp, that I could resolve by deleting /tmp files. But since /tmp is volatile files held only in RAM, these days, that issue rarely happens any more (any reboots wipe /tmp).
[ 40469.778] (EE) Please also check the log file at "/home/hennebry/.local/share/xorg/Xorg.0.log" for additional information.
And that file...
At the moment I have no further suggestions, but someone else may spot something.
On Fri, 21 Jun 2024, Tim via users wrote:
Tim:
Michael Hennebry wrote:
I could not login. The screen would blink. Sometimes I would briefly see a cursor. I'd be back at the login screen.
[ 40469.778] (EE) Please also check the log file at "/home/hennebry/.local/share/xorg/Xorg.0.log" for additional information.
And that file...
is the fle I was quoting.
From /home/hennebry/.local/share/xorg/Xorg.0.log [ 81949.159] (WW) glamor requires at least 128 instructions (64 reported) [ 81949.159] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time. [ 81949.159] (EE) Fatal server error: [ 81949.159] (EE) AddScreen/ScreenInit failed for driver 0
Is this modeset a reference to the modeset on the kernel command line? Do I need glamor? If not, how do I tell Xorg that I do not?
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support. I've installed pretty much everything I can think of, including *opengl* , *openGL* and *mesa* . No go. Firefox can play local movies.
A bit more info: hennebry@fedora:~$ glxinfo -B name of display: :0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: Mesa Project (0x8086) Device: i915 (chipset: Q33) (0x29d2) Version: 24.1.1 Accelerated: yes Video memory: 384MB Unified memory: yes Preferred profile: compat (0x2) Max core profile version: 0.0 Max compat profile version: 2.1 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 2.0 OpenGL vendor string: Mesa Project OpenGL renderer string: i915 (chipset: Q33) OpenGL version string: 2.1 Mesa 24.1.1 OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 24.1.1 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
I note Max core profile version: 0.0, which I have read is not good, but I do not know what to do about it.
On Fri, 21 Jun 2024, Michael Hennebry wrote:
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support.
Correction: could not initialise openGL support
I've installed pretty much everything I can think of, including *opengl* , *openGL* and *mesa* . No go. Firefox can play local movies.
On Fri, 2024-06-21 at 09:44 -0500, Michael Hennebry wrote:
On Fri, 21 Jun 2024, Michael Hennebry wrote:
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support.
Correction: could not initialise openGL support
I've installed pretty much everything I can think of, including *opengl* , *openGL* and *mesa* . No go. Firefox can play local movies.
-- Michael hennebry@mail.cs.ndsu.NoDak.edu "SCSI is NOT magic. There are *fundamental technical reasons* why it is necessary to sacrifice a young goat to your SCSI chain now and then." -- John Woods --
Maybe a codec issue? Try 'mediainfo' on the file and possibly install any missing codecs from RPMfusion.
poc
On Fri, 21 Jun 2024, Patrick O'Callaghan wrote:
On Fri, 2024-06-21 at 09:44 -0500, Michael Hennebry wrote:
On Fri, 21 Jun 2024, Michael Hennebry wrote:
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support.
Correction: could not initialise openGL support
I've installed pretty much everything I can think of, including *opengl* , *openGL* and *mesa* . No go. Firefox can play local movies.
Maybe a codec issue? Try 'mediainfo' on the file and possibly install any missing codecs from RPMfusion.
$ mediainfo chloe*.MOV | grep -i codec Codec ID : qt 0000.00 (qt ) Format/Info : Advanced Video Codec Codec ID : avc1 Codec ID/Info : Advanced Video Coding Codec configuration box : avcC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Codec ID : mebx Codec ID : mebx Codec ID : mebx
I've not gotten anywhere searching for any of these. Strange that firefox can play it, but totem cannot.
On Sun, 2024-06-23 at 17:54 -0500, Michael Hennebry wrote:
On Fri, 21 Jun 2024, Patrick O'Callaghan wrote:
On Fri, 2024-06-21 at 09:44 -0500, Michael Hennebry wrote:
On Fri, 21 Jun 2024, Michael Hennebry wrote:
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support.
Correction: could not initialise openGL support
I've installed pretty much everything I can think of, including *opengl* , *openGL* and *mesa* . No go. Firefox can play local movies.
Maybe a codec issue? Try 'mediainfo' on the file and possibly install any missing codecs from RPMfusion.
$ mediainfo chloe*.MOV | grep -i codec Codec ID : qt 0000.00 (qt ) Format/Info : Advanced Video Codec Codec ID : avc1 Codec ID/Info : Advanced Video Coding Codec configuration box : avcC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Codec ID : mebx Codec ID : mebx Codec ID : mebx
I've not gotten anywhere searching for any of these. Strange that firefox can play it, but totem cannot.
AFAIK Firefox has its own built-in codecs, while totem uses the gstreamer library and plugins. Here's what I have:
$ rpm -qa gstreamer* gstreamer1-svt-vp9-0.3.0-11.fc40.x86_64 gstreamermm-1.10.0-22.fc40.x86_64 gstreamer1-1.24.4-1.fc40.x86_64 gstreamer1-plugins-base-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-qt-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-qt6-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-gtk-1.24.4-1.fc40.x86_64 gstreamer1-1.24.4-1.fc40.i686 gstreamer1-vaapi-1.24.4-1.fc40.x86_64 gstreamer1-plugin-libav-1.24.4-1.fc40.x86_64 gstreamer1-plugins-ugly-free-1.24.4-1.fc40.x86_64 gstreamer1-plugins-base-1.24.4-1.fc40.i686 gstreamer1-plugin-openh264-1.24.4-2.fc40.x86_64 gstreamer1-plugins-bad-free-libs-1.24.4-2.fc40.x86_64 gstreamer1-plugins-bad-free-1.24.4-2.fc40.x86_64 gstreamer1-svt-av1-2.1.0-1.fc40.x86_64 gstreamer1-plugins-good-1.24.4-1.fc40.i686 gstreamer1-plugins-ugly-1.24.4-1.fc40.x86_64
Note that gstreamer1-plugins-ugly is from RPMfusion because of licensing issues.
poc
On Mon, 24 Jun 2024, Patrick O'Callaghan wrote:
On Sun, 2024-06-23 at 17:54 -0500, Michael Hennebry wrote:
Strange that firefox can play it, but totem cannot.
AFAIK Firefox has its own built-in codecs, while totem uses the gstreamer library and plugins. Here's what I have:
$ rpm -qa gstreamer* gstreamer1-svt-vp9-0.3.0-11.fc40.x86_64 gstreamermm-1.10.0-22.fc40.x86_64 gstreamer1-1.24.4-1.fc40.x86_64 gstreamer1-plugins-base-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-qt-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-qt6-1.24.4-1.fc40.x86_64 gstreamer1-plugins-good-gtk-1.24.4-1.fc40.x86_64 gstreamer1-1.24.4-1.fc40.i686 gstreamer1-vaapi-1.24.4-1.fc40.x86_64 gstreamer1-plugin-libav-1.24.4-1.fc40.x86_64 gstreamer1-plugins-ugly-free-1.24.4-1.fc40.x86_64 gstreamer1-plugins-base-1.24.4-1.fc40.i686 gstreamer1-plugin-openh264-1.24.4-2.fc40.x86_64 gstreamer1-plugins-bad-free-libs-1.24.4-2.fc40.x86_64 gstreamer1-plugins-bad-free-1.24.4-2.fc40.x86_64 gstreamer1-svt-av1-2.1.0-1.fc40.x86_64 gstreamer1-plugins-good-1.24.4-1.fc40.i686 gstreamer1-plugins-ugly-1.24.4-1.fc40.x86_64
Note that gstreamer1-plugins-ugly is from RPMfusion because of licensing issues.
Could not find it in rpnfusion-nonfree-* . Found it in rpmfusion-free-source rpmfusion-free-updates-source rpmfusion-free-debuginfo rpmfusion-free-updates-debuginfo
None of them seem right. I installed the rpmfusion .rpm's listed here: https://rpmfusion.org/Configuration I had to use rpm, as firefox just downloaded.
To search for the package, I used sudo dnf --enablerepo=rpmfusion-* whatprovides '*plugins-ugly-1.2*' | grep Repo
From which rpmfusion repo did your gstreamer1-plugins-ugly-1.24.4-1.fc40.x86_64 come?
This wrangling with fedora vs. rpmfusion has a familiar ring to it. Once I have the correct repositories, wold it be wise of me to: 1. Delete all the gstreamer stuff. 2. Mark all my rpmfusion repos as having a higher priority than the redhat repos. 3. Install the gstreamer stuff. ?
Would this require booting to a non-graphical level?
On 6/24/24 5:58 PM, Michael Hennebry wrote:
On Mon, 24 Jun 2024, Patrick O'Callaghan wrote:
Note that gstreamer1-plugins-ugly is from RPMfusion because of licensing issues.
Could not find it in rpnfusion-nonfree-* . Found it in rpmfusion-free-source rpmfusion-free-updates-source rpmfusion-free-debuginfo rpmfusion-free-updates-debuginfo
None of them seem right. I installed the rpmfusion .rpm's listed here: https://rpmfusion.org/Configuration I had to use rpm, as firefox just downloaded.
To search for the package, I used sudo dnf --enablerepo=rpmfusion-* whatprovides '*plugins-ugly-1.2*' | grep Repo
Why are you looking for provides? It's a package name. # dnf search -v plugins-ugly ========================================================================================================= Name Matched: plugins-ugly ========================================================================================================= gstreamer1-plugins-ugly.i686 : GStreamer 1.0 streaming media framework "ugly" plug-ins Repo : rpmfusion-free-updates Matched from: Provide : gstreamer1-plugins-ugly = 1:1.24.4-1.fc40
gstreamer1-plugins-ugly.x86_64 : GStreamer 1.0 streaming media framework "ugly" plug-ins Repo : rpmfusion-free-updates Matched from: Provide : gstreamer1-plugins-ugly = 1:1.24.4-1.fc40
gstreamer1-plugins-ugly-free.i686 : GStreamer streaming media framework "ugly" plugins Repo : updates-testing Matched from: Provide : gstreamer1-plugins-ugly-free = 1.24.5-1.fc40
gstreamer1-plugins-ugly-free.x86_64 : GStreamer streaming media framework "ugly" plugins Repo : updates-testing Matched from: Provide : gstreamer1-plugins-ugly-free = 1.24.5-1.fc40
From which rpmfusion repo did your gstreamer1-plugins-ugly-1.24.4-1.fc40.x86_64 come?
This wrangling with fedora vs. rpmfusion has a familiar ring to it. Once I have the correct repositories, wold it be wise of me to:
- Delete all the gstreamer stuff.
- Mark all my rpmfusion repos as having a
higher priority than the redhat repos. 3. Install the gstreamer stuff. ?
There's no need for any of that. Generally there are no conflicts other than things like "ffmpeg" vs. "ffmpeg-free". You need the gstreamer packages from both sides.
Would this require booting to a non-graphical level?
No. You're only installing new libraries, not removing anythign.
On Mon, 24 Jun 2024, Samuel Sieb wrote:
On 6/24/24 5:58 PM, Michael Hennebry wrote:
On Mon, 24 Jun 2024, Patrick O'Callaghan wrote:
Note that gstreamer1-plugins-ugly is from RPMfusion because of licensing issues.
# dnf search -v plugins-ugly
Have it now, but it did not help.
Any ideas?
On 6/25/24 4:15 PM, Michael Hennebry wrote:
On Mon, 24 Jun 2024, Samuel Sieb wrote:
On 6/24/24 5:58 PM, Michael Hennebry wrote:
On Mon, 24 Jun 2024, Patrick O'Callaghan wrote:
Note that gstreamer1-plugins-ugly is from RPMfusion because of licensing issues.
# dnf search -v plugins-ugly
Have it now, but it did not help.
Any ideas?
I don't. I usually use vlc, but I just tried totem (Videos) and it played anything I tried, include h265.
Michael Hennebry:
Any ideas?
Samuel Sieb:
I don't. I usually use vlc, but I just tried totem (Videos) and it played anything I tried, include h265.
I found totem rather bad for playing some files, likewise with parole media player (what an awful name for a media player - and it nearly always wants to download some codec, but either can't, or it doesn't help).
Likewise, I tend to use VLC for playing files in general. Or, mpv when double-clicking on single files in a file browser (it's simpler and quicker to start). But if I want to treat the PC as a jukebox, VLC is better for just dropping files onto the playlist and letting it run.
If the original poster might try some other players, it may point some fingers at things to resolve. Some players are more self-contained than others.
On 6/26/24 12:37 PM, Tim via users wrote:
Michael Hennebry:
Any ideas?
Samuel Sieb:
I don't. I usually use vlc, but I just tried totem (Videos) and it played anything I tried, include h265.
I found totem rather bad for playing some files, likewise with parole media player (what an awful name for a media player - and it nearly always wants to download some codec, but either can't, or it doesn't help).
Likewise, I tend to use VLC for playing files in general. Or, mpv when double-clicking on single files in a file browser (it's simpler and quicker to start). But if I want to treat the PC as a jukebox, VLC is better for just dropping files onto the playlist and letting it run.
If the original poster might try some other players, it may point some fingers at things to resolve. Some players are more self-contained than others.
I used to have issues with totem for some files, so I was rather surprised when I tested it and it just worked. :-) But it wasn't a very extensive test, just files that were handy that I thought might have issues.
On 6/21/24 07:44, Michael Hennebry wrote:
On Fri, 21 Jun 2024, Michael Hennebry wrote:
Possibly related: totem does not play movies. totem complains that it cannot initialize openGL support.
I can't dissect a .rpm but I know how to dissect a .deb so I installed totem onto Ubuntu 24.04 (latest release) so I could take it apart. There was no need for anything that drastic...
Running totem I got the same results you are seeing:
An error occurred Could not initialize OpenGL support
Methinks it is not a problem with your setup.
Browsers and VLC all play videos just fine...
On Mon, 2024-06-24 at 19:48 -0700, Mike Wright wrote:
I can't dissect a .rpm but I know how to dissect a .deb so I installed totem onto Ubuntu 24.04 (latest release) so I could take it apart.
You can open them in an archive manager (treating them the same as zip files, and various other archive formats). Allowing you to see the contents, and interact with some of them).
And you can list the contents from the command line.
e.g. rpm -qlp packagename.rpm
On Mon, Jun 24, 2024, at 11:23 PM, Tim via users wrote:
On Mon, 2024-06-24 at 19:48 -0700, Mike Wright wrote:
I can't dissect a .rpm but I know how to dissect a .deb so I installed totem onto Ubuntu 24.04 (latest release) so I could take it apart.
You can open them in an archive manager (treating them the same as zip files, and various other archive formats). Allowing you to see the contents, and interact with some of them).
And you can list the contents from the command line.
e.g. rpm -qlp packagename.rpm
Just adding my saved note on how it can be done:
Pull files out of an rpm without installing it: mkdir foo ; cp file.rpm foo ; cd foo rpm2cpio - < file.rpm | cpio --extract --no-absolute-filenames --make-directories
Doug Herr wrote:
Just adding my saved note on how it can be done:
Pull files out of an rpm without installing it: mkdir foo ; cp file.rpm foo ; cd foo rpm2cpio - < file.rpm | cpio --extract --no-absolute-filenames --make-directories
Or simpler, IMO:
Install 'rpmdevtools' and use:
rpmdev-extract /path/to/package
It supports a good number of package/archive formats, not just rpm.
On 6/25/24 18:13, Doug Herr wrote:
On Mon, Jun 24, 2024, at 11:23 PM, Tim via users wrote:
Just adding my saved note on how it can be done:
Pull files out of an rpm without installing it: mkdir foo ; cp file.rpm foo ; cd foo rpm2cpio - < file.rpm | cpio --extract --no-absolute-filenames --make-directories
Alternatively, with midnight commander you can just "enter" the rpm as if it were a directory. (and the same happens for most archive formats)
Regards.
-
Barry -
Barry Scott
-
Doug Herr -
Joe Zeff -
Jonathan Billings -
Michael Hennebry -
Mike Wright -
Patrick O'Callaghan -
Roberto Ragusa -
Roger Heflin -
Samuel Sieb -
Tim -
Todd Zullinger -
Tom Horsley