-
Notifications
You must be signed in to change notification settings - Fork 59
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
modules/steam: Add workarounds for OOBE #141
Conversation
One thing of note here: if steam was stopped "wrong", the updater may attempt to force an update. And thus may also break an existing and working steam instance. Though I'm unsure about how to reproduce. This is kinda out of scope for this current fix; OOBE is assumed to have been completed correctly. AFAIUI if you're still offline after a restart of the OOBE process, it will be okay because it has already been launched, and verified. Though [citation needed]. The iso couldn't test since there is no way to "properly" exit steam without a reboot. We may actually want to build a "recovery" applet type thing where we detect whether a key is held or not during steam launch, and if it is, we launch an app... or even "trivially" we can decide that e.g. holding B to launch the desktop session is an option, and just go to the desktop, where a user may be able to do useful stuff like connecting to the network. |
Just tried it - looks like the steam crashed right after the boot (Aug 16 10:26:10) and kept crashing until shutdown: |
So, to be fair I have not tested using your exact configuration, but on top of #142 and with that grub fix. So maybe there is something else going on with your configuration... ... but, looking at
I'm not 100% sure, but I believe this would be after the updater ran, so actual steam that got itself into a weird situation. It'd be interesting still to know what in your config compared to the distilled down caused that. Could it be having I'll try to take a look, but I believe that first issue (updater wanting to work before network is setup) should be solved, especially if you confirm that you didn't have the updater tell you that you should be online. |
Tried without it - same issue. (log)
I'll try #142 next |
#142 has the same issue. Couldn't get the logs since it's impossible to stay long enough in the tty and openssh wasn't enabled. I'll try with openssh enabled tomorrow EDIT: (log)
|
Also tried with #119, still crashing: journal.log [deck@nixos:~]$ md5sum /nix/store/r8rf9q07jnnaxy6bp5hlys9vfb4m3hvi-steam-jupiter-original-1.0.0.74/lib/steam/bootstraplinux_ubuntu12_32.tar.xz
d53aa7f82382c2383861499dd00bd380 /nix/store/r8rf9q07jnnaxy6bp5hlys9vfb4m3hvi-steam-jupiter-original-1.0.0.74/lib/steam/bootstraplinux_ubuntu12_32.tar.xz |
#119 was not meant to solve this; it got undrafted because this solves the only difference there was in the packaging of steam itself compared to the vendor image. |
I just tried again, and this time I made sure to have a declarative expression to test. Using this gisted expression: https://gist.github.com/samueldr/129e1674e06acd316b1ee379cd7ce906
Now, for extra spice:
Under that situation, steam doesn't crash, it will cleanly go to the updater window with the unhelpful error about connecting to a network. (I wonder if SteamOS has that issue too if you try hard to break it...) As a side-note, Can you provide a detailed list of things you do until you hit an issue? |
f9f7c63
to
7af13db
Compare
With this latest update, and its equivalent expression, the spicy parts now work as expected; not stranded without a connection. E.g., someone launching steam, connecting, powering off, will not be held into a bad place by the updater if somehow they start it back at a location without the initially setup access point. |
My Jovian-NixOS repo looks like this
And local nixpkgs checkout is on 54f1fa0447093a1ee1d19cd6eec6edc8b86fd5d6 Command used to build the iso
On the Steam Deck
Here's a video: https://drive.google.com/file/d/19vVBvbaC6C-tOk-ijT3UhotkDoTp0aSe/view?usp=sharing |
I don't know what to say... it works on my machine. The only difference I could see is coming from within the device(s) themselves. So, we're not using the same USB stick, that's 99% sure. I wouldn't think that itself would be the cause. Now, what might be a cause, is if your BIOS version is different. I am running (I think) the latest at F7A0116. I don't think that stable has the BIOS update. I know that older revs have a bug that required linux-side changes for the GPU driver to work correctly. I'm thinking this hunch could be right:
Can you check which BIOS version your deck is at? It's available in the setup utility. |
It's F7A0110. Is there an easy way to update BIOS from Jovian-NixOS? |
Two ways: fwupdMake sure the fwupd config is enabled (it should be by default).
Then uh... run a fwupd update. I forgot how that generally works. Vendor toolThe |
Tried booting the iso again - updating bios didn't help 😔 |
The steam updater will otherwise attempt to update even though there is no network connection. So we'll use approximately the vendor methods to decide what to do here. Additionally, we'll always disable auto-updates when offline. This will prevent stranding users with a valid steam install who happen to be offline.
9fed4c4
to
087813f
Compare
Discussion in the matrix room, and a last ditch effort showed that using my built image from the same out path worked here. fun. So I suspect we have to evaluate this PR with the implementation rather than exact reproduction at this moment. Mesa build is the only diff that is relevant [the other is the fwupd cab see #146]. And this tracks with your previous observations.
|
Conclusion for @misuzu's issues: bad luck and a file that broke (how?). Their dri I don't think there is anything spooky to consider from this conclusion, other than bad luck. Hopefully. So considering our successes running the iso with OOBE without internet connection, this PR should be good to merge. |
|
Indeed, from the nix path registration, it implies it went |
The steam updater will otherwise attempt to update even though there is no network connection.
So we'll use approximately the vendor methods to decide what to do here.
This was tested by using these:
Fixes #134
cc @misuzu