I'm trying to configure Suspend/Hibernate with my laptop and I issued some troubles.
I noticed the following troubles:
Suspend :
- Switching the lid off of my laptop : When I switch the lid on of the laptop, nothing happens. I must push down the power button to force the shutdown and then switch on the laptop.
- Typing systemctl suspend : same as previously.
Hibernate :
- Typing systemctl hibernate : the laptop seems to shutdown
I read those following links for helping me :
Hibernate with swap file
Suspend and hibernate
My system :
4.13.0-38-generic #43-Ubuntu SMP Wed Mar 14 15:20:44 UTC 2018 x86_64 GNU/Linux
My swap :
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=403661c1-c7b4-47a8-9493-c5c0262ce14e / ext4 errors=remount-ro 0 1
UUID=BF40-CD4F /boot/efi vfat umask=0077 0 1
/swapfile none swap sw 0 0
/swap swap swap defaults 0 0
What I've done :
Create swap file
$ fallocate -l 8g /swap
$ mkswap /swap
Add swappiness
sysctl -w vm.swappiness=1
$ cat /etc/sysctl.conf | grep swappiness
vm.swappiness=1
$ swapon /swap
Configure grub
$ cat /etc/default/grub | grep -i grub_cmdline_linux_default
GRUB_CMDLINE_LINUX_DEFAULT="resume=/swap resume_offset=60354560 quiet splash"
$ sudo filefrag -v /swap | head -n4
Filesystem type is: ef53
File size of /swap is 8589934592 (2097152 blocks of 4096 bytes)
ext: logical_offset: physical_offset: length: expected: flags:
0: 0.. 0: 60354560.. 60354560: 1:
According to previous links I could configure /etc/mkinitcpio.conf but there is no file like this in my system.
So, I don't really know how to configure my initramfs.
Here is my configuration from /sys/power :
$ cat /sys/power/disk
[platform] shutdown reboot suspend test_resume
$ cat /sys/power/mem_sleep
s2idle [deep]
$ cat /sys/power/image_size
3261943808
$ cat /sys/power/resume
0:0
Could you give me some hints to make a step forward. Thanks you.
Related
I'm trying to configure and enable ftrace on my ubuntu machine but its doesn't work. I also tried the instructions from the link here. I'm sure I'm missing something minor but I can't tell what.
Configuration:
$ cat /boot/config-5.15.0-56-generic | grep CONFIG_FUNCTION_TRACER
CONFIG_FUNCTION_TRACER=y
$ cat /boot/config-5.15.0-56-generic | grep CONFIG_FUNCTION_GRAPH_TRACER
CONFIG_FUNCTION_GRAPH_TRACER=y
$ cat /boot/config-5.15.0-56-generic | grep CONFIG_STACK_TRACER
CONFIG_STACK_TRACER=y
$ cat /boot/config-5.15.0-56-generic | grep CONFIG_DYNAMIC_FTRACE
CONFIG_DYNAMIC_FTRACE=y
$ uname -a
Linux <redacted> 5.15.0-56-generic #62-Ubuntu SMP Tue Nov 22 19:54:14 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Enable tracing (with root user)
$ echo function > /sys/kernel/debug/tracing/current_trace
$ echo do_sys_open > /sys/kernel/debug/tracing/set_ftrace_filter
$ echo 1 > tracing_on
debugfs is already mounted:
$ mount
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
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)
After enabling the tracing I was expecting to see the traces in /sys/kernel/debug/tracing/trace or /sys/kernel/debug/tracing/trace_pipe files but I didn't see any traces.
Update: Instructions to generate the traces are working as expected. I was able to generate the traces successfully for do_sys_openat2 but with do_sys_open I don't see any traces.
I've also posted this question on Super User, here: https://superuser.com/questions/1425657/identical-scripts-same-permissions-one-hangs-one-doesnt-how-why. Please answer on the site you believe the question is most appropriate for. This will help me learn which site I should use. Thank you.
I always forget the name of the inxi command so some time ago I created a bash script called sysinfo- (note the '-' at the end to distinguish my script from the linux command sysinfo.)
$ cat ~/scripts/sysinfo-
#!/bin/bash
# DESCRIPTION
#
# Display system info at the command promp
#
# Main Program
echo -e "#############\n# inxi -b #\n#############\n"
/usr/bin/inxi -b
echo -e "############"
This script stopped working when I upgraded my system and inxi was upgraded to version 3.0.27
The script hangs when it reached the inxi command and must be killed with CTRL+C
The developer of inxi advised me to upgrade it to version 3.0.33 which I did. Unfortunately upgrading has not changed the results when running the original script. HOWEVER, after some testing I have discovered something I can't explain: An exact copy of my script runs successfully when the original does not!?
jesse#Limbo ~ $ ~/scripts/sysinfo-
#############
# inxi -b #
#############
^C
jesse#Limbo ~ $ cat ~/scripts/sysinfo- > /tmp/inxi.test
jesse#Limbo ~ $ chmod +x /tmp/inxi.test
jesse#Limbo ~ $ /tmp/inxi.test
#############
# inxi -b #
#############
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 3879 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.32 TiB (57.7%)
Info: Processes: 316 Uptime: 56m Memory: 31.34 GiB used: 4.80 GiB (15.3%) Shell: inxi.test inxi: 3.0.33
############
jesse#Limbo ~ $ diff ~/scripts/sysinfo- /tmp/inxi.test
jesse#Limbo ~ $ ls -l ~/scripts/sysinfo- /tmp/inxi.test
-rwxr-x--- 1 jesse jesse 187 Apr 15 18:46 /home/jesse/scripts/sysinfo-
-rwxr-x--- 1 jesse jesse 187 Apr 15 19:09 /tmp/inxi.test
jesse#Limbo ~ $ md5sum ~/scripts/sysinfo- /tmp/inxi.test
a1356223d7bacb6d5b6d74cf44d733f2 /home/jesse/scripts/sysinfo-
a1356223d7bacb6d5b6d74cf44d733f2 /tmp/inxi.test
How is this possible?
If it was some sort of corruption of the original file wouldn't diff pick that up? How would I check this?
Is it possible for there to have been some sort of policy file created automatically, because I haven't made one, that prevents inxi from running from within a script in ~/scripts??
BIGO!!
jesse#Limbo ~ $ mv /tmp/inxi.test ~/scripts/
jesse#Limbo ~ $ ~/scripts/inxi.test
#############
# inxi -b #
#############
^C
Might this be an apparmor policy perhaps?
jesse#Limbo ~ $ apparmor_status | grep inxi
yields no results.
I tried placing env in both ~/scripts/sysinfo- and /tmp/inxi.test
#!/bin/bash
# DESCRIPTION
#
# Display system info at the command promp
#
env
# Main Program
echo -e "#############\n# inxi -b #\n#############\n"
/usr/bin/inxi -b
echo -e "############"
but the output of env from both scripts was identical.
jesse#Limbo ~ $ diff ~/scripts/sysinfo- /tmp/inxi.test
jesse#Limbo ~ $ ~/scripts/sysinfo- > /tmp/sysinfo.output
^C
jesse#Limbo ~ $ /tmp/inxi.test > /tmp/inxi.test.output
jesse#Limbo ~ $ diff /tmp/sysinfo.output /tmp/inxi.test.output
61a62,75
> System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
> Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
> Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
> date: 02/22/2014
> CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 1355 MHz min/max: 800/4000 MHz
> Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
> Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
> resolution: 1920x1080~60Hz, 1280x1024~60Hz
> OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
> Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
> Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
> Drives: Local Storage: total: 14.44 TiB used: 8.32 TiB (57.7%)
> Info: Processes: 315 Uptime: 1h 40m Memory: 31.34 GiB used: 4.97 GiB (15.9%) Shell: inxi.test inxi: 3.0.33
> ############
As you can see the issue is not a problem running bash scripts from ~/scripts but only with running inxi from a script in ~/scripts
~/scripts happens to be a bind mounted directory on my system. Perhaps that is the problem?
BINGO!!
jesse#Limbo ~ $ mv ~/scripts/sysinfo- ~/
jesse#Limbo ~ $ ~/sysinfo-
#############
# inxi -b #
#############
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 900 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.33 TiB (57.7%)
Info: Processes: 322 Uptime: 1h 52m Memory: 31.34 GiB used: 5.36 GiB (17.1%) Shell: sysinfo- inxi: 3.0.33
############
But hang on...
jesse#Limbo ~ $ mv ~/sysinfo- ~/scripts/
jesse#Limbo ~ $ cp ~/scripts/sysinfo- ~/
jesse#Limbo ~ $ chmod +x ~/sysinfo-
jesse#Limbo ~ $ ~/sysinfo-
#############
# inxi -b #
#############
^C
HUH ????
I moved the script back to the bind mounted ~/scripts directory, then copied (rather than moved) it to ~/, made the new file executable, and... inxi hangs!
Surely this behavior must be coming from a policy somewhere that is able to tell the difference between a file moved and a file copied. A program run from within a bash script rather than from the command line. What else besides apparmor could be capable of doing this??
jesse#Limbo ~ $ cd ~/scripts/
jesse#Limbo ~/scripts $ inxi -b
System: Host: Limbo Kernel: 4.15.0-47-generic x86_64 bits: 64 Desktop: Cinnamon 4.0.10 Distro: Linux Mint 19 Tara
Machine: Type: Desktop System: MSI product: MS-7823 v: 1.0 serial: <root required>
Mobo: MSI model: CSM-H87M-G43 (MS-7823) v: 1.0 serial: <root required> BIOS: American Megatrends v: 1.6
date: 02/22/2014
CPU: Quad Core: Intel Core i7-4790 type: MT MCP speed: 1500 MHz min/max: 800/4000 MHz
Graphics: Device-1: NVIDIA GM107GL [Quadro K2200] driver: nvidia v: 390.116
Display: x11 server: X.Org 1.19.6 driver: nvidia unloaded: fbdev,modesetting,nouveau,vesa
resolution: 1920x1080~60Hz, 1280x1024~60Hz
OpenGL: renderer: Quadro K2200/PCIe/SSE2 v: 4.6.0 NVIDIA 390.116
Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169
Drives: Local Storage: total: 14.44 TiB used: 8.33 TiB (57.7%)
Info: Processes: 315 Uptime: 2h 01m Memory: 31.34 GiB used: 4.96 GiB (15.8%) Shell: bash inxi: 3.0.33
I can't see how the directory permissions could be having any effect
jesse#Limbo ~/scripts $ ls -ld /tmp/ ~/scripts/ ~/
drwxr-x--- 194 jesse jesse 20480 Apr 15 20:06 /home/jesse/
drwxrwx--- 18 jesse jesse 12288 Apr 15 20:06 /home/jesse/scripts/
drwxrwxrwt 20 root root 24576 Apr 15 20:32 /tmp/
Has anyone discovered the dmidecode, lshw, lspci, lsusb, lsblk, or blkid utilities attempting to call back the parent_script? No. For that matter any UNIX or Linux utility doing a call back to the parent_script. No. Surprise, surprise, surprise, the newer inxi version does.
The inxi developer believes it is perfectly normal to do a call back on the parent_script without any intimate knowledge of the parent_script. Common sense would be to never do a call back on the parent_script unless you have working knowledge of that script and how it will behave. You are just asking for a vicious recursive loop. If the vicious loop is left running long enough it could fill up the Linux proc table or exhausted all available memory. And the inxi developer has made a fundamental change to inxi using very bad assumptions and created this scenario.
The previous 2.x version of inxi never performed a call back on the parent_script. I can imagine many users or system admins have been using the inxi utility in a monthly script to help document their server(s). And, with the inxi 2.x it was properly working for them.
The 3.x version of the inxi utility changed the foundational behavior. Now, inxi will perform a call back to the parent_script --version. The inxi developer assumes the parent_script will respond in kind to the --version argument. Why would anyone expect the --version call back when the 2.x version of inxi fundamental behavior did not do this? This can be very nasty for a cronjob script.
The 3.x version has a very fundamental change that will catch many users off guard with a vicious recursive loop. I attempted to get the inxi developer to explain why he would change an existing foundational behavior, and what useful purpose does the parent_script --version provide. Good luck getting an answer.
How to reproduce the problem
In my example the /home/temp/bin directory resides in my PATH.
Place this simple "dltest" script in your one of your PATH directories, and it will reproduce the problem:
# cat dltest
#!/bin/bash
# Open another terminal and use ps -ft /dev/pts/? to view the spawned process.
echo -e "\nUsing `tty`.\nSleeping yawn. Taking five seconds...\n" ; sleep 5
echo -e "\nStarting inxi -Ixxx\n"
# for a test use a very basic inxi.
/usr/bin/inxi -Ixxx
$ pwd
/home/temp/bin
$
$ ./dltest
Using /dev/pts/0.
Sleeping yawn. Taking five seconds...
Starting inxi_3.0.32
Concurrently using another terminal:
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13068 1820 0 14:28 pts/0 00:00:00 /bin/bash ./dltest
temp 13070 13068 0 14:28 pts/0 00:00:00 sleep 5
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13068 1820 0 14:28 pts/0 00:00:00 /bin/bash ./dltest
temp 13072 13068 18 14:29 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi
temp 13081 13072 0 14:29 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13082 13081 0 14:29 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13084 13082 0 14:29 pts/0 00:00:00 sleep 5
# The longer it runs the deeper it will get.
$ ps -ft pts/0
UID PID PPID C STIME TTY TIME CMD
temp 1820 1816 0 11:02 pts/0 00:00:00 bash
temp 13622 1820 0 14:48 pts/0 00:00:00 /bin/bash ./dltest
temp 13625 13622 1 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13634 13625 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13635 13634 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13638 13635 1 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13647 13638 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13648 13647 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13652 13648 2 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13661 13652 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13662 13661 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13665 13662 20 14:48 pts/0 00:00:00 /usr/bin/perl /usr/bin/inxi -tty -Ixxx
temp 13674 13665 0 14:48 pts/0 00:00:00 sh -c /home/temp/bin/dltest --version 2>/dev/null
temp 13675 13674 0 14:48 pts/0 00:00:00 /bin/bash /home/temp/bin/dltest --version
temp 13677 13675 0 14:48 pts/0 00:00:00 sleep 5
temp#lm19:~$
To prevent this vicious loop you can add this workaround at the top of your script.
if [[ "${1}" == "--version" ]] ; then
# work around for inxi_3.0.32 parent --version anomaly
exit 1
fi
You can create a new script that first creates a temporary copy of the original script and then runs the temporary script for you.
So you could name the script ~/scripts/sysinfo2 and it would look like this:
#!/bin/bash
cat $HOME/scripts/sysinfo- > /tmp/inxi.test
chmod +x /tmp/inxi.test
/tmp/inxi.test
Don't forget to make it executable: chmod +x ~/scripts/sysinfo2 and then you can run
~/scripts/sysinfo2
and it should execute without hanging up.
I have already seen Cannot enable kernel dynamic debugging on linux ; https://www.kernel.org/doc/html/v4.11/admin-guide/dynamic-debug-howto.html .
I have rebuilt the Raspbian 9 kernel with CONFIG_DYNAMIC_DEBUG, and booted into it; the file /sys/kernel/debug/dynamic_debug/control and is populated with 2k+ dynamic debug rule statements:
pi#raspberrypi:~ $ sudo ls -la /sys/kernel/debug/dynamic_debug/control
-rw-r--r-- 1 root root 0 Jan 1 1970 /sys/kernel/debug/dynamic_debug/control
pi#raspberrypi:~ $ sudo cat /sys/kernel/debug/dynamic_debug/control | wc -l
2358
pi#raspberrypi:~ $ sudo grep 'snd_device' /sys/kernel/debug/dynamic_debug/control
sound/core/device.c:132 [snd]snd_device_disconnect =_ "device disconnect %p (from %pS), not found\012"
sound/core/device.c:156 [snd]snd_device_free =_ "device free %p (from %pS), not found\012"
Ok, so I want to trace the is_connected_output_ep function, which is in sound/soc/soc-dapm.c. So I do this:
pi#raspberrypi:~ $ sudo bash -c "echo -n 'func is_connected_output_ep +p' > /sys/kernel/debug/dynamic_debug/control"
pi#raspberrypi:~ $ sudo cat /sys/kernel/debug/dynamic_debug/control | grep is_conn
pi#raspberrypi:~ $
pi#raspberrypi:~ $ sudo bash -c "echo 'file sound/soc/soc-dapm.c line 1175 +p' > /sys/kernel/debug/dynamic_debug/control"
pi#raspberrypi:~ $ sudo cat /sys/kernel/debug/dynamic_debug/control | grep dapm
pi#raspberrypi:~ $
... and I get no errors - but seemingly, nothing "sticks". (and yeah, I don't see this function being traced either).
The documentation says that +p does:
p enables the pr_debug() callsite.
I'm not sure what they mean by this - does it mean that if there are already existing pr_debug statements in the function, then they will be enabled (i.e. will print to syslog) with this? If so, what happens in the case when there are no such statements in the function - as is the case with is_connected_output_ep? Can I still setup dynamic debug to somehow trace this function - without having to manually insert printk or other statements and recompiling the kernel module?
Well, I did some more reading, and it seems the answer to:
does it mean that if there are already existing pr_debug statements in the function, then they will be enabled (i.e. will print to syslog) with this?
... is likely "yes" - so you cannot do dynamic debug of a function that does not have pr_debug statements in it already.
Also, it seems that the /sys/kernel/debug/dynamic_debug/control (upon read) is actually a list of all possible dynamic debug "probe points" if you will, along with their status (enabled or not), though I'm not sure about this.
Anyways, here is some more reading where this stuff is mentioned:
The dynamic debugging interface [LWN.net] 2011
Dynamic Debug, conference paper, 2009
So I cannot trace is_connected_output_ep with dynamic debug - so maybe I should look into ftrace or kprobes (dynamic probes) facilities of the Linux kernel...
EDIT: It turns out, dynamic_debug/control lists debuggable statements ONLY from currently loaded modules in the kernel! Example, there is a dev_dbg in the dpcm_path_get function in the soc-pcm.c source file, which ends up in the snd_soc_core kernel module (snd-soc-core.ko). This module by default is not loaded by Raspbian 9, so we get this:
pi#raspberrypi:~ $ lsmod | grep snd
snd_bcm2835 32768 1
snd_pcm 98304 1 snd_bcm2835
snd_timer 32768 1 snd_pcm
snd 69632 5 snd_timer,snd_bcm2835,snd_pcm
pi#raspberrypi:~ $ sudo grep 'soc-pcm' /sys/kernel/debug/dynamic_debug/control
pi#raspberrypi:~ $
Ok, now if the kernel module is loaded with modprobe, now suddenly the debuggable callsites appear in dynamic_debug/control:
pi#raspberrypi:~ $ sudo modprobe snd_soc_core
pi#raspberrypi:~ $ lsmod | grep snd
snd_soc_core 200704 0
snd_compress 20480 1 snd_soc_core
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_bcm2835 32768 1
snd_pcm 98304 3 snd_pcm_dmaengine,snd_bcm2835,snd_soc_core
snd_timer 32768 1 snd_pcm
snd 69632 7 snd_compress,snd_timer,snd_bcm2835,snd_soc_core,snd_pcm
pi#raspberrypi:~ $ sudo grep 'soc-pcm' /sys/kernel/debug/dynamic_debug/control
sound/soc/soc-pcm.c:1367 [snd_soc_core]dpcm_prune_paths =_ "ASoC: pruning %s BE %s for %s\012"
sound/soc/soc-pcm.c:1373 [snd_soc_core]dpcm_prune_paths =_ "ASoC: found %d old BE paths for pruning\012"
...
pi#raspberrypi:~ $ sudo grep 'dpcm_path_get' /sys/kernel/debug/dynamic_debug/control
sound/soc/soc-pcm.c:1331 [snd_soc_core]dpcm_path_get =_ "ASoC: found %d audio %s paths\012"
And finally, we can now enable this print statement:
pi#raspberrypi:~ $ sudo bash -c "echo 'func dpcm_path_get +p' > /sys/kernel/debug/dynamic_debug/control"
pi#raspberrypi:~ $ sudo grep 'dpcm_path_get' /sys/kernel/debug/dynamic_debug/control
sound/soc/soc-pcm.c:1331 [snd_soc_core]dpcm_path_get =p "ASoC: found %d audio %s paths\012"
Apparently, the disabled lines have a =_ symbol in the line, and the enabled lines have =p ...
Now all that I'd want, is to enable some statements before the driver is loaded, so I could monitor printouts in _probe functions of kernel module drivers...
You can add following argument to insmod
dyndbg="+p"
As a development environment for linux kernel, I'm using qemu with setting up initramfs as similar to what is shown here, with few additional executable. Basically, it uses busybox for creating minimal environment and package it up using cpio. Content of init is shown below.
$ cat init
mount -t proc none /proc
mount -t sysfs none /sys
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
exec /bin/sh
Using following command to start VM:
qemu-system-x86_64 -kernel bzImage -initrd initramfs -append "console=ttyS0" -nographic
It throws following error:
/bin/sh: can't access tty; job control turned off
Although, system functions normal in most cases. But, I'm not able to create background process:
$ prog &
/bin/sh: can't open '/dev/null'
$ fg
/bin/sh: fg: job (null) not created under job control
Root of all problems seem to be not having access to tty. How can I fix this?
EDIT: Apart from Accepted answer, as a get around cttyhack of busybox can be used.
$cat init
#!/bin/sh
mount -t proc none /proc
mount -t sysfs none /sys
mknod -m 666 /dev/ttyS0 c 4 64
echo -e "\nBoot took $(cut -d' ' -f1 /proc/uptime) seconds\n"
setsid cttyhack sh
exec /bin/sh
From Linux From Scratch Chapter 6.8. Populating /dev
6.8.1. Creating Initial Device Nodes
When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. Create these by running the following commands:
mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
You should then continue with the steps in "6.8.2. Mounting tmpfs and Populating /dev". Note the <-- below, and I suggest you read the entire free LFS.
mount -n -t tmpfs none /dev
mknod -m 622 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3
mknod -m 666 /dev/zero c 1 5
mknod -m 666 /dev/ptmx c 5 2
mknod -m 666 /dev/tty c 5 0 # <--
mknod -m 444 /dev/random c 1 8
mknod -m 444 /dev/urandom c 1 9
chown root:tty /dev/{console,ptmx,tty}
So I have the following setup:
[ec2-user#ip-172-31-9-177 ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 80G 0 disk
├─xvda1 202:1 0 6G 0 part /
└─xvda2 202:2 0 4G 0 part /data
All the tutorials I find say to use xfs_growfs <mountpoint> but that has no effect, nor has the -d option:
[ec2-user#ip-172-31-9-177 ~]$ sudo xfs_growfs -d /
meta-data=/dev/xvda1 isize=256 agcount=4, agsize=393216 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0
data = bsize=4096 blocks=1572864, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data size unchanged, skipping
I should add that I am using:
[ec2-user#ip-172-31-9-177 ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.0 (Maipo)
[ec2-user#ip-172-31-9-177 ~]$ xfs_info -V
xfs_info version 3.2.0-alpha2
[ec2-user#ip-172-31-9-177 ~]$ xfs_growfs -V
xfs_growfs version 3.2.0-alpha2
Before running xfs_growfs, you must resize the partition the filesystem sits on.
Give this one a go:
sudo growpart /dev/xvda 1
As per https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/recognize-expanded-volume-linux.html
You have a 4GB xfs file system on a 4GB partition, so there is no work to do.
To overcome, enlarge the partition with parted then use xfs_growfs to expand the fs. You can use parted rm without losing data.
# umount /data
# parted
GNU Parted 3.1
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit s
(parted) print
....
(parted) rm 2
(parted) mkpart
....
(parted) print
(parted) quit
# xfs_growfs /dev/xvda2
# mount /dev/xvda2 /data
Done. No need to update /etc/fstab as the partition numbers are the same.
Before running xfs_growfs, Please do the following step first:
#growpart <devicenametobeextend>
# growpart /dev/xvda 1
CHANGED: partition=1 start=4096 old: size=31453151 end=31457247 new: size=41938911,end=41943007
#xfs_growfs -d /
enter FYI for your reference
Many Servers by default won't have growpart utils So you can follow the below steps to do
Install growpart utils using package manager as per OS distribution below is for RPM/FEDORA based.
yum install cloud-utils-growpart
Run the growpart command on the partition which has to change.
growpart /dev/xvda 1
Finally run the xfs_growfs command.
xfs_growfs -d /dev/xvda1