Installing on steamlink

[Merith-TK]

Okay, so the way steamlink works for something like this. is you have your base rootfs that is R/O, but it is then overlayed with files from /mnt/config/overlay

Could one modify bedrock to use a different folder for its systems? because the steamlink does not have alot of free space and most methods of running any form of linux on it that is not steamlink, involves a USB, some helper scripts, and a chroot

I can setup the env to do this, but i need to know how to make bedrock use a different folder than default

[Merith-TK]

Okay this is more difficult than expected, i figured i could install the basic first, but ${color_alert} and ${color_norm} were giving "undefined" errors, so i removed them,

now i just get

~ # sh bedrock.sh
ERROR: Unexpected error occurred.

[Merith-TK]

in theory, this should be as easy as mounting /dev/block/sda1 (ext4) under /bedrock

[Merith-TK]

And that wont work as / is a read-only fs, meaning i cant physically make the mountpoint

[paradigm]

Just getting Bedrock's files on disk won't be sufficient to make them actually work here, sadly. There are two notable concerns such an effort would have to address:

1. Bedrock has a lot of design decisions which assume it is on the "real" root. For example, it makes heavy use of chroot relative to the "real" root it assumes it is on.

2. Bedrock assumes the system has a typical init sequence following typical kernel/initrd initialization. It does this to do runtime environment setup on which it heavily depends.

In theory these are surmountable problems with adequate effort:

• One avenue would be a major Bedrock refactor to make it aware it's not running on the real filesystem root. At the moment I'd be disinclined to accept a PR along these lines due to associated complexity not being worthwhile. I don't want performance and security related elements of the system to have to think about these kinds of things.
• Another avenue would be to make a container-like tool which sets up things like mount and PID namespaces; essentially a fancier chroot that retains Bedrock's design assumptions. This could be used to setup Bedrock at runtime and "chroot" in so the parent environment can use it. I don't plan on creating such a thing any time soon, but if others create a simple enough solution here I wouldn't mind it's official use for things like what you're pursing here.

[Merith-TK]

Well I think the hardest parts for bedrock on a steam link would be the storage issue, and injecting itself into the init

The steam link, you can't screw with the initrd/kernel as it's cpu is designed to only load kernels signed with a specific signature, which valve has not released a way of doing,

So the link will be stuck at the 3.8.16 kernel,

This repo has a working init injection for arch/systems, https://github.com/coderobe/archlinux-steamlink/

I am pretty sure the steam link uses runit or something simple, but this works

On Sun, Aug 2, 2020, 6:49 AM Daniel Thau notifications@github.com wrote:

Just getting Bedrock's files on disk won't be sufficient to make them actually work here, sadly. There are two notable concerns such an effort would have to address:

1.

Bedrock has a lot of design decisions which assume it is on the "real" root. For example, it makes heavy use of chroot relative to the "real" root it assumes it is on. 2.

Bedrock assumes the system has a typical init sequence following typical kernel/initrd initialization. It does this to do runtime environment setup on which it heavily depends.

In theory these are surmountable problems with adequate effort:

• One avenue would be a major Bedrock refactor to make it aware it's not running on the real filesystem root. At the moment I'd be disinclined to accept a PR along these lines due to associated complexity not being worthwhile. I don't want performance and security related elements of the system to have to think about these kinds of things.
• Another avenue would be to make a container-like tool which sets up things like mount and PID namespaces; essentially a fancier chroot that retains Bedrock's design assumptions. This could be used to setup Bedrock at runtime and "chroot" in so the parent environment can use it. I don't plan on creating such a thing any time soon, but if others create a simple enough solution here I wouldn't mind it's official use for things like what you're pursing here.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bedrocklinux/bedrocklinux-userland/issues/194#issuecomment-667676463, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPQOXWG433H2VD6H3ILJQDR6VVH5ANCNFSM4PSFPXJQ .

[paradigm]

The steam link, you can't screw with the initrd/kernel as it's cpu is designed to only load kernels signed with a specific signature, which valve has not released a way of doing,

So the link will be stuck at the 3.8.16 kernel,

This should be fine. That should be above Bedrock's minimum requirement, and Bedrock is designed to utilize kernel/initrd from other distros explicitly for situations like this.

This repo has a working init injection for arch/systems, https://github.com/coderobe/archlinux-steamlink/

Ahh, very cool! This probably provides the bulk of what is needed here. I didn't realize this was an option when I listed the above concerns.

In this case, I expect you can install ALARM (or some other distro) using this init injection technique. Once you've booted into that distro I expect Bedrock's hijack installer will work as-is. The pivot_root/chroot technique used by archlinux-steamlink should be adequate to resolve both of my above listed concerns.

You mentioned storage limitation issues earlier. Once Bedrock has hijacked ALARM (or whatever), you can then replace the essential parts of the system (e.g. init) with those from another distro and remove ALARM if you no longer want it; you're probably not stuck with it. If you want to minimize disk footprint, consider Alpine if you haven't already.

[Merith-TK]

In this case, I expect you can install ALARM (or some other distro) using this init injection technique. Once you've booted into that distro I expect Bedrock's hijack installer will work as-is. The pivot_root/chroot technique used by archlinux-steamlink should be adequate to resolve both of my above listed concerns.

One the main issues is that the steamlink cannot drop to a tty, all shell access is done over ssh solely as the SteamLink user interface firmware thingy, is still loaded first, meaning by the time the injection occurs, there is a splash screen that cannot be left

I know this has something to do with /etc/inittab however i have no clue how to safely modify this file (luckily, if i screw up, i delete the overlay cache and we good)

# Default runlevel 5
id:5:initdefault:

# System initialization.
si1::sysinit:/sbin/ueventd.sh &
si2::sysinit:/etc/init.d/rcS

# Runlevel 5
mu:5:wait:/etc/init.d/startup.sh
con:5:respawn:/bin/getty -l /bin/login 0 console

# Runlevel 6 (reboot)
l6:6:wait:/etc/init.d/reboot.sh

You mentioned storage limitation issues earlier. Once Bedrock has hijacked ALARM (or whatever), you can then replace the essential parts of the system (e.g. init) with those from another distro and remove ALARM if you no longer want it; you're probably not stuck with it. If you want to minimize disk footprint, consider Alpine if you haven't already.

The storage issues are generaly resolved by just putting whatever you need on a usb, and then overlaying files in the rootfs using usb://steamlink/overlay,

[paradigm]

One the main issues is that the steamlink cannot drop to a tty, all shell access is done over ssh solely as the SteamLink user interface firmware thingy, is still loaded first, meaning by the time the injection occurs, there is a splash screen that cannot be left

In terms of installing Bedrock, this should be fine. Presumably if archlinux-steamlink doesn't start an ssh server out of the box, you could configure it to. You could then run the hijack script as root. If everything goes well, you should retain Arch's init started ssh server when booting into Bedrock. If something goes wrong, though, it'd be quite a pain to debug.

In terms of using the system's graphics, I certainly see how you'd want to disable that to do your own thing.

I know this has something to do with /etc/inittab however i have no clue how to safely modify this file (luckily, if i screw up, i delete the overlay cache and we good)

Just from eyeballing it, I'd guess either it's something started by /etc/init.d/rcS (that isn't listed here directly) or it's /etc/init.d/startup.sh.

If you can ssh into the box and poke around at the process tree, you can probably figure out what executable is used to run the interface. Once you know the executable name, you could grep /etc to see what launches it directly, then work backwards to find what launches it indirectly. Alternatively, you might be able to just rename the executable so the default steamlink stuff can't run it with the expected name.

[Merith-TK]

Just from eyeballing it, I'd guess either it's something started by /etc/init.d/rcS (that isn't listed here directly) or it's /etc/init.d/startup.sh.

Yeah the second one exist

About the process tree thing, the only command that does this is the top command, and i have no clue how to configure that to show a "tree" veiw

[paradigm]

You don't strictly need a tree view, just a way to figure out what the GUI program name is. If you see something that could be the GUI from top, that could be sufficient. If top isn't cutting it, you could get the list of running executables with some scripting against /proc. Something like:

for d in $(find /proc -maxdepth 1 -type d); do readlink $d/exe; done | sort | uniq

Sadly this isn't something I'm equipped to help with remotely; hopefully you can poke around the system until you find it, or read about others similar experiences'; given the existence of archlinux-steamlink presumably other people have poked around here as well.