Closed cryptolok closed 7 years ago
Weird. I think the error comes from https://github.com/cappsule/nofear/blob/8255095392fb5f5f5d356381db875b98da6bcd95/src/gui.sh#L10. However, I don't understand how you can get this error since gui.sh
runs as root.
Can you reproduce it with a new profile (nofear --gui --temporary xclock
)? Otherwise, could you edit /usr/local/share/nofear/gui.sh
in the host in order to launch bash
from the xpra_cleanup
function, and understand the root cause of this issue?
Thanks!
Still reproducible with a temporary profile and no shell pops-up after modifying xpra_cleanup
.
However, now I have a new error:
umount: /virt/target: target is busy
Nothing in the kernel logs.
I made a mistake, gui.sh
runs as user
actually. Anyway, how is it possible to get this error with a temporary profile? .bashrc
is the only file copied to /home/user/
during the initialization.
Could you apply the following patch to get a shell before the GUI startup and list the directory content with ls -al /home/user/
:
--- src/gui.sh 2016-10-19 08:52:20.099013760 +0200
+++ /usr/local/share/nofear/gui.sh 2016-11-04 09:49:09.283163266 +0100
@@ -7,6 +7,7 @@
function xpra_cleanup()
{
+ bash
rm -f ~/.Xauthority*
rm -rf ~/.xpra/ ~/.dbus/
}
Actually, I might know what could cause such problem.
Editing xpra_cleanup()
doesn't help much, nevertheless I remarked that the directory /home/user
isn't created at all and the whole file-system is owned by user and group 0
:
drwx------ 3 0 0 4.0K Oct 24 10:36 home
So, it's normal that the GUI doesn't launch since, it just can't create the X
files, the question is why?
Another thing is that apparently the user isn't created as well since, users
and who
produce no output, whoami
says:
cannot find name for user ID 2000
Was it due to some abnormal behavior during the install or/and patching for Debian?
Should I create user
manually?
The VM filesystem doesn't seem to be correctly initialized. /usr/local/share/nofear/rootfs.tar.bz2
should be extracted to /virt/target/
during the creation of a new profile: https://github.com/cappsule/nofear/blob/b1099c06230cb5da2b78ecb87b386e59438c2347/src/overlayfs.sh#L12.
Is rootfs.tar.bz2
invalid? Did you build the archive from scratch with build.sh filesystem
before installing NoFear with install.sh
?
I have "untared" rootfs
into /virt/target
, but without any effect, still same errors.
I builed it following the instructions in YOLO
mode (which should build everything), after applying the patch for Debian in distro
(which modifies gui.sh
and nofear.py
by the way).
I'll try to reinstall it, using different options and trying to debug the proccess.
What's your Debian version?
The test machine has Debian 8 (jessie) 3.16.36 x64
Just reinstalled it, but it's still the same...
I did build.sh filesystem
separately though.
And the rootfs
, wasn't copied to /virt/target
, copying/extracting it doesn't change anything.
I think I'll study the source code, unless you can propose something else.
I just tested NoFear on a fresh install of Debian Jessie (debian-8.6.0-amd64-netinst.iso
), and it works fine (with and without --gui
option)...
$ uname -a
Linux debian-jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
$ cat /etc/issue
Debian GNU/Linux 8 \n \l
Here are the exact commands used to install NoFear:
$ git clone https://github.com/cappsule/nofear
$ cd nofear/
$ patch -p1 < distro/debian-stable.patch
$ ./build.sh filesystem
$ su
# ./install.sh
And the output of a console session (I also get the umount
error, but it doesn't matter):
blah@debian-jessie:~$ nofear
CPU: vendor_id 'LKVMLKVMLKVM' unknown, using generic init.
CPU: Your system may be unstable.
microcode: no support for this CPU vendor
user@nofear-default:~$ id
uid=2000(user) gid=2000(user) groups=2000(user),5(tty)
user@nofear-default:~$ uname -a
Linux nofear-default 4.4.27 #1 SMP Wed Oct 26 17:50:11 CEST 2016 x86_64 GNU/Linux
user@nofear-default:~$ exit
exit
umount: /virt/target: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)
reboot: Restarting system
blah@debian-jessie:~$
I did the exact same thing and the behavior is similar, except that I got:
bash: /etc/bash.bashrc: Permission denied bash: /home/user/.bashrc: Permission denied
When running in console and:
chroot: failed to run command '/usr/local/share/nofear/gui.sh': Permission denied
for GUI, so as it fails, it quits immediately, thus I have directly the exit error:
umount: /virt/target: target is busy
The whole installation was done as root. I'll continue the investigation on my side.
In the first comment you wrote that nofear works fine without GUI, while further comments contradict this statement. It's quite difficult to follow because each comment describes a different error...
It's clear that you encounter a permission issue. If running nofear as root solves the issue, there's at least one file/folder with invalid read/search permission on your filesystem (maybe a component of /usr/local/share/nofear/
?).
I was able to solve the permission problem by adding s
ticky bit (not really secure, but it's a test PC), although I wouldn't need it if I run it as root
(which is the case), so it's running under another user (staff
or libvirt-qemu
) ?
When I said "without the GUI it's working well", I meant that I had the console, but I ignored the errors about:
bash: /etc/bash.bashrc: Permission denied bash: /home/user/.bashrc: Permission denied
since, they are not really important for me, except that if it's impossible to access /home/user
:
rm: cannot remove '/home/user/.Xauthority*': Permission denied
it prevents X session (GUI) from starting.
So the main question for me is why after the exact same installation instructions (and probably configuration), either the filesystem doesn't build properly, either the hypervisor isn't working as expected ?
Well, let's solve one issue at a time. In a previous comment, you wrote that /home
has the following permissions and owner: drwx------ 3 0 0 4.0K Oct 24 10:36 home
. This is the /home
directory inside the VM, right? That doesn't make sense. In nofear's source:
rootfs/home/
is 0755
build.sh filesystem
preserves its mode (thanks to cp -p
)tar tjvf build/rootfs.tar.bz2 ./home/
shows that /home
's mode is still 0755
Could you confirm that the following command gives that output in the host?
$ tar tjvf /usr/local/share/nofear/rootfs.tar.bz2 ./home/
drwxr-xr-x root/root 0 2016-11-06 16:08 ./home/
drwxr-xr-x root/root 0 2016-11-06 16:08 ./home/user/
-rw-r--r-- root/root 105 2016-11-06 16:08 ./home/user/.bashrc
Thanks.
There is clearly a permission issue, because:
$ tar tjvf /usr/local/share/nofear/rootfs.tar.bz2 ./home/
drwx------ root/root 0 2016-11-08 07:30 ./home/
drwx------ root/root 0 2016-11-08 07:30 ./home/user/
-rw------- root/root 105 2016-11-08 07:30 ./home/user/.bashrc
So the filesystem doesn't build properly.
I'll try to play with umask then and/or modify the source.
I don't see how it can be related to umask, because neither git
, cp -p
nor tar
relies on the current mask. What's the mode of rootfs/home/
in nofear's source (stat -c '%a' rootfs/home/
)?
700 a.k.a. rwx------ So my system has some influence on the build's rights...
OK that explain the issue, but we still don't know why the files mode is invalid. I was wrong: git
and zip
do respect the current mask. Can you still reproduce this issue if you set a more permissive mask (umask 0002
) before cloning the git repository (or downloading and extracting the zip archive)?
Just did the build with umask 000
, rootfs
is "lucky" (777
), but when launching the console, still the same thing, not enough rights (700
for /home
)
Try to delete the default profile with nofear --delete-profile default
, or use a temporary profile (nofear -t
).
IT WORKED!
So yeah, was an issue with my umask which was 077 :) so you have to take in count the defined umask or just define the needed-one in the code, like 002
I still had to chmod -R o+rx /usr/local/share/nofear/
though, for gui.sh
, probably because of the umask as well
Anyway, the issue can be considered as closed, thanks for your help and the amazing project :)
After
YOLO
installation with root on a physical machine and patchapply
ing, when trying to launchnofear --gui xclock:
Exit status 0 and kernel logs indicate nothing, whereas no GUI is lanched, but the
DISPLAY
variable is correct.Without the GUI it's working well.
Any suggestions?