In IRC I was told that this line in /etc/fstab : shm /dev/shm tmpfs nodev is superflous nowadays - bit it isn't. As soon as I try to start a user mode linuc image I do get : tfoerste@n22 ~ $ start_uml.sh -r ~/virtual/uml/n22stab4 Locating the bottom of the address space ... 0x1000 Locating the top of the address space ... 0xc0000000 Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...OK Checking syscall emulation patch for ptrace...OK Checking advanced syscall emulation patch for ptrace...OK Checking environment variables for a tempdir...none found Checking if /dev/shm is on tmpfs...OK Checking PROT_EXEC mmap in /dev/shm...Operation not permitted /dev/shm must be not mounted noexec This is a x86 Gentoo.
That's your UML script. Maybe you should make it check that, too.
nope, that comes from the UML linux executable, this is the command line : /usr/local/bin/linux-v3.17-rc1 earlyprintk ubda=/home/tfoerste/virtual/uml/n22unst4 ubdb=/mnt/ramdisk/n22unst4_swap eth0=tuntap,tap0,72:ef:3d:5d:d3:db mem=2000M con0=fd:0,fd:1 con=pts umid=uml_n22unst4 rootfstype=ext4
And FWIW re-adding that line to /etc/fstab makes the error went away. So b/c the way was changed of how shm is handled at least an news item and/or an ewarn would be nice and/or a hint in the handbook would be nice.
(In reply to Toralf Förster from comment #2) > nope, that comes from the UML linux executable, this is the command line : > > /usr/local/bin/linux-v3.17-rc1 Gentoo can't fix /usr/local for you either, but if the executable can't fix the issue by remounting /dev/shm with the required options, then your script certainly can. Or you set up your own fstab as circumstances warrant. It's too late now for a news item, since these changes probably went stable more than a year ago with baselayout-2.2.
ok, understood, but just for the record: it is not an issue with a /usr/local, it is UML itself, which depends on "exec" on /dev/shm
(In reply to Toralf Förster from comment #5) > ok, understood, but just for the record: > > it is not an issue with a /usr/local, it is UML itself, which depends on > "exec" on /dev/shm I thought Gentoo has always mounted /dev/shm noexec; I don't remember OpenRC ever doing otherwise. @vapier: Is this something I should change in OpenRC?
HHm, I must admit, I cannot swear, that my fstab is the original entry from the installation and not later modified by me to run UML. But because I do not see in that file any comment from me I believed it at least...
Without ANY shm entry in fstab: shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) So if this should be changed, then it's the kernel that needs to change.
(In reply to Rick Farina (Zero_Chaos) from comment #8) > Without ANY shm entry in fstab: > > shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime) > > So if this should be changed, then it's the kernel that needs to change. Can you try booting with init=/bin/bash on the kernel command line, manually mount /proc, and then check to see if the kernel automounted /dev/shm? Not sure if this is caused by CONFIG_DEVTMPFS or not. But by booting straight into bash, you'll eliminate any startup scripts as the culprit.
(In reply to William Hubbs from comment #6) yes, baselayout-1.x & openrc have long used noexec in /dev/shm. we do not want to change that behavior. the # of packages that want to get executable shared memory maps can probably be counted on one hand. Chrome comes to mind (NaCl needs to generate code on the fly and share it between processes). not sure why UML needs interprocess executable memory ... i'm not familiar with its internals. (In reply to Rick Farina (Zero_Chaos) from comment #8) that's because baselayout/openrc have long mounted a default one for you when there's no entry in fstab. this isn't a kernel issue at all (well, ignoring the fact that UML is in the kernel source tree, but that's orthogonal to what you actually mean here).
