No gui

[cryptolok]

After YOLO installation with root on a physical machine and patch applying, when trying to launch nofear --gui xclock:

rm: cannot remove '/home/user/.Xauthority*': Permission denied

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?

[cappsule]

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!

[cryptolok]

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.

[cappsule]

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/
 }

[cryptolok]

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 usermanually?

[cappsule]

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?

[cryptolok]

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.pyby the way). I'll try to reinstall it, using different options and trying to debug the proccess.

[cappsule]

What's your Debian version?

[cryptolok]

The test machine has Debian 8 (jessie) 3.16.36 x64

[cryptolok]

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.

[cappsule]

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:~$ 

[cryptolok]

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.

[cappsule]

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/?).

[cryptolok]

I was able to solve the permission problem by adding sticky 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 ?

[cappsule]

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:

• the mode of 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.

[cryptolok]

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.

[cappsule]

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/)?

[cryptolok]

700 a.k.a. rwx------ So my system has some influence on the build's rights...

[cappsule]

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)?

[cryptolok]

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)

[cappsule]

Try to delete the default profile with nofear --delete-profile default, or use a temporary profile (nofear -t).

[cryptolok]

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 :)