[BUG]: The system using openrc incorrectly configured the permissions for /dev/null to crw--w----

[hiruocha]

Kernel Version

4.14.357

Kernel Source Link (REQUIRED)

https://github.com/hiruocha/android_kernel_xiaomi_nabu

Droidspaces Version

v6.4.5

Rooting Method

ReSukiSU

Device OEM & Model

Xiaomi Pad 5 (nabu)

Android Version & ROM

Android 16 LineageOS 23.2 UNOFFICIAL

Execution Mode

DAEMON

Networking Mode

Host

Describe the Bug

When I manually build the system from scratch using the Gentoo official stage, or use the Armtix official image as the rootfs, the system incorrectly configures the permissions of /dev/null to crw--w----
This may be the reason why I cannot connect to the network in NAT mode.

However, this does not happen when using Gentoo downloaded from lxc, so I'm not sure what's causing the problem.

Steps to Reproduce

1. Build the rootfs from the Gentoo stage and refer to the wiki / Download the rootfs from the Armtix official image.

2. Install it.

Droidspaces-bugreport_2026-08-07_19-08-23.tar.gz

Logs / Screenshots

gentoo from stage

gentoo from lxc

armtix

I noticed that the problematic /dev/null belongs to the group tty.

Required Acknowledgments

• I have verified this is not a duplicate issue.
• I am using a kernel compiled strictly according to Droidspaces' official documentation.
• I am NOT using a kernel with 69+ random configs, CRC nukes, or a broken ABI.
• I have confirmed this issue persists in both Daemon and Direct modes.
• I admit that I am a clown for checking this box, confirming I have NOT read these rules.
• I admit I did zero research, didn't ask my AI waifu for a fix, and am dropping this here because I'm 100% sure the fault lies with Droidspaces.

[hiruocha]

Even after manually chmoding, a reboot restores the incorrect state.

Incidentally, other virtual devices (/dev/urandom, /dev/zero, etc.) do not exhibit this problem.

[ravindu644]

Yeah, this might be a bug in your specific kernel and mostly happens in some 4.14 kernels. we do chmod 666 these nodes when populating the /dev.

If the permissions are incorrect, even if you manually chmod them, they never changes. that's a kernel bug rather than a droidspaces bug imo...

[ravindu644]

In my case, they looks completely okay.

the issue happens when chmodding the node doesn't take any effect. this happens even if you manually chmod the node :(

[hiruocha]

I think I need to do more research to find the problem. Sorry, I'm a complete newbie to kernels.

[hiruocha]

I think I've found a solution:

1. Query /etc/inittab(If it exists)

The default might be:

# TERMINALS
#x1:12345:respawn:/sbin/agetty 38400 console linux
c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Reverse it

# TERMINALS
x1:12345:respawn:/sbin/agetty 38400 console linux
#c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

2. Check the openrc service

rc-update show default | grep agetty

If you see agetty.tty1 Remove these services immediately:

rc-update del agetty.tty1 default
# Repeat this for other listed tty services

Then restart the container, and everything will return to normal.

[hiruocha]

However, I haven't figured out why I can't connect to the network in NAT mode. Maybe it's related to dhcpcd?

[ravindu644]

I think I've found a solution:

1. Query /etc/inittab(If it exists)

The default might be:

# TERMINALS
#x1:12345:respawn:/sbin/agetty 38400 console linux
c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Reverse it

# TERMINALS
x1:12345:respawn:/sbin/agetty 38400 console linux
#c1:12345:respawn:/sbin/agetty --noclear 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

2. Check the openrc service

rc-update show default | grep agetty

If you see agetty.tty1 Remove these services immediately:

rc-update del agetty.tty1 default
# Repeat this for other listed tty services

Then restart the container, and everything will return to normal.

What?

[ravindu644]

However, I haven't figured out why I can't connect to the network in NAT mode. Maybe it's related to dhcpcd?

Yeah, configure dhcpd properly...

[hiruocha]

However, I haven't figured out why I can't connect to the network in NAT mode. Maybe it's related to dhcpcd?

Yeah, configure dhcpd properly...

I'll just use HOST mode.

[ravindu644]

Closing as this issue cannot be reproduced.