users July 2022

users@lists.fedoraproject.org

93 participants
116 discussions

Update to f36: problem with wine libvkd3d-1.dll not found
by Gianluca Cecchi 20 Jul '22

20 Jul '22

Hello, I was using an application (Booktab for reading school manuals) that worked in fedora 35. After updating to fedora 36 when I run it I get: $ pwd /home/g.cecchi/.wine/drive_c/Program Files (x86)/Booktab $ wine ./Booktab.exe 002c:fixme:winediag:LdrInitializeThunk wine-staging 7.12 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org. MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0 0118:err:module:import_dll Library libvkd3d-shader-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found 0118:err:module:import_dll Library libvkd3d-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found 0118:err:module:import_dll Library wined3d.dll (which is needed by L"C:\\windows\\system32\\d3d9.dll") not found 0118:err:module:import_dll Library d3d9.dll (which is needed by L"C:\\Program Files (x86)\\Booktab\\Booktab.exe") not found 0118:err:module:import_dll Library libvkd3d-shader-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found 0118:err:module:import_dll Library libvkd3d-1.dll (which is needed by L"C:\\windows\\system32\\wined3d.dll") not found 0118:err:module:import_dll Library wined3d.dll (which is needed by L"C:\\windows\\system32\\DDRAW.dll") not found 0118:err:module:import_dll Library DDRAW.dll (which is needed by L"C:\\Program Files (x86)\\Booktab\\Booktab.exe") not found 0118:err:module:LdrInitializeThunk Importing dlls for L"C:\\Program Files (x86)\\Booktab\\Booktab.exe" failed, status c0000135 Any hint on how to use it again? BTW: do I have to worry about the message above "wine-staging 7.12 is a testing version containing experimental patches"? Why this choice in case? Thanks, Gianluca

4 7

Re: Update to f36: problem with wine libvkd3d-1.dll not found
by Gianluca Cecchi 20 Jul '22

20 Jul '22

On Wed, Jul 20, 2022 at 3:24 PM Lily White <lilywhite2005(a)outlook.com> wrote: > > BTW: do I have to worry about the message above "wine-staging 7.12 is a > > testing version containing experimental patches"? Why this choice in > case? > > Generally, no, `wine' should be relatively stable even it is staging. > > Moreover, when a Fedora version rolls out, the corresponding wine > *usually* has been moved to stable already. > > Lily > > Ok, thanks for the clarification, Lily Gianluca

1 0

qemu crashes kernel-5.18.11-200.fc36.x86_64
by Sam Varshavchik 20 Jul '22

20 Jul '22

Am I the only one lucky enough to have kernel-5.18.11-200.fc36.x86_64 crash reliably, on particular hardware, after starting a VM in virt-manager? At least I think it's a crash. One second after a VM start it's brick-city. Display frozen, no response from the network. I've got nothing: after a reboot there's nothing in journalctl -r -b -1. This brings up fond memories -- ages ago I had a null modem adapter hooked up to a serial port, the kernel configured for a serial console, thusly I was able to capture OOPSes over the serial console, in situations like these. But, these days, no more RS-232 ports. I dimly recall that a USB-serial option is possible; but I don't have any of that in any case. Anyway, reverting to 5.18.9 made this VM happy, and my VMs on another hardware, also running the same kernel, are also fine. But, 5.18.11 gets reliably clusterfarked by qemu on at least on some hardware combinations. I wish I had more useful data points, but I've got nuthin' worth putting into Bugzilla.

6 10

specialist audio configurations
by Tim 20 Jul '22

20 Jul '22

Hi, Has pulseaudio/pipewire got to the stage where we can specify output channels in our own way? For instance, I use a Behringer UMC1820 for sound input/output. It's a multichannel thing, over 10 inputs and outputs. You can record multichannel, that works fine (usually). Occasionally there's some restarting/rebooting fights to get things working with Audacity (internal sound versus USB), and working at the correct speeds (playback being slower than record, not knowing if one or both were off-speed). It might only take a system ding, or a website sound, to suddenly make Audacity play slowly (speed and pitch change). That kind of issue isn't too surprising, all things considered. I don't know if there's always a preset internal bitrate that pulseaudio transcodes on demand, or it switches bitrates all the time to track the input sources and output devices. I mostly worked in 44100 bitrates suited to CD audio, though now I'm trialling 48000 commonly used for video applications, since compact disc usage is getting rarer. Multichannel playback is another issue. The OS thinks its a surround sound system. So for the few things that can do more than two-channel stereo, it thinks the other outputs are a specific use for front, back, side, left, right, which aren't actually the case. It would be good if there was a way to specify the purpose of each output in a custom way, or even just have general purpose channel 1, 2, 3, 4, 5, etc. Bye, Tim. -- uname -rsvp Linux 3.10.0-1160.71.1.el7.x86_64 #1 SMP Tue Jun 28 15:37:28 UTC 2022 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list.

1 0

Is there an officially Fedora supported replacement for the old rc.local?
by Peter Boy 20 Jul '22

20 Jul '22

I have to run some scripts at the end of the boot process to establish various workarounds for bugs in systemd. In the days of System V, /etc/rc.d/rc.local would be the right place for this. My research revealed several solutions with conflicting recommendations: (a) There is - also in Fedora - systemd-rc-local service. In the man file it is advised not to use it. A Fedora default installation also does not completely create the necessary directory structure. And if one wants to execute this service as far as possible at the end of the boot process, further adjustments are necessary. (b) There is the DIY suggestion to create a service of one's own, and to place it as far as possible at the end of the system start. (c) A suggestion is to insert in the root-crontab at the end @reboot systemctl start …. The latter seems to be the most reliable solution at the moment. Any recommendations and/or experiences?

8 15

beat updatedb over the head?
by Tom Horsley 19 Jul '22

19 Jul '22

The timer installed by plocate insists on running updatedb at maximally inconvenient times. I looked at the docs for systemd timers and my brain screamed at me: "I don't feel like thinking hard enough to get this right!" Anyone have an example of a systemd timer that runs at a specific time of day (like 1AM) so I can avoid thinking too hard? :-). Can I override an installed systemd timer by putting a replacement with the same name under /etc somewhere?

3 3

MariaDB in Fedora - retiring 10.3 & 10.4 series
by Michal Schorm 19 Jul '22

19 Jul '22

Hello everyone, Due to several circumstances I am stopping all efforts in maintaining MariaDB 10.3 & 10.4 series in Fedora. Just before that, I rebased both series to the latest upstream versions, so you will get all the security patches released as for today ! MariaDB 10.3: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-0cd0202272 MariaDB 10.4: https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-c58e1ae21e Also, please notice that neither series is available in Fedora > 35, because our efforts to cherry-pick the OpenSSL 3 patch from the 10.8 series were unsuccessful. Furthermore, please note that _on upstream_ : MariaDB 10.3 will reach 'end of standard support' and EOL on: 25 May 2023 MariaDB 10.4 reached 'end of standard support' on: 02 July 2022 and will reach EOL on: 02 July 2024 -- I strongly recommend updating your applications to at least MariaDB 10.5 series. MariaDB upstream changed it's release model some time ago [1]. The upstream expects to release a new _serie_ every three months. Every new series (starting 10.6) support period was shortened to _one year_ only. Some of the series will be marked as LTS (long term support) with support period being at least 5 years. First serie marked as LTS is 10.6 Second serie that will _likely_ be marked as LTS is 10.10 My personal focus - as the package maintainer - is on the MariaDB 10.5 ; and MariaDB 10.10 (should it be marked LTS). Please consider all other series maintained (by me in Fedora) on 'best effort' basis only. The golden rule in case of my packages is that the development is done in base Fedora (branch 'rawhide'), so whichever version there is, it is the one maintained with most care. -- As always, anyone is welcome to submit patches or (preferably) pull requests to packages I maintain, or step in to maintain MariaDB series I don't have capacity for. Feel free to ask more questions if you are interested, I'll answer what I can. I wish you a nice day and stable DB servers :) [1] https://mariadb.com/newsroom/press-releases/mariadb-announces-new-innovatio… [2] rel-eng ticket regarding setting the EOL date: https://pagure.io/releng/issue/10902 [3] Wiki page with info which series are in which Fedora releases: https://fedoraproject.org/wiki/MariaDB_software -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --

1 0

Re: Is there an officially Fedora supported replacement for,> the old rc.local? - still an issue
by R. G. Newbury 19 Jul '22

19 Jul '22

>> Am 18.07.2022 um 22:18 schrieb Peter Boy<pboy(a)uni-bremen.de>: wrote >> >> I got it finally working. > After some tests: It isn’t. > > The programs I have to start depend on the existence of some (virtual) network interfaces. rc.local is ordered after network.target, which doesn’t mean, the network is functional then. Therefore, the program start via rc.local is in indeterministic process. Sometimes it works, sometimes not, sometimes only for some. > > Documentation mentions a drop in at/etc/systemd/system/rc-local.service.d/network.conf. But there is no > subdirectory /etc/systemd/system/rc-local.service.d/ > > Should I really mess around with vim and mkdir in the directories managed by the distribution? Seems like a bad idea to me. > > Or have I missed something? There is a cleaner workaround, which does, unfortunately mean you have to do some minor file amendments (with vim, *of course*!) Your original /etc/rc.d/rc.local is renamed: mv rc.local the-real-rc.local /etc/rc.d/rc.local is replaced with a new version: <code> #!/bin/bash # to run rc.local type things, without interference from systemd # rc-local: /usr/bin/at -M now <<'HERE' > /dev/null 2>&1 /etc/rc.d/the-real-rc.local HERE # And everything I used to run in rc.local now gets run # from the-real-rc.local, untouched by systemd meddling # (Resistance was futile, I was assimilated). </code> Both of these files have to be executable (chmod 755). The /usr/systemd/rc-local.service file IS NOT TOUCHED, so there are no problems with it being overwritten. (might need to be enabled. I cannot remember.) The rc-local service checks the rc.local file, and IF it is executable, will run it. The new version rc.local calls 'the-real-rc.local'. Your 'the-real-rc.local' file can have a sleep or structured pause until the networks respond properly and signal they are awake. This sleight-of-hand was posted by someone on an Arch distro forum/mailing list. I do not have his name, but kudos and thanks whoever you are. It works In addition, you can also split your 'real' file, by creating a semaphore file in /tmp, and run different sections. If you prefer you can run a 'real' files only on the first run after a boot, or even after an install. If you have not yet changed, for example, /var/lib/mysql from a directory to a link to somewhere else, then this is the first run after a re-install, and that has not yet been done: an install, in my experience, whether told to format or not to format, will wipe the /var partition, and all of the databases in that folder. I put them elsewhere and link to there, so no losses. So obviously one thing I want to do is change the folder to a link to the proper place. And obviously there are a plethora of things which need to be done *once* after an install. Needs one 'if' statement in the bash script. A re-run will skip the block. Geoff

2 1

diagnosing XFS corruption after upgrading to Fedora 36
by Patrick Hemmer 19 Jul '22

19 Jul '22

Ever since upgrading to Fedora 36, my root filesystem is getting corrupted every few hours. I maintain block level backups, and I have to restore every time this happens. xfs_repair can fix the filesystem, but the system is typically unusable as there's often over 10k files in lost+found. I have tried creating a brand new filesystem (mkfs.xfs), but it still gets corrupted. I would file a bug, but the caveat is that I also have LVM underneath the filesystem. And so I don't know whether it's a problem with XFS, or LVM. I have other XFS filesystems also on LVM, and have seen corruption on them as well, but it's nowhere near as significant or frequent as on the root filesystem. Sometimes I can detect the corruption before the kernel does, by doing a snapshot, and running `xfs_repair -n` on the snapshot. And sometimes the kernel will detect the corruption first, usually with a message like: Jul 17 15:06:52 whistler kernel: XFS (dm-0): Metadata corruption detected at xfs_buf_ioend+0x14c/0x5d0 [xfs], xfs_inode block 0x46057c8 xfs_inode_buf_verify Jul 17 15:06:52 whistler kernel: XFS (dm-0): Unmount and run xfs_repair Jul 17 15:06:52 whistler kernel: XFS (dm-0): First 128 bytes of corrupted metadata buffer: Jul 17 15:06:52 whistler kernel: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Jul 17 15:06:52 whistler kernel: XFS (dm-0): metadata I/O error in "xfs_imap_to_bp+0x40/0x50 [xfs]" at daddr 0x46057c8 len 32 error 117 Jul 17 15:06:52 whistler kernel: XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x179/0x2d0 [xfs] (fs/xfs/xfs_trans_buf.c:296). Shutting down filesystem. Jul 17 15:06:52 whistler kernel: XFS (dm-0): Please unmount the filesystem and rectify the problem(s) So how can I proceed on this? Is there any way to determine whether this is an LVM issue or an XFS issue?

4 5

Is it possible to protect OpenSSH Daemon logins with 2nd factor authentication (2FA)?
by Turritopsis Dohrnii Teo En Ming 19 Jul '22

19 Jul '22

Subject: Is it possible to protect OpenSSH Daemon logins with 2nd factor authentication (2FA)? Good day from Singapore, Is it possible to protect OpenSSH Daemon logins with 2nd factor authentication (2FA)? If it is possible, could you give me the links to excellent and well-written guides on how to do so? Thank you very much. Regards, Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore 19 July 2022 Tuesday Blogs: https://tdtemcerts.blogspot.com https://tdtemcerts.wordpress.com

2 2

← Newer
1
...
4
5
6
7
8
9
10
11
12
Older →