I have bought an external DVD driver but, after plugging (or booting with the unit already plugged) I see the unit listed in the resources of the computer but I cannot access it: If I try to access the driver via VLC, I get the error VLC is unable to open the MRL 'cdda:///dev/sr0'. The content of fstab is: $ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/nvme0n1p2 during installation UUID=341faa1b-4e49-49d7-85a4-e33acecb2212 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/nvme0n1p1 during installation UUID=24D6-7429 /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0 What is the right way to plug a DVD in Ubuntu 20.04? Is it a problem with the driver (I need to buy another brand more Linux-prone)? Or do I need to change the permission of the driver with some sudo commands? After I plug the DVD driver I get: $ ls -lt | less | grep sr0 lrwxrwxrwx 1 root root 3 May 27 21:15 cdrom -> sr0 lrwxrwxrwx 1 root root 3 May 27 21:15 cdrw -> sr0 lrwxrwxrwx 1 root root 3 May 27 21:15 dvd -> sr0 lrwxrwxrwx 1 root root 3 May 27 21:15 dvdrw -> sr0 brw-rw----+ 1 root cdrom 11, 0 May 27 21:15 sr0 Thank you

I'm trying to learn as as much as I can about about the interplay between syscalls, the VFS, device driver handling and ultimately, having the end device do some operation. I thought I would look at a fairly trivial example - creating a file - and try to understand the underlying process in as much detail as possible. I created a bit of C, to do little more than open a (non-existing) file for writing, compiled this (without optimization), and took a peek at it with strace when I ran it. In particular, I wanted to focus on the openat syscall, and why and how this call was ultimately able to not only create the file object / file description, but also actually do the writing to disk (for reference, EXT4 file system, SATA HDD). Broadly speaking, excluding some of the checks and ancilliary bits and pieces, my understanding of the process is as follows (and please correct me if I'm way off!): - ELF is mapped into memory - libc is mapped into memory - fopen is called - libc does its open - openat syscall is called, with the O_CREAT flag among others - Syscall number is put into RAX register - Syscall args (e.g. file path, etc.) are put into RDI register (and RSI, RDX, etc. as appropriate) - Syscall instruction issue, and CPU transition to ring 0 - System_call code pointed to by MSR_LSTAR register invoked - registers pushed to kernel stack - Function pointer from RAX called at offset into sys_call_table - asmlinkage wrapper for the actual openat syscall code is invoked And at that point my understanding is lacking, but ultimately, I know that: 1. The open call returns a file descriptor, which is unique to the process, and maintained globally within the kernel's file descriptor table 2. The FD maps to a file description file object 3. The file object is populated with, among other structures, inode structure, inode_operations, file_operations, etc. 4. The file operations table should map generic syscalls to the respective device drivers to handle the respective calls (such that, for example, when a write syscall is called, the respective driver write call is called instead for the device on which the file resides, e.g. a SCSI driver) 5. This mapping is based on the major/minor numbers for that file/device 6. Somewhere along the line, code is invoked which causes a instructions to be send to the device drive for the hard drive, which gets send to the disk controller, which causes a file to be written to the hard disk, though whether this is via interrupts or DMA, or some other method of I/O I'm not sure 7. Ultimately, the disk controller sends a message back to the kernel to say it's done, and the kernel returns control back to use space. I'm not too good at following the kernel source, though I've tried a little, but feel there's a lot I'm missing. My questions are as follows: I've found some functions which return, and destroy FDs in the kernel source, but can't find where the code is which actually populates the file object / file description for the file. A) On an open or openat syscall, when a new file is created, how is the file structure populated? Where does the data come from? Specifically, how are the file_operations and inode_operations, etc. for that file populated? how does the kernel know, when populating that structure, that the file operations for this particular file need to be that of the SCSI driver, for instance? B) Where in the process - and particularly with reference to the source - does the switch to the device driver happen? For example, if an ioctl or similar was called, I would expect to some reference to the instruction to be called for the respective device, and some memory address for the data to be passed on, but I can't find where that happens. From looking at the kernel source, all I can really find is code that assigns a new FD, but nothing that populates the file structure, no anything that calls the respective file operations to transfer control to a device driver. Apologies that this is a really long-winded description, but I'm really trying to learn as much as possible, and although I have a basic grasp of C, I really struggle to understand others' code. Hoping someone with greater knowledge than I can help clarify some of these things for me, as I seem to have hit a figurative brick wall. Any advice would be greatly appreciated. **Edit:** Hopefully the following points will clarify what technical detail I'm after. - The open or openat syscalls take a file path, and flags (with the latter also being passed an FD pointing to a directory) - When the O_CREAT flag is also passed, the file is 'created' if it doesn't exist - Based on the file path, the kernel is able to identify the device type this file should be - The device type is identified from the major/minor numbers ordinarily - for a file that already exists, these are stored in the inode structure for the file (as member i_rdev) and the stat structure for the file (as members st_dev for the device type of the file system on which the file resides, and st_rdev for the device type of the file itself) So really, my questions are: 1. When a file is created with either of the open syscalls, the respective inode and stat structure must also be created and populated - how do the open syscalls do this (when all they have to go on at this point is the file path, and flags? Do they look at the inode or stat structure of the parent directory, and copy the relevant structure members from this? 2. At which point (i.e. where in the source) does this happen? 3. It's my understanding that when these open syscalls are invoked, it needs to know the device type, in order for the VFS to know what device driver code to invoke. On creating a new file, where the device type has yet to be set in the file object structures, what happens? What code is called? 4. Is the sequence more like: user process tries to open new file -> open('/tmp/foo', O_CREAT) open -> look up structure for '/tmp', get its device type -> get unused FD -> populate inode/stat structure, including setting device type to that of parent -> based on device type, map file operations / inode operations to device driver code -> call device driver code for open syscall -> send appropriate instruction to disk controller to write new file to disk -> tidy up things, do checks, etc. -> return FD to user calling process?

What do I need to do to have read permissions on /dev/hidraw*? I'm seeing stuff about udev rules and saw this on the net, but the world of udev is like a foreign land to me, and if there's some sort of a simpler solution where I just add myself to a group that'd be dandy... (Ubuntu 13.10 Preview) Feel free to retag the question - I'm not too keen on what 'hidraw' exactly goes under. EDIT: H'okay, so, just some more information to clarify the issue: I literally stepped through code that called the POSIX open() method, and got the errno for insufficient permissions. Running cat on the file as a normal user results in an insufficient permissions error, while running under su results in a successful (albeit meaningless) cat operation. EDIT EDIT: At request, I'm providing the relevant code with POSIX call. It's from the HIDAPI library by Signal11 (function hid_open_path). I trust that this code is correct, as it has apparently been in use for quite some time now. I've added a comment located where the relevant errno reading took place in GDB. hid_device *dev = NULL; hid_init(); dev = new_hid_device(); if (kernel_version == 0) { struct utsname name; int major, minor, release; int ret; uname(&name); ret = sscanf(name.release, "%d.%d.%d", &major, &minor, &release); if (ret == 3) { kernel_version = major device_handle = open(path, O_RDWR); // errno at this location is 13: insufficient permissions /* If we have a good handle, return it. */ if (dev->device_handle > 0) { /* Get the report descriptor */ int res, desc_size = 0; struct hidraw_report_descriptor rpt_desc; memset(&rpt_desc, 0x0, sizeof(rpt_desc)); /* Get Report Descriptor Size */ res = ioctl(dev->device_handle, HIDIOCGRDESCSIZE, &desc_size); if (res device_handle, HIDIOCGRDESC, &rpt_desc); if (res uses_numbered_reports = uses_numbered_reports(rpt_desc.value, rpt_desc.size); } return dev; } else { /* Unable to open any devices. */ free(dev); return NULL; }

On my Linux Ubuntu I've a Linux bridge vnet0_6. You can check the mac address of each of the two interfaces attached to bridge's ports. root@eve-ng62:~# brctl show vnet0_6 bridge name bridge id STP enabled interfaces vnet0_6 8000.7afc42bc8d20 no vunl0_4_4 vunl0_6_5 root@eve-ng62:~# root@eve-ng62:~# brctl showmacs vnet0_6 port no mac addr is local? ageing timer 2 ba:41:1d:fc:61:3a yes 0.00 2 ba:41:1d:fc:61:3a yes 0.00 1 ce:8f:3f:0e:a7:cb yes 0.00 1 ce:8f:3f:0e:a7:cb yes 0.00 root@eve-ng62:~# My question is: do bridge's ports have their *own* mac addresses ? I'm not sure whether the concept of mac address actually applies to bridge's ports themselves or only to interfaces (even virtual ones) attached to them.

I have a laptop with its built-in keyboard broken (The shift-button sometimes gets stuck down). I exclusively use an external keyboard, but the internal keyboard interferes with it. (I can not unplug the device.) I can disable the keyboard with xinput, but it becomes enabled again (see https://unix.stackexchange.com/q/471114/4778) . I have identified the device (you need to install lsinput, with e.g. apt install input-utils): sudo lsinput /dev/input/event0 bustype : BUS_I8042 vendor : 0x1 product : 0x1 version : 43841 name : "AT Translated Set 2 keyboard" phys : "isa0060/serio0/input0" bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP How to I disable it?

I'm using Ubuntu 12.04. I need to send a command to a device that I have connected on a port of my PC. I can send the command by finding out what the Bus and Device number are. For example, lsusb will tell me that I have a device connected on Bus 007 and Device 003 "Bus 007 Device 003: ID 045e:00cb Google Inc." However, the device number will change if I reboot the device. "Bus 007 Device 004: ID 045e:00cb Google Inc." Is there a way to make sure that I can send the commands to that PC USB port? By associating the device number to that phyical USB port? Or is there other fixes and workarounds?

Can someone explain me the connection between /dev/ttyACM0 and the output of lsusb? I am following this instructions . It says "Update ttyACM0 to match your adapter location." I do not know what to do here. lsusb Bus 002 Device 002: ID 1058:25a3 Western Digital Technologies, Inc. Elements Desktop (WDBWLG) Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 0451:16a8 Texas Instruments, Inc. CC2531 ZigBee Bus 001 Device 002: ID 046d:c52b Logitech, Inc. Unifying Receiver Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub simon@simon-itx:~/Downloads/zigbee2mqtt$ usb-devices

On my laptop, only Dummy Output appears in Sound Preferences. This is Mint 20.3, but similarly, nothing is found when running on with an Endeavor or Fedora live-USB-stick. Headphones in the AUX do not work either. With Windows, audio works. Apparently the sound card is HDA Intel PCH (see aplay -l below). arecord --list-devices gives an empty result (below). See also arecord --list-pcms and /sbin/lsmod | grep snd below. How can I get this working?

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

arecord --list-devices


**** List of CAPTURE Hardware Devices ****

$ arecord --list-pcms
default
    Playback/recording through the PulseAudio sound server
surround21
    2.1 Surround output to Front and Subwoofer speakers
surround40
    4.0 Surround output to Front and Rear speakers
surround41
    4.1 Surround output to Front, Rear and Subwoofer speakers
surround50
    5.0 Surround output to Front, Center and Rear speakers
surround51
    5.1 Surround output to Front, Center, Rear and Subwoofer speakers
surround71
    7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
null
    Discard all samples (playback) or generate zero samples (capture)
samplerate
    Rate Converter Plugin Using Samplerate Library
speexrate
    Rate Converter Plugin Using Speex Resampler
jack
    JACK Audio Connection Kit
oss
    Open Sound System
pulse
    PulseAudio Sound Server
upmix
    Plugin for channel upmix (4,6,8)
vdownmix
    Plugin for channel downmix (stereo) with a simple spacialization
usbstream:CARD=PCH
    HDA Intel PCH
    USB Stream Output

$ /sbin/lsmod | grep snd
snd_sof_pci            20480  0
snd_sof_intel_hda_common    73728  1 snd_sof_pci
snd_soc_hdac_hda       24576  1 snd_sof_intel_hda_common
snd_sof_intel_hda      20480  1 snd_sof_intel_hda_common
snd_sof_intel_byt      20480  1 snd_sof_pci
snd_sof_intel_ipc      20480  1 snd_sof_intel_byt
snd_sof               106496  4 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_intel_byt,snd_sof_intel_ipc
snd_sof_xtensa_dsp     16384  1 snd_sof_pci
snd_hda_ext_core       32768  3 snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda
snd_soc_acpi_intel_match    32768  2 snd_sof_pci,snd_sof_intel_hda_common
snd_soc_acpi           16384  2 snd_sof_pci,snd_soc_acpi_intel_match
ledtrig_audio          16384  1 snd_sof
snd_soc_core          249856  3 snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hda
snd_compress           24576  1 snd_soc_core
ac97_bus               16384  1 snd_soc_core
snd_pcm_dmaengine      16384  1 snd_soc_core
snd_hda_codec_hdmi     61440  1
snd_hda_intel          53248  1
snd_intel_dspcfg       28672  3 snd_hda_intel,snd_sof_pci,snd_sof_intel_hda_common
snd_hda_codec         139264  3 snd_hda_codec_hdmi,snd_hda_intel,snd_soc_hdac_hda
snd_hda_core           90112  7 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_sof_intel_hda_common,snd_soc_hdac_hda,snd_sof_intel_hda
snd_hwdep              20480  1 snd_hda_codec
snd_pcm               106496  8 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_sof,snd_sof_intel_hda_common,snd_soc_core,snd_hda_core,snd_pcm_dmaengine
snd_seq_midi           20480  0
snd_seq_midi_event     16384  1 snd_seq_midi
snd_rawmidi            36864  1 snd_seq_midi
snd_seq                69632  2 snd_seq_midi,snd_seq_midi_event
snd_seq_device         16384  3 snd_seq,snd_seq_midi,snd_rawmidi
snd_timer              36864  2 snd_seq,snd_pcm
snd                    90112  13 snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_rawmidi
soundcore              16384  1 snd

On my Laptop the names of my graphical outputs change depending on what chip is activated in the BIOS. This leads to problems in some scripts where outputs such as VGA-0 or LVDS-0 are specified. So I want to rename the graphical outputs, similar to how you can specify persistent names for network devices with udev. But I can't find anything that would explain how or if this is even possible at all. In /sys I could find kernel names such as as: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DVI-D-1 /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-VGA-1 while xrandr reports the names as DVI1 and VGA1. So they have to be renamed somewhere(?) When I call udevadm info on one of those devices I get a lot of information but not the names used by xrandr and other X tools. So is it possible to create a udev rule to rename the outputs and if so how? Are the names even set by udev?

I can't seem to get this PICe card working and I can't find any info/drivers about it on the internet. All the SATA HDDs in my server are connected using this card which came with the system. It works instantly plug-and-play in Windows. But on Linux, nothing. lspci shows the card but no drives or /dev/sdX devices show up, and I don't see any messages/errors regarding it in dmesg, not sure what I should be looking for though. I'm using Ubuntu Desktop 20.04 btw. (And if you're curious why desktop on a server, it's a headless box but I installed the desktop so I can VNC in as well as SSH in) Here is the card. It says "Newer MAXPower RAID mini-SAS 6G PCIe 2.0" EDIT: Here's what lspci -v shows: 06:00.0 RAID bus controller: HighPoint Technologies, Inc. Device 1e10 (rev 03) Subsystem: HighPoint Technologies, Inc. Device 0000 Physical Slot: 3 Flags: fast devsel Memory at 90940000 (64-bit, non-prefetchable) [disabled] [size=128K] Memory at 90900000 (64-bit, non-prefetchable) [disabled] [size=256K] Expansion ROM at 90960000 [disabled] [size=64K] Capabilities: Power Management version 3 Capabilities: MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: Express Endpoint, MSI 00 Capabilities: Advanced Error Reporting Capabilities: Virtual Channel

I am a bit confused with behavior of Jetson TX2 when loading drivers for camera. Here is definition of IMX274 in device tree: i2c@3180000 { reg = ; dmas = ; interrupts = ; compatible = "nvidia,tegra186-i2c"; clock-names = "div-clk", "parent", "slow-clk"; reset-names = "i2c"; clock-frequency = ; scl-gpio = ; sda-gpio = ; clocks = ; resets = ; status = "okay"; #address-cells = ; phandle = ; #stream-id-cells = ; #size-cells = ; dma-names = "rx", "tx"; linux,phandle = ; imx274_a@1a { reg = ; mclk = "extperiph1"; devnode = "video0"; avdd-reg = "vana"; compatible = "nvidia,imx274"; clock-names = "extperiph1", "pllp_grtba"; reset-gpios = ; physical_h = "2.738"; physical_w = "3.674"; clocks = ; vana-supply = ; sensor_model = "imx274"; iovdd-reg = "vif"; delayed_gain = "true"; vif-supply = ; dvdd-reg = "vdig"; vdig-supply = ; mode0 { ... } ports { #address-cells = ; #size-cells = ; port@0 { reg = ; endpoint { bus-width = ; remote-endpoint = ; phandle = ; csi-port = ; linux,phandle = ; }; }; }; }; i2c2 is an alias for i2c@3180000 therefore I expect to see the device on bus 2. An sure I can see it on a bus with address 0x57. nvidia@tegra-ubuntu:~/kernel/kernel$ sudo i2cdetect -r -y 2 [sudo] password for nvidia: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- UU -- -- -- -- -- 20: -- -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- 57 -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Here comes the first question. **How does kernel identifies type of i2c device on a bus?** I thought that field reg is used, but 0x1a in device tree is clearly different from 0x57 on a bus. Secondly, as I can see module is compatible with the following drivers: compatible = "nvidia,imx274"; However device driver is different: nvidia@tegra-ubuntu:~/kernel/kernel$ sudo v4l2-ctl -D -d /dev/video0 Driver Info (not using libv4l2): Driver name : tegra-video Card type : vi-output, imx274 2-001a Bus info : platform:15700000.vi:0 Driver version: 4.4.38 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format **Therefore it seems for me that wrong driver is loaded for some reasons, it it true or I am just missing something?** However it is still possible to capture image with argus.

To startup vm called "sys-net" in Qubes on my laptop need to write "1" in file echo -n "1" > /sys/bus/pci/devices/0000\:04\:00.0/remove also 0000:04:00.0 and 0000:04:00.1 are conflicts and need to be removed first after every startup laptop. then network start and work fine. there is some input for information $ lspci | grep -i eth 04:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev12) $ find /sys -name *04:00.0 /sys/bus/pci/devices/0000:04:00.0 /sys/bus/pci/drivers/rtsx_pci/0000:04:00.0 /sys/devices/pci0000:00/0000:00:1d.3/0000:04:00.0 $ find /sys -name *04:00.1 /sys/bus/pci/devices/0000:04:00.1 /sys/bus/pci/drivers/pciback/0000:04:00.1 /sys/devices/pci0000:00/0000:001d.3/0000:04:00.1 How can I convert it to systemd script to run it at start-up? It works only temporarily. After reboot the network device is there again.

https://bugzilla.redhat.com/show_bug.cgi?id=1679010 seeing this log:

Failed to init entropy source hwrng

Does Intel or AMD CPU contain a hwrng device? or it need extra chip/card/device?

I'm currently learning about Linux device drivers and feel as if I have a fundamental misunderstanding on how devices are instantiated in Linux. Within a Linux module, I can call alloc_chrdev_region() to register devices with the kernel. Specifically, this function is int alloc_chrdev_region(dev_t *dev, unsigned int firstminor, unsigned int count, char *name); which generates a device number (major / minor) and accepts a device name. After successful execution, an entry is made in /proc/devices with the major number and device type name. However, there are no devices files generated in /dev. Instead I must make a mknod call to generate the device files. So my question: why? This seems unnecessary since I've already specified a device type name and number of devices to be registered with kernel. Why aren't device files automatically created?

I'm working on a project that aims to use a small (6-key keyboard) to control music played by mpd (and mpc) on a Raspberry Pi. Obviously I need to "capture" the keyboard inputs, and translate them into commands to mpd. I have no (zero) experience working with keyboards, but after some research and using [this Q&A as a starting point](https://unix.stackexchange.com/questions/428399/how-can-i-run-a-shell-script-on-input-device-event) I've now got a short working script that uses evtest to monitor the keyboard output. There is a statement on the [Debian website for the evtest package](https://packages.debian.org/bookworm/evtest) that I want to ask about: >evtest is now in maintenance mode and doesn't support all the features of the latest kernels; evemu-record from the evemu-tools package should be used instead. I've also tried the evemu-record command in my script; it seems to work very much the same as evtest. I have two questions: The first is whether or not the issues mentioned for evtest are a real concern given the following: * the target system is a headless Raspberry Pi ('bookworm', 64-bit) * the keyboard has only 6 keys, and is connected via USB I also have a question re this statement in man evtest: >If the --grab flag is given in capture mode, evtest keeps an EVIOCGRAB on the device. While this grab is active, other processes will not receive events from the kernel devices. Does this mean that if my script is started @reboot (cron) the output of 6-key keyboard will never go to any other process? If so, this seems like "a good thing" to me, and a potential advantage over evemu-record. The second question is an "opinion question" I guess, but I'd like to know if there are real "compelling advantages" to writing this keyboard monitor in C vs in bash as I've done?

everyone. I have a completely filled root filesystem, but I can't figure out what it is. sudo df -h / /dev/nvme0n1p2 49G 49G 0 100% / sudo du -h --max-depth=1 --exclude="media" --exclude="proc" --exclude="run" --exclude="home" / | sort -rh | head -10 25G / Help me figure it out. Thank you all for your answers, but I'll rephrase the question. We have an SSD In gparted, we see that the root partition is 50 GB in size and it is all used. But du shows that only 21 GB is occupied in /. Where (and what is it occupied by) did 29 GB go?

If possible, can you point to documentation or describe the kernel space memory layout? When a device driver instantiates a variable does that variable live in the kernel space or does it live in user space with special permissions?

I have a RHEL9 system with a NVIDIA L40S and Driver Version: 570.124.06 CUDA Version: 12.8. Installed as described here by (basically) running: # dnf config-manager --add-repo http://developer.download.nvidia.com/compute/cuda/repos/rhel9/$(uname -i)/cuda-rhel9.repo # dnf module install nvidia-driver:latest # nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml In order to allow non-root users access to the GPU via podman I changed the selinux type on the /dev/nvidia* device objects like so:

# semanage fcontext -a -t container_file_t '/dev/nvidia(.*)?'
# restorecon -rv /dev/nvidia*
Relabeled /dev/nvidia0 from system_u:object_r:xserver_misc_device_t:s0 to system_u:object_r:container_file_t:s0
Relabeled /dev/nvidia-caps from unconfined_u:object_r:device_t:s0 to unconfined_u:object_r:container_file_t:s0
Relabeled /dev/nvidia-caps/nvidia-cap2 from unconfined_u:object_r:xserver_misc_device_t:s0 to unconfined_u:object_r:container_file_t:s0
Relabeled /dev/nvidia-caps/nvidia-cap1 from unconfined_u:object_r:xserver_misc_device_t:s0 to unconfined_u:object_r:container_file_t:s0
Relabeled /dev/nvidiactl from system_u:object_r:xserver_misc_device_t:s0 to system_u:object_r:container_file_t:s0
Relabeled /dev/nvidia-uvm from unconfined_u:object_r:xserver_misc_device_t:s0 to unconfined_u:object_r:container_file_t:s0
Relabeled /dev/nvidia-uvm-tools from unconfined_u:object_r:xserver_misc_device_t:s0 to unconfined_u:object_r:container_file_t:s0

After which a non-root could run the following successfully: $ podman run --rm --device nvidia.com/gpu=all nvidia/cuda:12.8.1-base-ubi9 nvidia-smi Everything done and looking good I figured until dnf-automatic rebooted the machine. When the machine comes up after reboot all the device files are naturally re-created with the old selinux labels - forcing a root to re-run the restorecon to make the devices available to the user. To make things worse not all nvidia devices are created on boot, specifically the user runs into:

$ podman run --rm --device nvidia.com/gpu=all nvidia/cuda:12.8.1-base-ubi9 nvidia-smi
Error: setting up CDI devices: failed to inject devices: failed to stat CDI host device "/dev/nvidia-uvm": no such file or directory

If I run something like nvidia-smi the driver "wakes up" and creates the uvm-device. After which I can run restorecon. After which the user can do its things. Am I holding it wrong? Should I really need to create a oneshot-unit to massage these things into place? Or is there someway to teach selinux and the nvidia driver how to wake up in the desired state?

I wrote a Python script to manage keyboard events using [python-libevdev](https://python-libevdev.readthedocs.io/en/latest/) , although I don't believe the script itself is related to my problem. I configured udev and systemd to automatically start/stop the script when my external keyboard is added/removed. Here's my /etc/udev/rules.d/keyboard.rules file:

ACTION=="add", SYMLINK=="input/by-id/usb-Microsoft_Microsoft®_Nano_Transceiver_v2.1-event-kbd" TAG+="systemd"

And here's my ~/.config/systemd/user/keyboard.service file:

[Unit]
BindsTo=dev-input-by\x2did-usb\x2dMicrosoft_Microsoft\xc2\xae_Nano_Transceiver_v2.1\x2devent\x2dkbd.device
After=dev-input-by\x2did-usb\x2dMicrosoft_Microsoft\xc2\xae_Nano_Transceiver_v2.1\x2devent\x2dkbd.device

[Service]
ExecStart=/usr/bin/sudo /usr/local/bin/kbd.py /dev/input/by-id/usb-Microsoft_Microsoft®_Nano_Transceiver_v2.1-event-kbd

[Install]
# Allows service to start when external keyboard is connected
WantedBy=dev-input-by\x2did-usb\x2dMicrosoft_Microsoft\xc2\xae_Nano_Transceiver_v2.1\x2devent\x2dkbd.device
# Allows service to start on login if external keyboard is connected before computer boots
WantedBy=default.target

enabled via:

systemctl --user enable keyboard.service

This works perfectly. My problem is that now I want to disable the systemd service so I can test improvements to the Python script without interference, but I can't figure out how to fully disable the service. I initially ran:

systemctl --user disable keyboard.service

and confirmed that all of the keyboard.service symlinks under ~/.config/systemd/user/ got deleted. I've also run:

systemctl --user daemon-reload
sudo systemctl daemon-reload

and rebooted multiple times. I've run:

systemctl --user status keyboard.service
systemctl status keyboard.service

and confirmed the service is not found. After all of these steps, the kbd.py script is clearly still being run by systemd. I can see the process getting stopped/started in htop when I disconnect/reconnect the keyboard and I can tell by the keyboard's behavior that the script is still running. If I run pgrep -a -f kbd.py I see something like:

7169 /usr/bin/sudo /usr/local/bin/kbd.py /dev/input/by-id/usb-Microsoft_Microsoft®_Nano_Transceiver_v2.1-event-kbd
7184 /usr/bin/python3 -O /usr/local/bin/kbd.py /dev/input/by-id/usb-Microsoft_Microsoft®_Nano_Transceiver_v2.1-event-kbd

and if I run pstree -s -p 7184 I see:

systemd(1)───systemd(2345)───sudo(7169)───kbd.py(7184)

If I find process 2345 in htop, I see the expected Command:

/usr/lib/systemd/systemd --user

So, it appears that systemd is still managing my kbd.py script, although the service does not appear to exist anymore. I'm on Fedora Linux 41 (Workstation Edition). Running systemctl --version shows:

systemd 256 (256.11-1.fc41)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE

The last thing I see in journalctl --user around the time of my most recent tests is just some gnome-shell JavaScript error, so no help there. I've reached the limit of my systemd knowledge. A few questions: 1. Am I missing some command(s) for fully disabling the service? 1. Is there a way to further interrogate systemd to discover why it's still starting the script? 1. Could this have something to do with the fact that this is a --user service that runs a script as root via sudo? 1. Is there some other bug in my keyboard.service file? Edit: Another (possibly unrelated) observation is that whenever I re-create the service file and run systemctl --user enable keyboard.service, I see a yellow warning like:

Unit /path/to/keyboard.service is added as a dependency to a non-existent unit dev-input-by\x2did-usb\x2dMicrosoft_Microsoft\xc2\xae_Nano_Transceiver_v2.1\x2devent\x2dkbd.device

even though I see the expected symlink being created at:

~/.config/systemd/user/dev-input-by\\x2did-usb\\x2dMicrosoft_Microsoft\\xc2\\xae_Nano_Transceiver_v2.1\\x2devent\\x2dkbd.device.wants/keyboard.service

Also, if I run:

systemctl status dev-input-by\x2did-usb\x2dMicrosoft_Microsoft\xc2\xae_Nano_Transceiver_v2.1\x2devent\x2dkbd.device

I see:

Loaded: loaded
Active: inactive (dead)

Even while the keyboard is connected and working. I'm not sure if this is expected behavior, or if it's at all related to the systemd service issue.

This works

head -c 10 /dev/zero | sed 's/\x0/x/g'

and generates xxxxxxxxxx as expected. Then I tried this:

sed 's/\x0/x/g' /dev/zero | head -c 10

which seems to just hang. Then I thought, oh, sure, there's no newline in here and sed can't even finish take a line in the pattern space, so it hangs. Is that the reason why the command above hangs? But wait, there's a -u option: > -u, --unbuffered > > load minimal amounts of data from the input files and flush the output buffers more often which made me think it would be the solution, but it also seems to block:

sed -u 's/\x0/x/g' /dev/zero | head -c 10

Does this mean that it is just not possible to operate with sed on an infinite stream?