How do tracefs and debugfs differ? It looks like both can trace functions, system calls, etc. When to go for debugfs and when should we should use tracefs?
You should use /sys/kernel/tracing. Both /sys/kernel/tracing and /sys/kernel/debug/tracing are tracefs mounts, so in theory they are equivalent. However, the second one depends on debugfs being available (since it is created inside the debugfs mount).
Before tracefs was introduced, tracing was only available through debugfs, so the entry in debugfs (/sys/kernel/debug/tracing) was kept for backward compatibility with old applications. Now tracing does not depend on debugfs anymore and tracefs has its own separate mount point (/sys/kernel/tracing).
See the relevant patch:
There has been complaints that tracing is tied too much to debugfs,
as there are systems that would like to perform tracing, but do
not mount debugfs for security reasons. That is because any subsystem
may use debugfs for debugging, and these interfaces are not always
tested for security.
[...]
To maintain backward compatibility with older tools that expect that the tracing directory is mounted with debugfs, the tracing directory
is still created under debugfs and tracefs is automatically mounted there.
And indeed:
$ mount -t tracefs
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/debug/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
Related
I'm getting started with imx6 processors and the procedure involved to bring up the board is to flash u-boot kernel dtb and rootfs which is taken care of by mfg tools provided by nxp.
For creating a rootfs partition the command run is
mkfs.ext3 -F -E nodiscard /dev/mmcblk1p2
and for untaring the rootfs into this partition it is.
pipe tar -jxv -C /mnt/mmcblk1p2
I'd like to know the working of this, which kernel driver is being called for executing these commands?
My kernel version is 4.9.88.
I did find a few driver files related to mmc in the path
/drivers/mmc/core
but there is nothing related to filesystem reading or writing here.
Can anyone explain which driver files are used to create filesystems?
Creating the filesystem is done by the userspace program mke2fs (of which mkfs.ext3 is an alias) which is part of the e2fsprogs package. The kernel and drivers have no way of creating filesystems. Therefore, only the block driver for accessing the MMC device is involved, but no file system driver.
I'm using the buildroot version-20011.02 for kernel, toolchain and filesystem.My customized board ARMV7 cortexA9 SoC.Kernel version is 3.18.41.
Build the kernel(uImage), Buildroot toolchain, rootfs.tar.gz.
Enable the filesystem tyep ext4 in buildroot and also in kernel.
Extracting this rootfs.tar.gz to /export/users/buildroot/.
exporting this directory by using
exportfs -a, exportfs -rv and restart the nfs server.It seems everything is fine on nfs server side.
Here I'm sharing the "make menuconfig" system configuration -->
Init system (BusyBox) --->
Even I tried with Init system (systemV) --->
with bootargs as bootargs console=ttyAM0,115200n8 root=/dev/nfs rw rootwait ip=dhcp nfsroot=192.168.1.40:/export/users/buildroot,tcp,v3 init=/sbin/init
Every time I'm getting below log:
VFS: mounted fs via nfs
devtmpfs is mounted.
Kernel panic - not syncing:Attempted to kill init, exit code=0x000000b
Please help me out how to resolve this issue.
This may help you.
As you said, there is a log like below.
Kernel panic - not syncing:Attempted to kill init, exit code=0x000000b
This means init(busybox) is exited and the exit code is 0xb.
So kernel goes into panic.
Maybe this is caused by a network problem. But we cannot conclude this is due to network or not, for now.
You said, you saw crashing, without NFS.
I think resolving that crash maybe better way to solve this situation.
Please share crash log without NFS configuration. If you share log, I will check it.
I'm running Docker for Windows (similar effect described below is observable on MacOSX)
I have a Docker Container in which a program tries to access a squashfs image. To access squashfs the kernel has to be either complied with loopdevice support statically or load the relevant kernel module.
When I try to mount the image or setup the loop device the kernel that's shared between docker containers cannot find the loopdevice module.
I could possibly use unsquashfs tool but the squashfs image is used for a reason: squashfs has a very decent property: it allows unlimited number of files and inodes - if I try to to unpack the image I quickly hit the inode limit of the images.
Is Moby Linux kernel which is shipped with docker a statically compiled kernel? What volume to mount to have access to its /lib/modules? lsmod run in a privileged container lists no loaded modules. Trying to modprobe loop yields the following error message:
root#6e1b23cc65e5:/# modprobe loop
modprobe: ERROR: ../libkmod/libkmod.c:556 kmod_search_moddep() could not open moddep file '/lib/modules/4.9.8-moby/modules.dep.bin'
I have an Amazon EC2 instance. I booted up a volume and attached it to /dev/sdj. I edited my fstab file to have the line
/dev/sdj /home/ec2-user/mydirectory xfs noatime 0 0
Then I mounted it (sudo mount /home/ec2-user/mydirectory)
However, running the "mount" command says the following:
/dev/xvdj on /home/ec2-user/mydirectory type xfs (rw,noatime)
What? Why is it /dev/xvdj instead of /dev/sdj?
The devices are named /dev/xvdX rather than sdX in 11.04. This was a kernel change. The kernel name for xen block devices is 'xvd'. Previously Ubuntu carried a patch to rename those devices as sdX. That patch became problematic.
https://askubuntu.com/a/47909
i've installed krusader via macports but i'm unable to run krusader.
w-4jesc:web_cms_dms w-4jesc$ /Applications/MacPorts/KDE4/krusader.app/Contents/MacOS/krusader
KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work
krusader(97879)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes.
krusader(97879)/KSharedDataCache: Unable to find an appropriate lock to guard the shared cache. This *should* be essentially impossible. :(
krusader(97879)/KSharedDataCache: Unable to perform initial setup, this system probably does not really support process-shared pthreads or semaphores, even though it claims otherwise.
krusader(97879)/KSharedDataCache: Unable to unmap shared memory segment 0x1142d2000
Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
krusader(97879)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
KCrash: Application 'krusader' crashing...
KCrash: Attempting to start /opt/local/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi from kdeinit
sock_file=/Users/w-4jesc/Library/Preferences/KDE/socket-w-4jesc.local/kdeinit4__tmp_launch-URcTjs_org.x_0
Warning: connect() failed: : No such file or directory
KCrash: Attempting to start /opt/local/lib/kde4/libexec/drkonqi.app/Contents/MacOS/drkonqi directly
QProcess: Destroyed while process is still running.
drkonqi(97882)/KSharedDataCache ensureFileAllocated: This system misses support for posix_fallocate() -- ensure this partition has room for at least 10547296 bytes.
drkonqi(97882)/KSharedDataCache: Unable to find an appropriate lock to guard the shared cache. This *should* be essentially impossible. :(
drkonqi(97882)/KSharedDataCache: Unable to perform initial setup, this system probably does not really support process-shared pthreads or semaphores, even though it claims otherwise.
drkonqi(97882)/KSharedDataCache: Unable to unmap shared memory segment 0x1145ea000
Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
drkonqi(97882)/kdeui (kdelibs): Session bus not found
To circumvent this problem try the following command (with Linux and bash)
export $(dbus-launch)
dbus is already loaded:
sudo launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
org.freedesktop.dbus-session: Already loaded
has every one a idea?
sudo launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
MacPorts installer specifically says to start dbus without sudo:
# Don't forget that dbus needs to be started as the local
# user (not with sudo) before any KDE programs will launch
# To start it run the following command:
# launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist