ruh-roh
- Posts
- 4
- Comments
- 89
- Joined
- 6 days ago
- Posts
- 4
- Comments
- 89
- Joined
- 6 days ago
Spitballing:
Depending on how demanding those games are, perhaps they could still be run in VMs, just without physical GPU at all? Then you can passthrough USB controllers or attach USB devices just for the input and audio.
I guess you probably want third "management monitor" for this where you run virt-manager.
I'm guessing a "thin client" setup might not make sense here, but otherwise if you have some laptops around to use as "terminals viewers" that could also work I guess. I guess you would just do Steam Link remote play if this is just for Steam gaming though.
This gives a little bit of credence to the theory of an old installation taking precedence.
- Are there other EFI partitions around? Try booting explicitly from each one and see if you get different results
- Are there old bootloaders or entries from no longer existing installations lingering around on yor EFI drive? Move them from a live env to a backup or just delete them if you are confident.
- How about NVRAM? It's a way for the OS to configure boot straight to your mobo; separate from any disks attached. It doesn't look like it to me but perhaps it is possible your mobo is still trying to load stale OS from NVRAM config and your newest installation didnt touch it? Manually overriding boot in BIOS like above should root out this possibility.
Just to root out the x-y factor, could you elaborate on your goals and how you wish to use it? I think "multi-seat" is a bit of a fuzzy term at this point and perhaps other solutions than what it's typically referring to is more appropriate for your use-case.
I haven't set up a single-GPU classic multiseat myself but a cursory reading from Debian wiki and Arch wiki Talk say it should be possible. There is mention of Xephyr, which QubesOS is using to do something similar with their "GUI domain". Maybe looking at that can be useful for you.
Two other things to consider could be VM with PCI-passthrough of the GPU (this does require a second GPU or an APU/iGPU in order to still have graphics on the host OS), or running secondary X servers with TigerVNC that you can then run fullscreen using vncviewer. The latter scales very well on a single GPU and works great for usual desktop/browser/dev but I'd be curious about gaming performance.
https://doc.qubes-os.org/en/latest/user/advanced-topics/gui-domain.html
https://doc.qubes-os.org/en/latest/developer/system/gui.html
Is the Flatpak version running inside it’s own “box” and it isn’t getting SU permissions across my whole system?
Indeed it is running sandboxed!
Same principle as running uid 0 inside a rootless container.
You can poke around a shell inside the sandboxed environment with
flatpak run --command=bash org.freecad.FreeCADand tweak access with FlatSeal.Changing
/etc/fstabonly won't change anything if/can not be mounted. How would it pick up those changes? I think you are on the right track but missing the part with updating the initramfs.OP, in case you still haven't given up I think I can fill in the gaps. You got a lot of advice somewhat in the right direction but no one telling you how to actually sort it out I think.
It's likely that your
/dev/sdb2is now either missing (bad drive or cable?) or showing up with a different name.You want to update your fstab to refer to your root (and /boot and others) by UUID= instead of /dev/sdbX. It looks like you are not using full-disk encryption but if you are, there is
/etc/crypttabfor that.First off, you actually have two
/etc/fstabs to consider: One on your root filesystem and one embedded into the initramfs on your boot partition. It is the latter you need to update here since it happens earlier in the boot process and needed to mount the rootfs. It should be a copy of your rootfs/etc/fstaband gets automatically copied/synced when you update the initrams, either manually or on a kernel installation/upgrade.So what you need to do to fix this:
- Identify partition UUIDs
- Update
/etc/fstab - Update initramfs (
update-initramfs -ukallor reinstall kernel package)
You need to do this every time you do changes in fstab that need to be picked up in the earlier stages of the boot process. For mounting application or user data volume it's usually not necessary since the rootfs fstab also gets processed after the rootfs has been successfully mounted.
That step 3 is a conundrum when you can't boot!
Your two main options are a) boot from a live image, chroot into your system and fix and update the initramfs inside the chroot, or b) from inside the rescue shell, mount the drive manually to boot into your normal system and then sort it out so you don't have to do this on every reboot.
For a), I think the Debian wiki instructions are OK.
For b), from the busybox rescue shell I believe you probably won't have the
lsblkorblkidlike another person suggested. But hopefully you canls -la /dev/disk/by-uuid /dev/sd*to see what your drives are currently named and thenmount /dev/XXXX /newrootfrom there.In your case I think b) might be the most straightforward but the live-chroot maneuver is a very useful tool that might come in handy again in other situations and will always work since you are not limited to what's available in the minimal rescue shell.
Good luck!
Linux is not like Windows where you can run programs on any partition or inserted media ; you can only run executables on the primary boot partition. Its therefore pointless IMO to have more than one partition (plus a swap partition).
What are you on? You can run executables from any partition as long as it is not mounted with the
noexecmount option.Configuration UI can be added regardless of what happens with defaults. Defaults change is not a blocker for exposing configurability. If anything I'd say you got it backwards: Don't switch long-standing defaults until there is a discoverable and accessible way to change it.
Have you tried complaining to the manufacturer? I hear some allow trade-ins for defectives ones. You may not get a brand-new one but as long as it's not defective it should easily get you a decent drive on the swap market.
Thank you, I'm glad you like!
not having worked with memmap before, it is not immediately obvious to me which hex means what (I am guessing RANGE@START? ). Would be nice to have a link to an explanation there.
I just have the link to the kernel docs because I think they do a better job explaining it than I would 😁
But yeah, basically. Except for this use-case you want
RANGE$STARTnot@. And you can use human sizes like128M$RANGE.There is one part in the post mentioning how to "pad holes" in failing areas. Maybe I should expand it with some details around aligning reserved address space.
Otherwise, corruption of the RAM itself does not usually spread like mold in bread or wear out and fail in similar ways to flash memory.
You are telling people to break rule 4, which I find a reasonable one: "Don’t duplicate the full text of your blog or github here. Just post the link for folks to click"
It's a static HTML page with no JS. I think telling people that's unwelcome and that it's all-in on your platform or GTFO is what is poor taste. Maybe one day my blog will speak native ActivityPub if I bother setting up a non-static hosting for it.
I am not going to rewrite the whole post and have it maybe render poorly in your client due to handling inconsistencies and maybe be gone in 10 years due to platform changes just so you don't have to click. Just disable JS and image loading in your browser or read it with lynx or sth if you are concerned.
Lowering frequency is often the right solution and I do mention it in the writeup. I couldn't find any up-to-date, accurate and accessible info on how to safely keep running with actually faulty DIMMs and it's not obvious so I thought people might find working instructions helpful.
If you're still wary of using some old 3200 stick you have and can't or won't RMA, please sell it to me instead of binning it :3
I have a hard time imagining a less rewarding user-facing software to be maintainer of. That’s probably why there isn’t one.
Thousands of hours and being blamed for dozens of people softbricking their PCs (which they now probably lack the USB route to recover from) - all because writing an ISO to USB and rebooting is too much friction?