The small linux problem thread

this is the way. steer clear of cut -d' ' cos it’ll munt up files with spaces in them. awk is the way to go.

more than welcome mate, was a pleasure :+1:

I’m having issues trying to watch video files over the network from a SMB share, I can do it no problem from my windows laptop, but I need to drag the file into my desktop(running manjaro) to play it.

the applications(MPV and VLC) just immediately close after opening the file, not sure if it matters, but I’ve tested it with .MKV and .mp4 files same results.

Strangely enough, VLC doesn’t work at all now either. Closes immediately after opening a file.

Have you tried starting vlc from a command prompt to see what messages it outputs before it closes?

2 Likes
-- logger module started --
main warning: cannot load module `/usr/lib/vlc/plugins/visualization/libgoom_plugin.so' (libgoom2.so.0: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/visualization/libprojectm_plugin.so' (libprojectM.so.3: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/control/liblirc_plugin.so' (liblirc_client.so.0: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/demux/libts_plugin.so' (libaribb24.so.0: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/codec/libkate_plugin.so' (libtiger.so.5: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/codec/libaribsub_plugin.so' (libaribb24.so.0: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/access/liblive555_plugin.so' (libliveMedia.so.107: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/access/libnfs_plugin.so' (libnfs.so.14: cannot open shared object file: No such file or directory)
main warning: cannot load module `/usr/lib/vlc/plugins/stream_filter/libaribcam_plugin.so' (libaribb25.so.0: cannot open shared object file: No such file or directory)
main: Running vlc with the default interface. Use 'cvlc' to use vlc without interface.
faad warning: decoded zero sample
gl: Initialized libplacebo v5.229.0 (API v229)
glconv_vaapi_x11 error: vaInitialize: unknown libva error

this is what I ended up getting from the VLC’s logger

1 Like

Looks like your VLC install is a little borked… You’re missing plugin files that seem to be provided by VLC itself. My VLC installation on arch w/ no plugins has all those files.

Did you mess with VLC plugins at some point? You may want to try reinstalling VLC on that machine.

1 Like

this is most likely the culprit of your media player closing problems. it can’t use VAAPI.

you should try to install vaapi again for your gpu: Hardware video acceleration - ArchWiki

the rest of the modules just look like incidental to me, the va one is serious

1 Like

Hi Linux gurus,
I installed Manjaro on my new 13700k/z690.
Worked fine for few days then I get this during boot. Not sure where to start. I think the only change I made was a switch to the proprietary NVIDIA drivers. Any tips? Seems related to Intel integrated graphics?

Did you successfully install the nVidia drivers?
You can try to disable the Intel iGPU in uEFI to see if the nVidia card finally takes over. Otherwise you will need to look at mode setting and blacklisting drivers.

https://wiki.archlinux.org/title/NVIDIA

Does anyone know how to fix this issue I ran into with the Intel Ethernet Controller is not properly configured? Here is the hardware probe for my computer. I am using a Caldigit TS4, but the ethernet was working properly prior to this previous weekend.

I’m running NixOS, kernel version 6.1.11, with a 7950X on a ProArt X670E, which is nice, but I’m getting some annoying issues with suspending the machine. On issuing a systemctl suspend, the machine will dutifully go to sleep, and then immediately wake again. Issuing another systemctl suspend will put it to sleep for real.

I fixed this a few months ago, or so I thought, when I added a script to systemd’s pre-sleep.service target:

echo XHC0 > /proc/acpi/wakeup
echo XHC1 > /proc/acpi/wakeup
echo XHC2 > /proc/acpi/wakeup

Unfortunately, the solution was short lived and the issue returned. Any ideas for things I could try?

Is there anything else that’s enabled in /proc/acpi/wakeup? Might as well try disabling them all (except PWRB) and see if you fare better.

There’s also the option of rmmod -ing any non-crucial kernel modules (like sound drivers) before suspending.

Troubleshooting acpi suspend issues is a whole topic in itself:

try going into bios and disabling wake up on lan (magic packet).
it might be your network connection waking the pc if its set up to wake on lan.

/etc/pm/sleep.d

/usr/lib/pm-utils/sleep.d

check both locations and see if theres any scripts you want to adjust parameters in.

cat /sys/power/state
cat /sys/power/mem_sleep

check to see if your system is using and alt instruction to hibernate and wake.
apparently there are a couple.

look here for more info…

Is there anything else that’s enabled in /proc/acpi/wakeup ? Might as well try disabling them all (except PWRB) and see if you fare better.

$ cat /proc/acpi/wakeup
Device  S-state   Status   Sysfs node
GPP3      S4    *disabled
GPP4      S4    *disabled
GPP5      S4    *disabled
GPP6      S4    *disabled
GP17      S4    *enabled   pci:0000:00:08.1
XHC0      S4    *disabled  pci:0000:6e:00.3
XHC1      S4    *disabled  pci:0000:6e:00.4
XHC2      S4    *disabled  pci:0000:6f:00.0
GPP0      S4    *enabled   pci:0000:00:01.1
SWUS      S4    *enabled   pci:0000:01:00.0
SWDS      S4    *enabled   pci:0000:02:00.0
GPP1      S4    *enabled   pci:0000:00:01.2
GPP2      S4    *disabled
GPP7      S4    *disabled  pci:0000:00:02.1
UP00      S4    *enabled   pci:0000:05:00.0
DP40      S4    *enabled   pci:0000:06:08.0
UP00      S4    *enabled   pci:0000:08:00.0
DP00      S4    *enabled   pci:0000:09:00.0
WIFI      S4    *disabled  pci:0000:0a:00.0
DP08      S4    *enabled   pci:0000:09:01.0
I225      S4    *enabled   pci:0000:0b:00.0
DP10      S4    *enabled   pci:0000:09:02.0
AQCL      S4    *disabled  pci:0000:0c:00.0
DP20      S4    *enabled   pci:0000:09:04.0
TBTC      S4    *enabled   pci:0000:0e:00.0
DP50      S4    *disabled
PX16      S4    *disabled
DP60      S4    *enabled   pci:0000:09:0c.0
XH00      S4    *enabled   pci:0000:69:00.0
DP60      S4    *enabled   pci:0000:06:0c.0
XH00      S4    *enabled   pci:0000:6b:00.0

I started with XHC because I assumed those were USB3, and I’ve had similar suspend issues caused by USB3 on Windows in the past, but it was pure guesswork and honestly I’m not even sure it was actually the thing that helped. Checking the PCI addresses against lspci confirms that these are the USB3 controllers. Suspend remained finicky for a week, then started working fine, and now isn’t working again. All sorts of system updates going on too, I didn’t keep track of versions. Most of the other addresses are host bridge and PCI bridges, no PWRB (power button?) though. Honestly as long as I can wake the machine with poweronlan, the keyboard, or wiggling the mouse, I’m fine. It’s in a rack, I never push the power button anyways.

Curiously, it seems I can’t actually disable everything. Some of the entries are duplicates, and I can only toggle the first occurence of each one.

Device  S-state   Status   Sysfs node
GPP3      S4    *disabled
GPP4      S4    *disabled
GPP5      S4    *disabled
GPP6      S4    *disabled
GP17      S4    *disabled  pci:0000:00:08.1
XHC0      S4    *disabled  pci:0000:6e:00.3
XHC1      S4    *disabled  pci:0000:6e:00.4
XHC2      S4    *disabled  pci:0000:6f:00.0
GPP0      S4    *disabled  pci:0000:00:01.1
SWUS      S4    *disabled  pci:0000:01:00.0
SWDS      S4    *disabled  pci:0000:02:00.0
GPP1      S4    *disabled  pci:0000:00:01.2
GPP2      S4    *disabled
GPP7      S4    *disabled  pci:0000:00:02.1
UP00      S4    *disabled  pci:0000:05:00.0
DP40      S4    *disabled  pci:0000:06:08.0
UP00      S4    *enabled   pci:0000:08:00.0
DP00      S4    *disabled  pci:0000:09:00.0
WIFI      S4    *disabled  pci:0000:0a:00.0
DP08      S4    *disabled  pci:0000:09:01.0
I225      S4    *disabled  pci:0000:0b:00.0
DP10      S4    *disabled  pci:0000:09:02.0
AQCL      S4    *disabled  pci:0000:0c:00.0
DP20      S4    *disabled  pci:0000:09:04.0
TBTC      S4    *disabled  pci:0000:0e:00.0
DP50      S4    *disabled
PX16      S4    *disabled
DP60      S4    *disabled  pci:0000:09:0c.0
XH00      S4    *disabled  pci:0000:69:00.0
DP60      S4    *enabled   pci:0000:06:0c.0
XH00      S4    *enabled   pci:0000:6b:00.0

lspci identifies these as:

08:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43f4 (rev 01)
06:0c.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43f5 (rev 01)
6b:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43f7 (rev 01)

If any of these were the problem, I’d suspect the 6b USB controller. I have tried unplugging all USB peripherals, though, and it doesn’t help.
Disabling everything hasn’t helped, though, and in fact suspend is now completely broken no matter what I do. Rebooting brought it back to how it was before, but disabling everything again re-broke it.

That link is really in depth, thanks. I’ll sit down this weekend and try to get through it.

try going into bios and disabling wake up on lan (magic packet).

Nah, I need WoL. Having it off doesn’t solve the issue, though, disabling it was one of the first things I tried.

$ find / -name sleep.d
/nix/store/l2wm0n1lqczrk85943jjk6w10f1bhfb6-pm-utils-1.4.1/lib/pm-utils/sleep.d
/nix/store/mfg3rds43265g4hhxj8jmnqjzaky6h9d-pm-utils-1.4.1/lib/pm-utils/sleep.d

They contain some scripts. No idea what they do, but nothing looks strange to me.

$ cat /nix/store/l2wm0n1lqczrk85943jjk6w10f1bhfb6-pm-utils-1.4.1/lib/pm-utils/sleep.d/00powersave
#!/nix/store/qqa28hmysc23yy081d178jfd9a1yk8aw-bash-5.2-p15/bin/sh

. "${PM_FUNCTIONS}"

command_exists pm-powersave || exit $NA

case $1 in
    suspend|hibernate) pm-powersave false ;;
    resume|thaw)       pm-powersave ;;
    *) exit $NA ;;
esac
exit 0
    %
$ cat /sys/power/state
freeze mem
$ cat /sys/power/mem_sleep
s2idle [deep]

The issue isn’t the command I’m using. systemctl suspend works, I just have to issue it twice for some reason. The first time the machine wakes instantly, but if I issue the same command again within a minute or so, it works properly.

I get the impression that suspending/hibernating Linux machines is another one of those core functionalities that are just fundamentally broken because servers don’t use them, like sound, or Wayland, or Nvidia drivers. I guess I should consider myself lucky that this is pretty inconsequential as far as problems go. I don’t have to suspend this machine, it’s in a closet so I can just leave it idling if I have to.

1 Like

S3 suspend is complex, many OEMs screw up their part of it and workarounds for buggy hardware need to be implemented in software. If you stick to more common systems, it is well supported in Linux.

1 Like

Hey, I have an application that I had to compile from source since the developer doesn’t care enough about Linux to create a binary for it. Anyway, the application creates a directory ~/PropellerIDE\ Projects on startup. This is highly annoying to me because I am very particular about the directory tree within my home directory. Well, I was thinking I could use SELinux policy or something to prevent the application from being able to create new directories in my system. Is it possible to do this, or should I look for another solution?

If you compiled it from source, you should be able to find the line where it is creating it, and change the path, or remove it entirely. But yes, a carefully written SELinux policy should allow you to prevent it.

1 Like

I want to get more familiar with SELinux. I know I could fix the line of code, and that would probably be easier; but why take the easy way out? :stuck_out_tongue:

What is security.NTACL? It just screams SELinux to me. I get this error, mv: setting attribute 'security.NTACL' for 'security.NTACL': Operation not permitted, when moving a file on my local filesystem to an NFS mounted filesystem. My local filesystem is using BTRFS, but my NFS filesystem is using XFS.

Sounds more like a Windows NT file system ACLs to me. And a quick web search hasn’t dissuaded me:

Anyone know how to make use of LVM snapshots when using LVM on LUKS?

steps to reproduce:

  1. Create LVM snapshot of root logical volume ( which resides in LUKS encrypted partition, which is decrypted during boot by unencrypted unified kernal with built-in initramfs)
  2. the system will fail to boot until I boot from rescue media and remove the root snapshot.

Very annoying because I can’t take LVM snapshots prior to rolling release distro system updates, trying out system changes, etc.