Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running armhf (armv7l) application on aarch64 processor inside proot #151

Closed
ZhymabekRoman opened this issue Feb 15, 2021 · 10 comments
Closed

Comments

@ZhymabekRoman
Copy link

ZhymabekRoman commented Feb 15, 2021

Hello, is it realistic to fix the launches of the armhf (armv7l) application inside the aarch64 proot system? I noticed that system calls such as statfs generally work crooked in armhf (armv7l) binaries inside the aarch64 proot system.

@ZhymabekRoman ZhymabekRoman changed the title Running armhf application on aarch64 processor inside proot Running armhf (armv7l) application on aarch64 processor inside proot Feb 15, 2021
@ghost
Copy link

ghost commented Feb 15, 2021

Not sure if i can relate to this but i have issues going on when emulating armhf on arm64 with proot, it gives me this kind of error when setting up user account, even though i deleted lock files

Screenshot_2021-02-15-18-03-18-42.jpg

idk if it's something related to this issue

@ericek111
Copy link

ericek111 commented May 7, 2021

Same here on S10e. Because of that error, I cannot install my system. Everything works great on aarch64.

Setting up dbus (1.12.16-2ubuntu2.1) ...
groupadd: /etc/group.2526: lock file already used
groupadd: cannot lock /etc/group; try again later.
adduser: `/sbin/groupadd -g 101 messagebus' returned error code 10. Exiting.
dpkg: error processing package dbus (--configure):
 installed dbus package post-installation script subprocess returned error exit status 1

strace is of no help. It hangs indefinitely when tracing any executable.

EDIT:
I investigated some. "groupadd" uses the link function:
https://github.com/shadow-maint/shadow/blob/b30e9614c3dff4823f7d0989b64ecb80e2434612/lib/commonio.c#L179

Then it counts links pointing to the group database file:
https://github.com/shadow-maint/shadow/blob/b30e9614c3dff4823f7d0989b64ecb80e2434612/lib/commonio.c#L180

This could be perhaps a bug in hardlink emulation. Here's how it works: #31 (comment)

@ghost
Copy link

ghost commented May 7, 2021

Huh, so the issue of that is the hardlink emulation, there could be a workaround for that, rather than using a 32-bit version of proot

@ericek111
Copy link

ericek111 commented May 7, 2021

Yep. I'm experimenting a bit.

touch base
ln base link
ln base link2
stat --format="%h" base

Expected output (my Arch desktop and aarch64 proot installation from Andronix) is 3.
On 32-bit armhf Ubuntu proot, it returns 1.

Both executed with --link2symlink. In both cases, the links properly point to the original inode.

Another (unrelated? idk) thing; on aarch64, I see the UID and GUI properly set to 0. On armhf, I get "Uid: (10310/ UNKNOWN) Gid: (10310/ UNKNOWN)" in stat.

michalbednarski added a commit that referenced this issue May 9, 2021
#151

Also configure OFFSETOF_STAT_UID_32 in arch.h to fix second issue
reported in #151 (comment)
@michalbednarski
Copy link
Collaborator

Looks like I've missed this issue when it was initially reported, sorry.

Anyway now I think I have this fixed, for now you can test by building proot from source and if everything is okay then I'll submit to Termux apt repo.

It might be necessary to manually remove lock file which could previously became left over.

@ericek111
Copy link

Thanks! Strangely enough, Roman's proot-static built for 32b armhf works fine.
Will test this repo regardless.

@ghost
Copy link

ghost commented May 10, 2021

Thank you so much! i was able to create user accounts in 32-bit on 64-bit without problems

Screenshot_2021-05-10-09-08-10-74.jpg

michalbednarski added a commit to termux/termux-packages that referenced this issue May 10, 2021
termux/proot#151 link2symlink AArch32 support
@michalbednarski
Copy link
Collaborator

Updated version is now available in Termux apt repo

@ghost
Copy link

ghost commented May 11, 2021

Hi, i recently installed Ubuntu 32-bit on 64-bit, everything goes well and when trying to start xfce4 session, proot crashes

marcusz@localhost:~$ vncserver :1                          
You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n
xauth:  file /home/marcusz/.Xauthority does not exist

New 'X' desktop is localhost:1

Creating default startup script /home/marcusz/.vnc/xstartup
Starting applications specified in /home/marcusz/.vnc/xstartup
Log file is /home/marcusz/.vnc/localhost:1.log

marcusz@localhost:~$ export DISPLAY=fish: Job 1, 'proot-distro login ubuntu-12.04…' terminated by signal SIGSEGV (Address boundary error)
:logout
-su: /home/marcusz/.bash_logout: Function not implemented
-su: /etc/bash.bash_logout: Function not implemented
su: User not known to the underlying authentication module

Somehow the error spits out is about User not known to the underlying authentication module

However when using proot static 32-bit, xfce starts fine as intended, though only Tested on Ubuntu, other distributions isn't tested

Sorry for any inconveniences if things got worked out recently

@ghost
Copy link

ghost commented May 11, 2021

Also happens in Debian Sid 32-bit as well

/usr/bin/startxfce4: X server already running on display localhost:0
-bash: [4120: 1 (255)] tcsetattr: Function not implemented Bad system call                     
marcusz@localhost:~$ logout
-bash: /home/marcusz/.bash_logout: Function not implemented
-bash: /etc/bash.bash_logout: Function not implemented
fish: Job 1, 'proot-distro login sd --user ma…' terminated by signal SIGSEGV (Address boundary error)

Somehow this was caused by tcsetattr, though this is the only thing that i could spot, other GUI Applications like gtk3-demo also has the same effect when running GUI programs

michalbednarski added a commit that referenced this issue May 30, 2021
Currently when running in 32-on-64 mode sendmsg calls won't be patched

#151 (comment)
michalbednarski added a commit to termux/termux-packages that referenced this issue May 30, 2021
amuramatsu pushed a commit to amuramatsu/termux-packages that referenced this issue Jun 26, 2021
termux/proot#151 link2symlink AArch32 support
amuramatsu pushed a commit to amuramatsu/termux-packages that referenced this issue Jun 26, 2021
Grimler91 pushed a commit that referenced this issue Jul 25, 2022
#151

Also configure OFFSETOF_STAT_UID_32 in arch.h to fix second issue
reported in #151 (comment)
Grimler91 pushed a commit that referenced this issue Jul 25, 2022
Currently when running in 32-on-64 mode sendmsg calls won't be patched

#151 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants