Jump to content

Any updates on desktop OS's?


Recommended Posts

  • 2 weeks later...
  • Replies 112
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I have been playing with chroot on the Pro¹ lately, extremely happy with it, even though it is still rough around the edges. Even my N900 never felt so close to an actual pocketable computer. Therefor

this is my mobile "desktop" solution. i want to make it with my pro1.

Ubu chroot on Pro¹ running SFOS: Thanks Preflex and TheKit!  

Posted Images

I did achieve my "desktop experience" using a Debian Chroot on top of a rooted LineageOS 16.0 (the same result could probably be obtained using Stock Android 9, if rooted).

I installed a customised Debian on a dedicated partition of my SD-card, basically following the receipes found here:

https://bogeskov.dk/DebianAndroid.html
https://wiki.debian.org/ChrootOnAndroid
https://unix.stackexchange.com/questions/321491/android-chroot-networking-issues

Using Run Userinit from F-Droid, I mount the Chroot at /data/DEBIAN and start its SSH server on boot of the Pro1 (I attach my Chroot script to this post for reference). Doing this gives CLI access to Debian from any Lineage/Android SSH client. I mount the Android filesystems (read only) in the Chroot. There is a second, common partition on the SD-card writable from both systems for data exchange. The Chroot script also starts a background process ('aid_dns_syncd') that keeps Debian's DNS in-sync with that of LineageOS, so that internet access just works (tm) in Linux.

A CLI Debian is already a very powerful tool in itself, especially as it is accessible via SSH: it allows e.g. to automate backup tasks or transfer files to and from the device via SFTP. Still, this does not yet qualify as a "desktop" experience, of course.

So my Chroot script also starts an XRDP-server. The latter is ready to spawn a KDE/Plasma 5 desktop on request by any RDP client (although I specifically restrict this server to listen to localhost only). I found (paradoxically for a Linux enthusiast) that Microsoft's Remote Desktop 8 App provides -- by far --  the best support of the Pro1's keyboard because it is able to forward scancodes. VNC -- the usually recommended way of accessing a Chroot desktop -- did not work for me, as Android VNC clients (at least all that I tested) are unable to send the Pro1's level-3 keys (essentially the yellow symbols), which are important for programming. That said, my XRDP does use a (Tiger)VNC frontend that I found to provide the most stable X11 server, although more performant solutions (xorgxrdp) do exist.

Using Remote Desktop 8 to connect to Debian's XRDP service allows to use the Pro1 like a miniature laptop. Remote Desktop 8 can emulate a touchpad-driven cursor, which allows to operate conventional desktop software much more conveniently than when using the touchscreen directly (trying to hit minuscule buttons or icons by fingertip is just frustrating and IMHO not suited for a working environment). A nice side effect of using XRDP and the Microsoft App is that they are able to forward sound from the Debian chroot to the Android sound system transparently. This does not work out-of-the-box though, one needs to manually compile and install the respective PulseAudio drivers in Debian, as described here:

https://github.com/neutrinolabs/pulseaudio-module-xrdp

That audio set-up works well enough for listening to local music players or Youtube music. The video frame rate of the latter is bad due to the lack of hardware acceleration and (probably) because of the additional overhead introduced by XRDP. But as I have Newpipe and VLC on LineageOS, I do not really care about that: Debian is for work, Lineage for fun. 🙂  

image.thumb.png.7076217648e5eaa81e06739037d0b8b4.png

image.thumb.png.23867bd5aa15bae652d486c37cb43718.png

Edit:

Since writing this post, I migrated my set-up from Debian 10 to Devuan 3 as explained in this post. Because of its traditional server init scripts, I found the latter to be more suited for a chroot environment.

Updated the chroot startup script accordingly.

 

99devuan_chroot_init

Edited by claude0001
Uploaded most recent version of chroot script.
  • Like 2
  • Thanks 2
Link to post
Share on other sites
  • 2 years later...

Hello @claude0001

After inserting partitioned SD Card (59 GB - FAT32, 59 GB - ext3), my F(x)tec Pro1 keeps saying "Memory card not supported" and keeps remounting internal eMMC storage, what is weird and annoying.

I'm running official latest Lineage 20, Magisk v26.1, MicroG, LSPosed.

Do you have any ideas? Seems like Android doesn't support mounting ext3.

Thank you

Link to post
Share on other sites
2 hours ago, Wunder Wungiel said:

Do you have any ideas? Seems like Android doesn't support mounting ext3

On LOS 16.0, ext3 is supported in the kernel. I do not know about LOS 20, but it would surprise me if someone had removed something as basic as ext2/3 from the config. Check this on your device:

# cat /proc/filesystems
nodev   sysfs
nodev   rootfs
nodev   ramfs
nodev   bdev
nodev   proc
nodev   cpuset
nodev   cgroup
nodev   cgroup2
nodev   tmpfs
nodev   configfs
nodev   debugfs
nodev   tracefs
nodev   sockfs
nodev   pipefs
nodev   devpts
        ext3
        ext2
        ext4
        vfat
        msdos
nodev   ecryptfs
nodev   sdcardfs
        fuseblk
nodev   fuse
nodev   fusectl
        f2fs
nodev   pstore
nodev   selinuxfs
nodev   functionfs

It is true that the ext3 partition is not mounted automatically. I do that manually using the init-script I provided above. After doing so, the partition is also visible to Android file managers.

That was actually the whole point of using ext3 for the rootfs of my GNU/Linux install: As Android (well LOS 16.0, at least) does not automagically try to do anything stupid with that partition, I have full control over how I mount and use it.   

ext3 was just one of all the low-level tricks I found while installing my GNU/Linux chroot on Lineage 16.0. I do not know if any of these still apply to later Lineage releases. Especially handling of SD-cards was unfortunately strongly changed after Android 10, I think. That's the reason I continue to use a custom LOS 16.0 ROM on my Pro1, which I update roughly every month with the latest security stuff:

I do have a Pro1-X with LOS 20, and had initially intended to port my GNU/Linux-chroot setup to that more modern environment (or at least try to), but with all the technical problems the prawn-X is causing me, I am no longer very enthusiastic to do that work ... 😞

Edited by claude0001
Link to post
Share on other sites
20 hours ago, claude0001 said:

# cat /proc/filesystems

I receive similar output, ext3 is here.

But: if SD with ext3 partition is in device, then Lineage keeps remounting internal storage, even if I manually mount that ext3 partition on SD with Termux (via su of course). I see folders of partition in mountpoint - but eMMC keeps being remounted. What can I do?

 

 

Link to post
Share on other sites
19 hours ago, Wunder Wungiel said:

I receive similar output, ext3 is here.

But: if SD with ext3 partition is in device, then Lineage keeps remounting internal storage, even if I manually mount that ext3 partition on SD with Termux (via su of course). I see folders of partition in mountpoint - but eMMC keeps being remounted. What can I do?

I tried formatting the SD card to ext3 once when I was still using the Pro1 under a previous LOS version (16 or 18), but while it was seen by the system and, at a first glance, seemed usable, it didn't work out because the OS does not properly deal with the owner and permission flags ext3 offers when it's seeing an SD card. Stuff apps put on the SD card frequently became unreadable, apps stopped working. So I went back to FAT...

Link to post
Share on other sites
21 hours ago, Wunder Wungiel said:

But: if SD with ext3 partition is in device, then Lineage keeps remounting internal storage, even if I manually mount that ext3 partition on SD with Termux (via su of course).

Actually, I was wrong in my previous post. In LOS 16.0, the ext3 partition does get mounted automatically under /mnt/media_rw/. I then just bind-mount that file to wherever I want (/data/DEBIAN, in my case). The difference to ext4 (and my reason for using it) was that Android 9 does not seem to subject ext3 partitions to a SELinux security context, which would effectively prevent a seperate (chrooted) OS to run on them.

Sorry for causing confusion, it's just quite long ago that I set this all up. Look at the initial lines of my chroot script above:

#!/system/bin/sh
#
# Script to set up the Debian/Devuan chroot environment on boot of LineageOS
#
#
# Set PATH used inside the CHROOT
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH
#
# Specify the mount point for Debian
export ROOT=/data/DEBIAN
#
# Mount the system partition containing Debain
# It turns out this should be an ext3 fs (not ext4), for things to
# work smoothly ...
mount -o bind /mnt/media_rw/88f89540-879a-4309-9776-bf276aaac733 $ROOT
#
# Make it a real root directory
mount -o remount,exec,dev,suid $ROOT
#
# Map all that strange stuff a root dir needs
for f in proc dev dev/pts dev/ashmem dev/cpuctl dev/cpuset dev/stune dev/cg2_bpf sys acct; do mount -o bind /$f $ROOT/$f ; done
#
# Mount the other (ext4) partition of the sd card, containing data to be
# shared with Android apps.
mount -o bind /mnt/media_rw/24a37a95-5429-4d2f-b98d-27fccea25e17 $ROOT/mnt/sdcard
#
# Mount the Android default storage, so we can access that from Debian too.
# For write access to this partition, kernel keys are needed. While these are
# inheritet automatically when chroot-ing, am PAM policy in Debian has them 
# dropped upon login via SSH by default. Either change the PAM scripts accor-
# dingly or set 'UsePAM no' in /etc/sshd_config. 
mount -o bind /data/media/0 $ROOT/mnt/storage
#
# Make /run, /tmp, and /var/tmp tmpfs to save write-cycles to the sd card
chroot $ROOT mount -t tmpfs tmpfs /run
chroot $ROOT /bin/mkdir /run/lock
chroot $ROOT mount -t tmpfs tmpfs /run/lock
chroot $ROOT mount -t tmpfs tmpfs /tmp
chroot $ROOT mount -t tmpfs tmpfs /var/tmp
#
# Make sure Debian has a SysV-style shared-memory device available
# otherwise things like firefox will not run
chroot $ROOT /bin/mkdir /run/shm
chroot $ROOT mount -t tmpfs tmpfs /run/shm
chroot $ROOT /bin/ln -s /run/shm /dev
#
# create utmp file for registering logins
chroot $ROOT /usr/bin/touch /run/utmp
chroot $ROOT /bin/chown root:utmp /run/utmp
chroot $ROOT /bin/chmod 664 /run/utmp
#
# Allow normal users to FUSE-mount their own stuff
chroot $ROOT /bin/chmod g+rw /dev/fuse
chroot $ROOT /bin/chgrp plugdev /dev/fuse
#
[...]

... that's where all of the GNU/Linux chroot filesystem gets defined.

2 hours ago, Rob. S. said:

I tried formatting the SD card to ext3 once when I was still using the Pro1 under a previous LOS version (16 or 18), but while it was seen by the system and, at a first glance, seemed usable, it didn't work out because the OS does not properly deal with the owner and permission flags ext3 offers when it's seeing an SD card. Stuff apps put on the SD card frequently became unreadable, apps stopped working. So I went back to FAT...

UNIX user permissions are of course a caveat when using ext3, but I am pretty sure @Wunder Wungiel is aware of that. Defining the usual Unix groups used by Android also inside the chroot, and making the chroot user a member of GID 1023 ('media_rw' in Android) helps somewhat, but does not solve all problems. Every Android app runs with a seperate UID and uses that for accessing any files not meant to be shared with other programs. This is by design and part of the Android security mechanisms (and it breaks core Unix philosophy in the process ... 🙄).

In Android 9 / LOS 16, it is actually also possible to use ext4 for an SD data partition shared with non-Android programs. One then needs to additionally disable SELinux and do some remounting. I call this script after boot to achieve that:

#!/system/bin/sh
#
# Disable SELinux, it prevents write access to our EXT4-formatted SD-Card
# partition.
#
/vendor/bin/setenforce 0
#
# Re-mount data partition of external SD-card read-writable by all apps
#
mount -o remount,mask=0 /mnt/runtime/write/24a37a95-5429-4d2f-b98d-27fccea25e17

where "24a37a95-5429-4d2f-b98d-27fccea25e17" is the id of the ext4 SD partition.

Even shared access to the built-in default Android storage is possible. Carefully read and understand the part about bind-mounting /data/media/0 in the script above, especially the comment about kernel keys and PAM policies in the chroot. That part took me some time to figure out ...

Edited by claude0001
Link to post
Share on other sites

So basically, something changed in some Android / Lineage version. You were using 16.0 for that purpose, ext3 was mounted automatically. In 20.0 it is mounted too (!) in /mnt/media_rw - but Android, for some reason, keeps unmoutning and mounting internal storage and both partitions of SD (first is FAT32, second ext3). And if SD has only one partition with ext3, the same happens. Just internal storage and first and only partition of SD in this case.

It's sad. I even wanted to give up with your solution, and use Andronix Modded OS (which I bought for $2) instead. It works in Termux ~/ (in its data folder, i.e. /data/data/<>) - but is quite slow, so I thought that a dedicated ext3 / ext4 partition on fast SD would improve its performance... it would, if Android didn't make above problems with remounting. I can't understand it, why it happens.

I could migrate to Lineage 16 of course... but I already like 20 😂. Also, there is one other reason. Key Mapper uses the accessibility service to work, and, if accessibility service is enabled, then you can't use other language on physical keyboard. It was fixed in Android 12 (Lineage 19.1). And I use Key Mapper a lot...

Anyway, thank you for all your help.

Link to post
Share on other sites
33 minutes ago, Wunder Wungiel said:

In 20.0 it is mounted too (!) in /mnt/media_rw - but Android, for some reason, keeps unmoutning and mounting internal storage and both partitions of SD (first is FAT32, second ext3). And if SD has only one partition with ext3, the same happens.

Check if your SD partition gets mounted with a SELinux context (see my edited post above regarding this aspect). If yes, I would first try to disable the latter ("/vendor/bin/setenforce 0"). In fact, I'd do that anyway, just to be sure. ^^

33 minutes ago, Wunder Wungiel said:

Also, there is one other reason. Key Mapper uses the accessibility service to work, and, if accessibility service is enabled, then you can't use other language on physical keyboard.

If you mean this bug:

https://gitlab.com/LineageOS/issues/android/-/issues/3321

reported by @EskeRahn, I think that was introduced only in LOS 18.1. As far as I understand, things were fine in 16.0 and 17.1. I do not know for sure, though, as I'm not using multiple keyboard layouts on my 16.0 ROM. If you provide me with sufficiently precise test-case instructions, I can check the functionality in question on my device if you want ...

Edited by claude0001
Link to post
Share on other sites

Hello! After running

/vendor/bin/setenforce 0

Remounting problem is gone!

Can I run it at boot as an other init script? I assume your script does it, so I guess that yes.

 

I will try to run Andronix Modded OS from SD Card now.

Edited by Wunder Wungiel
Link to post
Share on other sites

Okay. I created selinux_init at /data/local/userinit.d with following content:
 

#!/system/bin/sh

/vendor/bin/setenforce 0

And hit the button in Run Userinit app.  But it doesn't seem to be launched at boot, because Android after reboot starts that party with partitions again, unless I run "/vendor/bin/setenforce 0" as root in Termux, manually.

 

I forgot to chmod +x 🤭

Edited by Wunder Wungiel
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Terms