Re: XWayland Victory!
 

Sounds like we're the same. On my system "mode" was empty and "modes" had the screen res.

Re: XWayland Victory!
 

All right then, i'll make script.

One thing, I do not understand how this works? is this some kind of emulation? Or does this arch linux use sailfish os kernel?

Re: XWayland Victory!
 

It's not emulated. It's just a chroot. The kernel (and some other resources, hence the bind mounts) are shared.

See: https://en.wikipedia.org/wiki/Chroot

Re: XWayland Victory!
 

Here is script to automatically get resolution.
This only needs one argument. for example: startlxde.

This can be change to search that file and if it's not available or if it could not find resolution to ask user to enter by hand, but i'm on work now and do not have time. When i get home i'll add that.

If you change $y $x places you will see half of your screen. Because Arch itself will open in landscape mode, but the whole window is in portrait mode. So if we somehow manage to rotate whole window itself it will work in landscape mode :)

Re: XWayland Victory!
 

Your script had typo and there were many outputs in terminal. correct it.

/usr/share/easychroot/scripts/start_xwayland_user_shell.sh: line 12: dbus-lsunch: command not found

it should be dbus-launch :)


Best way to kill arch linux processes

just run this command

pid=`ps -ef | grep -v grep | grep xw | awk '{print $2}'` && kill -9 $pid


Can you tell me what terminal output do you have when running DeskChroot.sh?

Here is what i am having everytime i run it on Nexus 5

Re: XWayland Victory!
 

Hi. In regards to several of the warnings you are getting, there seems to be an inconsistency in the file naming convention. If you go to

/usr/share/kservicetypes5

you will see that the file (or services) do not have a dash in the name.

That is

kwin-effect.desktop

is called

kwineffect.desktop

in the directory. Although probably not the best solution, I just made a symbolic link to the correct file in the same directory.

Re: XWayland Victory!
 

Great work. Thanks for it. I run it on a oneplus one.

I tried to use plasmashell but everything is too small. (1920x1080 display) and eventhough I change dpi and 'scale desktop' a new start shows everything still too small (except the 'scale desktop' preview which seem to be the only widget that knows about this setting).

Re: XWayland Victory!
 

If you're using xfce, you might try changing the setting in the "Fonts" tab in xfce's Appearance settings.

Re: XWayland Victory!
 

Thanks!

For me the files were in /usr/share/kservicetypes5, and not in /usr/local/share/kservicetypes5.

Also there is a similar issue with the kwin-scripts.desktop file, which can be fixed the same way.

Re: XWayland Victory!
 

Oops! You are right. I had cut and pasted the wrong part of the error message when writing the post. The path begins with /usr/share... Regardless, the warning was due to the file name. I'll edit my post. Thanks!

Re: XWayland Victory!
 

I searched that file on places error gave me but did not find, i found that file on github i even wanted to create it but i did not. It was working and i left it.

preflex

i used xfce on my nexus and that setting in fonts does not change anything. now i tried this on my nexus 4 and everything is so much better.

1 everything is much bigger and easy to use.
2 terminal in arc linux works

Nexus 4 is amazing device for SFOS and this too. Aliendalvik works on it without issues, google play, video playback, camera everything works. I even think to have nexus 4 as my daily driver not nexus 5 haha

Re: XWayland Victory!
 

You can use this script, it needs only one argument and it's either 'terminal' or 'startlxde'

You do not need two separate scripts.

Re: XWayland Victory!
 

DPI FIX!

QT_WAYLAND_FORCE_DPI="160" kwin_wayland --xwayland ...

This will make your title bars nice and big. Use whatever value you'd prefer
If you use xfce4, you should also set it in settings->appearance->fonts.


Also, my manager app is coming along well, and should see an alpha release shortly.

Re: XWayland Victory!
 

Bonus round:

I messed around with Ubuntu Zesty Beta 2 rootfs from http://cdimage.ubuntu.com/ubuntu-bas.../zesty/beta-2/
It works ... mostly.

Unlike Archlinux, chromium does not work.
However, also unlike Archlinux, firefox does work!

Re: XWayland Victory!
 

Sneak preview screenshot of manager app:

Re: XWayland Victory!
 

To set XFCE dpi from command line:

xfconf-query -c xsettings -p /Xft/DPI -s 160

Re: XWayland Victory!
 

I have compiled glibc 2.23 using crosstool-ng for those who have 3.0 kernel. In ubuntu 17.04 there is 2.24 version but it requires 3.2 kernel, however 2.23 works.

Also, I had to forget something because you need to create few symlinks from /lib/arm-linux-gnueabihf/*so* to /lib/.

Re: XWayland Victory!
 

Excellent, thanks. If you get time, could we have a quick Ubuntu setup guide, or would I be better waiting for preflex's installer?

Re: XWayland Victory!
 

Basically steps are the same like on arch. You have to unpack ubuntu rootfs to directory and install bunch of packages.
The best would be to work together (in github or here) to create well working build and chroot scripts.

I have attached my scripts but they need improving before execute.

Re: XWayland Victory!
 

For which devices is this an issue?

Re: XWayland Victory!
 

For few ancient devices like photon q.
https://wiki.merproject.org/wiki/adaptations/libhybris

Btw Weston works in landscape mode but is slow and without touch support.

Re: XWayland Victory!
 

Hi,

Sorry to bother you again.

When I do the chroot, I get 'FATAL: kernel too old', so presumably, this is where the glibc 2.23 comes in? What do I need to do with that?

Also, 'cp /usr/bin/qemu-arm-static $UBU_DIR/usr/bin/' failed, as I don't have that file. Do I need it?

Thanks

Re: XWayland Victory!
 

You need to unpack glibc.tar.gz and copy content to ubuntu. As I said there is something wrong so you need to create symlinks (ugly workaround):
ln -s $UBU_DIR/lib/arm-linux-gnueabihf/*.so* $UBU_DIR/lib/

If you do it on device you don't have to copy qemu, otherwise install qemu-user-static.

Re: XWayland Victory!
 

I have the weird problem that any program that runs as normal user doesn't have internet access (such as chromium).
As root in the chroot, I can update and if I start Firefox as root I also have there access.
But ping as nemo says e.g. 'permission denied'

Does anyone have an idea why that's the case?


Mystery solved:
the nemo in chroot is not in group `inet`. I solved it via:

Re: XWayland Victory!
 

I tried again to get Maemo UI running in ArchLinux chroot (built from https://github.com/fremantle-gtk2) with XWayland. It's still too hacky, but UI itself is pretty smooth. What I tried is modifying Cogl Xlib winsys to connect both to X server and Wayland, but initializing EGL with Wayland instead, so libhybris Wayland platform can be used.

http://i.imgur.com/JyloVey.jpg

Some LXDE apps look surprisingly nice with Sapwood theme engine, by the way. I wonder if anyone would be interested to get this working with chenliangchen's keyboard device.

Re: XWayland Victory!
 

Wow! That is awesome!

How to build this, or can you share the rootfs?

I've had some stuff chewing up my free time lately, but I was hoping to finish up my utility this weekend or next week. I'd love to be able to build in support for launching this.

Re: XWayland Victory!
 

I plan to upload PKGBUILDs once it becomes more usable, but need to do some more packaging/testing/fixing first.

Re: XWayland Victory!
 

Hey, any progress on that? This looks great. I'm sad to see that this thread has not been active since months.

[Edit] Just sent a PM to Preflex to check directly with him, since it seems he has been away from TMO for some time now. It's time to cross fingers.

Re: XWayland Victory!
 

Playing around with this, I have a few noob questions. What would be the best way to use Arch chroot from the SD card (ext4) on a Jolla C instead of /opt/easychroot/Arch? The latest release on Preflex's github repository says that one should unpack the .tar.gz file to /opt/easychroot/Arch/, but that eats way too much space on the Jolla C's root partition.

I see two solutions but I'm not sure which one is the worst (I'm sure none can be considered good, but waiting some feedback):

# A
- tar -xvf ArchRootfsFile.tar.gz /media/sdcard/XXX/easychroot/Arch/ (as nemo or as root by the way?)
- Alter ArchChroot.sh and DeskChroot.sh to use this path in all mount points instead of /opt/easychroot/Arch/
- mount -o remount,exec /media/sdcard/XXX
- pkexec chown root /usr/lib/sudo/sudoers.so and pkexec chown root /etc/sudoers (I don't know why but I got errors with these files, telling me that they must be owned by uid 0; maybe because I unpacked the .tar.gz file as nemo?)
- sh DeskChroot.sh 1268 720 startxfce4

This is what I tried. It worked (at least it launched a Xfce4 window but I did not try many things there), except from the above technicalities.

# B (not tested and I don't know what I'm talking about, don't try if you don't know more than me!)
- tar -xvf ArchRootfsFile.tar.gz /media/sdcard/XXX/easychroot/Arch/ (as nemo or as root by the way?)
- mount /media/sdcard/XXX/easychroot/ /opt/easychroot/
- sh DeskChroot.sh 1268 720 startxfce4 (without altering the mounting points in Preflex's original DeskChroot.sh)
- Not sure if needed: mount -o remount,exec /media/sdcard/XXX
- Not sure if needed: pkexec chown root /usr/lib/sudo/sudoers.so and pkexec chown root /etc/sudoers

Would # B work, or would it eat my brain (and Jolla C's brain)? I have not tried it. I'm not even sure it would provide any benefit except from no need to alter the bash scripts from Preflex's github repository, I would probably still have the exec and uid 0 issues I had in # A I suppose?

Also, when I close the Xfce4 window and kill the xwayland processes with "pid=`ps -ef | grep -v grep | grep xw | awk '{print $2}'` && kill -9 $pid", I suppose everything is still mounted, and turns out I cannot launch any Sailfish application (the cover will show the loading animation, and eventually close) nor reboot. The phone can be turned off, but maybe not completely since I have to remove the battery to reboot it. Any ideas? I'm a bit lost and I may very well be playing with fire here, trying to do things I am not mastering.

Re: XWayland Victory!
 

I tried it yesterday evening on the Jolla tablet again. I have an Arch i686 chroot (tablet is Intel x86_64). The image linked to by Preflex had a lot of stuff missing from the Arch base system (had to install a lot to make it work).

For your questions, I would untar the image as root. Only /home/nemo should be owned by nemo user. I kept my image in /home/nemo/ on the tablet (too little space elsewhere). I don't really see the point in choosing either #A or #B in your example. Whatever works for you.

There is a typo in the start_xwayland_user_shell.sh script: s/dbus-lsunch/dbus-launch/

For your last problem, it sounds like you have bind mounted directories several times, creating loops. This happened to me and I had to hard reboot the device.

Also, starting the session as user at some point would make sense, there were some errors with regards to this. I'm toying with this.

Btw, the usability of the normal desktop environments is questionable at this point, at least on the tablet. Even though I tried to do changes as recommended for HIDPI, most things are incredibly small on a 1536 x 2048 display. So far I've only toyed with XFCE.

Re: XWayland Victory!
 

My past job was around deploying chroots (for scientific software on a clusters)

As root (unless the chroot doc specifies otherwise).
I don't know the specific details of *that* chroot, but most of the time it requires some specific access rights (e.g.: a different owner user:group) and you need root rights to set those, otherwise tar will complain that it cannot change the rights to the untarred files .


Good idea, but won't necessarily work :

- some will just call "chroot" to start the environment inside a new path name space (i.e.: the will see the content of the tar as "/usr/lib64" instead of "/opt/easychroot/Arch/usr/lib64")
that is simply a change as you mention.

- some chroot might entirely rely on environment variables, like "LD_LIBRARY_PATH" to indicate where to fetch the .so dynamic libraries (e.g.: "/opt/easychroot/Arch/lib64" instead of "/usr/lib64")

- but other my use Rpaths : search patch directly set inside an elf executable. (i.e.: the files in "/opt/easychroot/Arch/bin" are designed to search first in "/opt/easychroot/Arch/lib64". If the libraries are instead in "/media/sdcard/XXX/easychroot/Arch/lib64", the executable will miss them and default to the next search path which will lead to the Phone's own /usr/lib64, which won't contain what you need).

I'll have to check exactly how the archive work.

Usually debian works like the first case above. (it's basically a regular "/ust" debian tree, put into a different path that you "chroot" into).

Gentoo works using a mix of the other 2 solution (it's basically gentoo, but recompiled to work out of a sub-directory instead of /usr).

The best would be to head for your solution B :

Bind mounting could work.

But you could as well put a symlink :
Both should work equally well.

And both work regardless of how the Arch chroot is organised.

Yes, it is needed.
By default, the mount script ( /usr/sbin/sd-mount ) uses noexec.

Re: XWayland Victory!
 

Thanks to both of you for your detailed answers. I was concerned about # B because there was some kind of mount loop and I was afraid it would end up in http://forum-images.hardware.fr/imag.../oh%20shi-.gif. The symlink seems like a good alternative. I thought about it but never remember in which order to put the source and destination arguments. :D

Can I put the following line at the beginning of DeskChroot.sh?

Are there any side effects to expect, for the other files stored on my SD card (all my android_storage for instance, the rest is mostly just documents)?

Also, I suppose my issues with /etc/sudoers and sudoers.so was related to the fact that I unpacked the .tar.gz as nemo. I'll do it again as root.

Re: XWayland Victory!
 

So I fixed the typo Jukk reported, and then tried # B. Unfortunately, I can't get xfce running using solution # B, either with a symlink or a mount point to /opt/, while it did work yesterday when I tried with # A. However, several things were different, as I also had unpacked the .tar.gz as nemo, and had to solve several things manually after that, so I'm not exactly sure how to replicate and identify the exact source of the problem now. I did not try it extensively either yesterday so I don't know if it was fully working with # A, probably not, but at least a window was launched, as opposed to now. Maybe the issue I'm having now is not even related to # A or # B, but to the rootfs being unpacked as nemo?

This is the output of what I tried (with a symlink):

DeskChrootOrig.sh is the original script from Preflex's github repository with the unaltered paths.

Any ideas?

Re: XWayland Victory!
 

You need to check that the directories exist before mounting. And after chrooting, check that it looks like you are inside the correct environment (should look like normal arch linux filesystem in this case). I recommend ssh:ing to the device and configure mounting and chrooting everything that way (much more easy to handle terminal from a PC). Of course starting xwayland and xfce must be done on the device itself, so you need to also to chroot on the device before doing that (mounting is only required once).

The easiest thing to do is to put the image where you want and then correct the paths in the script. There is no reason in this case to keep the exact paths as written in the original script. The only reason I see for that in some other case, is if you have some external software managing chroots, which at least I don't have on the Jolla device. Or if the images are specially built (not like copies of a normal linux system).

DrYak's instructions may apply when you have custom chroot images (maybe built from the host system), but in this case we have a normal Arch filesystem inside a tar. It would be the same as when you have a linux system on a hard disk that is currently unbootable and you use a rescue image (USB/CD) to boot and then mount the hard disk in a temporary directory, bind mount proc, sys, dev, etc. and then chroot into it and do the resuce operations. I've done this many, many times. Once in a chroot in such an image, it works just like a normal linux environment and no need to mess around with any libraries etc.

Re: XWayland Victory!
 

I don't think the missing directories in /home/nemo are not the real issue, they were already missing when I got xfce4 to start the other day.

Alright for the paths, then if there is no need to keep them as in Preflex's original file, I'll just use my altered script with the sd card path. However the same problem persists: I get these segmentation faults at the end and xrdb errors. I have no idea what they mean unfortunately, I'm not familiar with that. The only things that changed is that I untared the rootfs as root instead of nemo this time (and eventually did not have to fix uid 0 issues), and I fixed the typo in start_xwayland_user_shell.sh. Since you all said the .tar.gz should not be unpacked as nemo, I'm guessing you did it as root and got it working.

I am sshing no worries! You can see it in the terminal output I pasted above. Are you sure that starting xwayland and xfce cannot be started from ssh as well? I don't understand why it would be different, and in fact I'm almost sure I did it from ssh when I managed to get Arch and Xfce running correctly.

Re: XWayland Victory!
 

I confirm having the same issue after creating the missing /home/nemo folders with nemo:nemo ownership and running a DeskChroot.sh with /path/to/sdcard/easychroot instead of /opt/easychroot in the mount commands:

Re: XWayland Victory!
 

Whenever shell scripts are failing and you don't know why, run all of the commands step by step in terminal. Now it looks like it is crashing when launching kwin_wayland, but you will see it better if doing it manually. Maybe some packages are missing from the image?

Re: XWayland Victory!
 

Thanks Jukk. In fact I did, sorry if I did not tear it down from the beginning, but I still get the same error without much more details than what you already understood from the full output above:

Mounting is not the issue, chrooting in Arch is no issue either, but issues appear when start_xwayland_user_shell.sh is started:

But I suppose it's nothing, probably just due to the fact that it never worked before in this rootfs (remember that I deleted the one I unpacked as nemo and unpacked a new one as root) so there is no .lock file to delete in Arch's system.

Kinda works I guess since there's an output (not sure this is the expected output though?), but regardless of the next command to be executed (could be something as simple as ls or pwd), a segmentation fault will appear. In fact, the segmentation fault comes with this kwin_wayland command, but only appears in the next command due to the & at the end. Without the &, I just get the segmentation fault without the 11469 output.

From there, and until this issue is solved, I'm not sure it makes much sense to further investigate the next commands in the script (export DISPLAY=:0, then xhost +, then sudo -u nemo bash /usr/share/easychroot/scripts/start_de.sh "$Start_DE") as they are probably influenced by this error.

Is kwin_wayland causing a segmentation fault for you too guys? Maybe someone using a Jolla C as well, or at least an ARM device?

Re: XWayland Victory!
 

Bump! Any ideas? I'd like to make it work, I have a use for some desktop applications, and I think functional chroot will be very convenient when Chen's phone becomes a real thing (if we manage to rotate the chroot display into landscape).

Re: XWayland Victory!
 

When you run kwin_wayland --xwayland... do you see a window?
Perhaps it would help to use a different OS base for the chroot. Debian has lots of ARM packages..
You could also use the android runtime and use xserver xsdl as a workaround.