guys
I've mounted cgroup V2 manually but I found there are none controllor in the root hierarchy.
[root#node5 /]# mount -t cgroup2 none /cgroup2/
[root#node5 /]# cd cgroup2/
[root#node5 cgroup2]# ls
cgroup.controllers cgroup.max.descendants cgroup.stat cgroup.threads
cgroup.max.depth cgroup.procs cgroup.subtree_control
[root#node5 cgroup2]# cat cgroup.controllers
[root#node5 cgroup2]# uname -r
5.0.0-rc6+
This is the expected behavior. It's really due to the fact that, very likely, you have both the older cgroups v1 as well as the newer cgroups v2 present, IOW, they're mixed. Now no controllers show up in v2.
What you can do is disable v1 and retry. To disable cgroups v1, reboot the box passing this kernel command-line parameter via your bootloader (GRUB, if on an x86):
cgroup_no_v1=all
After booting with this, pl mount and check, it should show up (provided of course it's configured in the kernel).
Related
I'm currently tiptoeing into custom kernel building.
I first started on a VM in VirtualBox, installing a fresh distribution of Ubuntu Server 20.04.
I followed the following procedure:
# getting the archive
cd ~/src/linux/
wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.4.91.tar.xz
tar -xf linux-5.4.91.tar.xz
cd linux-5.4.91/
# getting the config of the kernel currently running
cp -v /boot/config-$(uname -r) .config
# adapting the config to the target kernel, selecting the default for everything
make oldconfig
# adding manually a suffix to the kernel name: "-tony"
make menuconfig
# building and installing modules & image
time make -j $(nproc)
sudo make modules_install
sudo make install
Everything goes fine, although the build takes a bit longer than expected (~30 minutes on a 6-core AMD Ryzen 5 3600 6-Core Processor, with 32 GB of RAM; I assigned 6 CPUs over the 12 available to the VM).
However, when I check the size of the source directory, now containing the object files of everything built, the size of the drivers directory bothers me:
user#vm:~/src/linux/linux-5.4.91$ du -hd 1
1.3G ./fs
544K ./certs
34M ./block
128K ./usr
41M ./tools
208K ./LICENSES
58M ./security
48M ./Documentation
3.4M ./init
58M ./include
895M ./sound
73M ./lib
5.1M ./ipc
95M ./crypto
2.0G ./net
2.2M ./samples
446M ./arch
5.2M ./scripts
195M ./.git
4.8M ./virt
142M ./kernel
56M ./mm
13G ./drivers
20G .
13 GB looks like a lot.
When I look at the installed files, the modules also looks very big (5.6G):
root#vm:/# find -name '*5.4.91*' | xargs du -hs
20G ./home/user/src/linux/linux-5.4.91
105M ./home/user/src/linux/linux-5.4.91.tar.xz
5.6G ./usr/lib/modules/5.4.91-tony+
4.0K ./var/lib/initramfs-tools/5.4.91-tony+
912M ./boot/initrd.img-5.4.91-tony+
232K ./boot/config-5.4.91-tony+
12M ./boot/vmlinuz-5.4.91-tony+
4.5M ./boot/System.map-5.4.91-tony+
Especially when I compare with the vanilla kernel installed with the distribution:
root#vm:/# find -name '*5.4.0-62*' | xargs du -hs
...
262M ./usr/lib/modules/5.4.0-62-generic
4.0K ./usr/lib/modprobe.d/blacklist_linux_5.4.0-62-generic.conf
4.0K ./var/lib/initramfs-tools/5.4.0-62-generic
...
12M ./boot/vmlinuz-5.4.0-62-generic
79M ./boot/initrd.img-5.4.0-62-generic
236K ./boot/config-5.4.0-62-generic
4.6M ./boot/System.map-5.4.0-62-generic
262M vs 5.6G seems like a lot of difference, taken into account that I took the same config file (the cp -v /boot/config-$(uname -r) .config command).
I also reproduced the same results on Ubuntu Server 18.04.
Moreover, I tried on my host directly (no VM) with again the same results.
I am obviously missing something here, but I cannot find what:
should I strip the kernel / the modules from unused symbols?
is there a configuration that is missing somewhere ?
Thank you in advance for your help!
Disabling CONFIG_SLUB_DEBUG, CONFIG_DEBUG_INFO and CONFIG_DEBUG_MISC in the kernel configuration resulted in reasonable build performance:
real 22m19.559s
user 119m17.273s
sys 12m15.424s
And the following size for the modules:
root#vm:/usr/lib/modules# du -hs *
261M 5.10.10-stripped+
262M 5.4.0-64-generic
Which is even better than the shipped kernel :) (notice I updated the kernel source, but it doesn't change the result if using the same kernel).
Apparently, one can also use make modules_install INSTALL_MOD_STRIP=1 to strip the modules when they are built with debug symbols, reducing the size without having to change the build options.
Installing with that option on the already-stripped kernel & modules as described above resulted in the following size:
user#vm:/usr/lib/modules$ du -hs *
260M 5.10.10-stripped+
262M 5.4.0-64-generic
We effectively gain one more megabyte from this additionnal stripping.
I am trying to run a Docker image based on an ARMv7 container on a x86 computer. According to this site, it is possible by running this container first.
docker run --rm --privileged hypriot/qemu-register
This command works on Mac OS X and on an Ubuntu 19 virtual machine (with a Windows 10 host). However, when I try to run on CentOS 7 and one of the AWS A1 instances, I get the message standard_init_linux.go:211: exec user process caused "exec format error". The CPU for the CentOS 7 is an Intel Core i7-8700K and AWS A1 is based on the Graviton processor.
Anyone know what I'm missing here?
The complaint on the AWS A1 instance is with installing miniconda. I'm not sure if there is a way to say yes (to continue to install) since the -b flag already is supposed to get miniconda to install silently.
Step 6/11 : RUN /bin/bash /tmp/miniconda.sh -b -p /opt/miniconda
---> Running in ab9b5fef6837
WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> Aborting installation
AWS A1 instances do support running Armv7 binaries. Using the available Ubuntu 18.04 AMI for A1, run this on the command line:
cat /boot/config-4.15.0-1043-aws | grep "CONFIG_COMPAT=y"
If this succeeds, then the AMI and kernel have been built with support for running 32-bit executables on the 64-bit platform. To test this capability, install using apt-get install gcc:armhf libc6:armhf to get a minimal 32-bit build environment, create an executable and execute readelf -h on it. You should see the Machine listed as ARM, not AArch64. Execution should also succeed.
Testing docker with armv7 images also works out of the box on the Ubuntu 18.04 AMI on A1. I tested via docker pull armhf/ubuntu:latest and then entered interactive mode using bash and tried installing Miniconda3. The problem does appear to be with the Miniconda install script linked above. It tries this unconditionally on line 58:
if [[ `uname -m` != 'armv7l' ]]; then
echo -n "WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> "
read ans
if [[ ($ans != "yes") && ($ans != "Yes") && ($ans != "YES") &&
($ans != "y") && ($ans != "Y") ]]
then
echo "Aborting installation"
exit 2
fi
fi
Docker does not do any rewriting of what uname -m returns, it will see AArch64 on the A1 instance and it will trip up there. Commenting this block out should get you going on the A1 instances.
For getting this to work on your x86 laptop, you will need to copy qemu-arm-static to the docker image to enable emulation. I am not sure, but I would suspect that uname would still not return the proper machine-type Miniconda expects.
When I run make run.byte I get this error ocsigenserver: ocsigen:main: Fatal - You are not allowed to use port 80.. I've tried sudo make run.byte but sudo doesn't know about opam or ocsigenserver. I've tried to play with wwwuser in the Makefile.options, but I can't make it work.
The README generated by the distillery doesn't give much information, and I can't find anything online.
make test.byte works just fine.
Any idea please?
edit:
It looks like it has nothing to do with eliom/ocaml, non root users just can't run anything on ports lower than 1024 on Ubuntu. But I still don't understand why the distillery suggests that I can do it if my wwwuser is me, I don't think there's any way this is ever going to work.
I also don't understand how I am supposed to run sudo make run.byte, opam is installed in my ~ directory, sudo cannot find ocsigenserver.
I could make it work by running everything as root, but anytime I run an opam command as root I get the you shouldn't use opam as root warning. I don't think this is the way I'm supposed to run it. Something's not right.
With previous release of eliom (eliom.5.0.0) - I have not used yet the fresh 6.0.0 release - you have to install first your eliom application :
sudo make install
Then you have to kill the process listening to the 80/tcp port (ex: sudo netstat -tulpn 80 | grep :80 will help identify the process listening to that port - most likely apache2 or lighthttpd).
Then, you run your executable:
sudo PATH=$PATH OCAMLPATH=$OCAMLPATH LD_LIBRARY_PATH=$LD_LIBRARY_PATH
make run.byte
This is what is written in README created with eliom-distillery - but take care to set your env variables before :
OCAMLPATH is the location of ocaml used in your env (in my env :~/.opam/4.02.3/bin).
LD_LIBRARY_PATH : .opam/4.02.3/lib/stublibs (otherwise dllssl_threads_stubs is not found)
I did the following both on Ubuntu 14 and SUSE Linux Enterprise Server 11 (x86_64) where libcgroup is installed, with root:
cgcreate -t ngam:home -a ngam:home -g cpuset:/nadav2ndCpuSet
cgset -r cpuset.cpus=1 nadav2ndCpuSet
After that, if you cat /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.cpus,
you will get:
1
which is good! as it is supposed to work.
Then, from user ngam, I ran the following cmd:
cgexec -g cpuset:nadav2ndCpuSet ~/whileLoop
where whileLoop is just a simple program that runs in a loop doing sqrt.
After that, I got the following error msg:
cgroup change of group failed
Why is it happening?
Thanks!
I ran into something similar while playing with cgroups on Ubuntu 16.04 just now.
When using the controller cpuset, cpus and mems are not initiated. Therefor you manually have to do it. Since you already specified cpuset.cpus you only need to set cpuset.mems
simply running
echo 0 > /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.mems
or
cgset -r cpuset.mems=0 nadav2ndCpuSet
would solve your problem.
for more info on cpuset see http://man7.org/linux/man-pages/man7/cpuset.7.html
What I found is I forgot to make cgconfig start with system reboot, so a simple systemctl start cgconfig resolve the problem, and then do not forget systemctl enable cgconfig to make it start with system reboot.
I know my this answer might not be relevant to the question. I hope when people search the error cgroup change of group failed, this answer could help them.
BTW: systemctl start cgconfig is for centos 7, for centos 6 you may use service cgconfig start / chkconfig cgconfig on
Getting a strange error on my Crouton chroot on my Chromebook after apt-get install smlnj and attempting to call sml from the terminal, an error that I haven't been able to find anywhere else:
$ sml
/usr/lib/smlnj/bin/sml: Error -- unable to map 1179648 bytes, errno = 1
/usr/lib/smlnj/bin/sml: Fatal error -- unable to allocate memory object for BIBOP
Any guidance?
Edit: This issue (bug #120) was fixed in SML/NJ version 110.77 (release notes) by enabling MAP_ANONYMOUS, which was previously unsupported in Linux. Installing the latest version of SMLNJ would be preferable to the solution below, since it doesn't require weakening the security of the system. If you do continue via modifying the permissions of /dev, it's advisable to remove exec permission after each session.
This problem is primarily reproducible in a Chromium OS environment running ChrUbuntu or Crouton, but may happen to other users in other environments who have a similar problem.
Running strace on sml gives this (attempted) operation before the error output:
open("/dev/zero", O_RDONLY) = 4
mmap2(NULL, 1245184, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, 4, 0) = -1 EPERM (Operation not permitted)
According to the mmap(2) documentation, EPERM indicates that the system is attempting to allocate memory with execute permission in a directory that is marked noexec.
Indeed, mount gives:
...
devtmpfs on /dev type devtmpfs (rw,nosuid,noexec,relatime,size=960456k,nr_inodes=240114,mode=755)
...
The solution is thus to remount /dev with exec permission:
$ sudo mount -o remount,exec /dev
$ sml
Standard ML of New Jersey v110.75 [built: Thu May 9 05:41:01 2013]
-