In the beginning (way back in Unix), the way that programs found out about the running processes on the system was via directly reading process structures from the kernel memory (opening /dev/mem, and interpreting the raw data directly). This is how the very first 'ps' commands worked. Over time, some information was made available via system calls.
The files in /dev are actual devices files which UDEV creates at run time. The directory /sys/class is exported by the kernel at run time, exposing the hierarchy of the hardware through sysfs.
From the libudev and Sysfs Tutorial
On Unix and Unix-like systems, hardware devices are accessed through special files (also called device files or nodes) ...
The sysfs file system, typically mounted on /sys, just like the /proc file system, isn’t a typical file system, it’s a so called pseudo file system. It’s actually populated by the kernel and you can’t delete files directly.
So, if the ASUS laptop support isn’t appropriate for you, then you have to ask the kernel to remove it. To do so, remove the ...
The /sys filesystem (sysfs) contains files that provide information about devices: whether it's powered on, the vendor name and model, what bus the device is plugged into, etc. It's of interest to applications that manage devices.
The /dev filesystem contains files that allow programs to access the devices themselves: write data to a serial port, read a ...
/sys is sysfs, an entirely virtual view into kernel structures in memory that reflects the current system kernel and hardware configuration, and does not consume any real disk space. New files and directories cannot be written to it in the normal fashion.
Applying disk space monitoring to it does not produce useful information and is a waste of effort....
This is essentially a matter of checking a whole bag of corner cases.
A drive can appear in /proc/mounts
A drive can be used as swap (use /proc/swaps)
A drive can be part of an active LVM pv (use pvdisplay)
A drive can be part of a dm-mapper RAID group (use /proc/mdstat)
A drive can be directly accessed by an application (e.g. Oracle supports writing ...
Rsync has code which specifically checks if a file is truncated during read and gives this error — ENODATA. I don't know why the files in /sys have this behavior, but since they're not real files, I guess it's not too surprising. There doesn't seem to be a way to tell rsync to skip this particular check.
I think you're probably better off not rsyncing /sys ...
First off /sys is a pseudo file system. If you look at /proc/filesystems you will find a list of registered file systems where quite a few has nodev
in front. This indicates they are pseudo filesystems. This means they exists
on a running kernel as a RAM-based filesystem. Further they do not require a
$ cat /proc/filesystems
It might help to up /proc/sys/vm/page-cluster (default: 3).
From the kernel documentation (sysctl/vm.txt):
page-cluster controls the number of pages up to which consecutive
pages are read in from swap in a single attempt. This is the swap
counterpart to page cache readahead. The mentioned consecutivity is
not in terms of virtual/...
procfs allows arbitrary file_operations, sysfs is more restricted
procfs entries receive a file_operations struct, which contains function pointers that determine what happens to every file-based system call, e.g. open, read, mmap, etc., and you can take arbitrary actions from those.
How does /proc/* work? | Super User
The /sys directory is generally where the sysfs filestystem is mounted, which contains information about devices and other kernel information.
The files in /sys/block contain information about block devices on your system. Your local system has a block device named sda, so /sys/block/sda exists. Your Amazon instance has a device named xvda, so /sys/block/...
/etc/resolv.conf is copied in order not to lose the DNSs.
/lib/modules is copied because because it may be necessary to use some hardware component that need not be present at the time of setting up the chroot. You must remember that the original question you refer to in your OP concerns the replacement of a NAS OS with Arch Linux. You will thus need ...
ioctl tends to go hand-in-hand with a /dev entry; your typical code would do
This is perfectly standard Unix behaviour. Inside the kernel driver you can put access controls (eg only root can do some things, or require a specific capability for more fine grained access) which makes it pretty flexible and ...
This information can be retrieved from the iSerial entry of the verbose output of the lsusb. Easiest is to pass the output to the the less viewer and search manually with /, or for example with grep:
$ lsusb -v 2>/dev/null | grep '^Bus\|iSerial'
Bus 001 Device 029: ID 12d1:1506 Huawei Technologies Co., Ltd. Modem/Networkcard
The generic way to do this for any kind of file systems is bind mount.
This example is using /tmp. To do that on /sys you may replace /tmp/sysall by /sys:
mkdir -p /tmp/mychroot/sys/class/gpio
mount -t sysfs sysfs /tmp/sysall/
mount --bind /tmp/sysall/class/gpio /tmp/mychroot/sys/class/gpio
It's the device link in class directories that you aren't supposed to use. The idea is that /sys/class/net/eth0 is a symbolic link to somewhere under /sys/devices, and the device link merely links to a (grand-)*parent directory; instead of using the device link, you're supposed to walk back to a parent directory if needed.
Accessing files in /sys/class/net/...
# strace hdparm -i /dev/sda
ioctl(3, HDIO_GET_IDENTITY, 0x7fffa930c320) = 0
brk(0) = 0x1c42000
brk(0x1c63000) = 0x1c63000
write(1, "\n", 1
) = 1
write(1, " Model=…
So hdparm gets its information from the HDIO_GET_IDENTITY ioctl, not from sysfs. That doesn't mean that the ...
It is not related to any bootloader at all.
When a driver uses the kernel's common firmware loading infrastructure to load a firmware file, the kernel can either load the file directly from the standard /lib/firmware directory tree, or it can optionally start an user-space process to handle the firmware load.
This user-space process used to be part of the ...
/etc/resolv.conf - you need this file for resolving DNS requests. It isn't necessary under some circumstances:
a DHCP client is available in the chroot, it does get executed and the DHCP server returns the appropriate information (which usually is the case).
you are not interested in networking (or more precisely making DNS queries from usual applications ...
/proc/devices - List of device drivers configured into the currently running kernel (block and character)
/dev - This directory contains the special device files for all the devices
Difference between procfs vs sysfs
Each loaded module has an entry in /sys/module. But there are also kernel components with an entry in /sys/module that are not loaded as modules. Each kernel component¹ that can be built as a module has an entry in /sys/module, whether it is compiled and loaded as a module or compiled as part of the main kernel image.
lsmod gets the list of loaded modules ...
the kernel use sysfs to export device nodes to user space to be used by udev
No. Sysfs does not contain device nodes. Sysfs mainly contains files that provide information about devices, as well as some files that allow processes to control how devices operate. But for the most part devices cannot be used through what sysfs provides.
Let's take a hard disk, ...
I had the same problem, and I found that you have to set $LIMIT to 0 to remove that limit:
echo "$MAJOR:$MINOR 0" > blkio.throttle.write_bps_device
This removes the entry from the cgroup. If you then cat blkio.throttle.write_bps_device, you will not see the entry any more.
I have not played with the GPIO pins this way but based on lgeorgets second comment and this article, you must first set the direction of the pin to "out". The direction node is owned by root, so:
sudo sh -c 'echo out > /sys/class/gpio/gpio18/direction'
sh -c is needed here to execute that command in a root subshell. This is because sudo echo out > ...
I don't believe tmpfiles.d is the proper way to go here. You really should do the udev rules. Look:
udevadm info -a -p /sys/class/scsi_host/host*
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, ...
You may try adding the programs you most care about to a cgroup and tuning swappiness so that the next time the application runs the programs you add are less likely to be candidates for swapping.
Some of their pages will likely still be swapped out but it may get around your performance problems. A large part of it is probably just the "stop and start" ...
You need to add mount --make-rslave /mnt/"$i" after your first mount command, to set the correct propagation flags for those mount points.
They protect the host from changes made inside the chroot environment, and help prevent blocking situations like yours.
I dug around a bit, and the reason behind your "LCD cooler" turned out to be incredibly interesting, in my opinion:
First off all, apparently LCD devices being listed as coolers under acpi are a thing, and not just a strange feature of your laptop - there are some more examples of those floating around online. If you do acpi -c yourself, you can list your ...