That file already exists in the efi folder, the fedora folder however does not exist
That file already exists in the efi folder, the fedora folder however does not exist
IWhen I installed bazzite, my ntfs drives were populated automatically. In trying to fix something else, I removed the default mount point for one and set it as something else. Now I am having trouble figuring out where the initial mounting configuration is stored so I can/how to revert it to that. Where should I start looking?
KDE Partition Manager works with /etc/fstab, which doesn't seem to have anything for the initally configured drive.
Edit: Anyone finding this, if you're dealing with an ntfs volume with a windows installation, it will mount read-only if windows is hibernated. Shut down fully with Shutdown in windows.
Also, remove the line from /etc/fstab and mount with sudo mount path|guid mountpoint
KDE Partition Manager works with /etc/fstab, which doesn't seem to have anything for the initally configured drive.
Edit: Anyone finding this, if you're dealing with an ntfs volume with a windows installation, it will mount read-only if windows is hibernated. Shut down fully with Shutdown in windows.
Also, remove the line from /etc/fstab and mount with sudo mount path|guid mountpoint
Dhey I noticed that there has been some successful builds and some not successful, what would make some succede and others not
VUsually some components will fail
VThat's why broken images usually come in groups
Ve.g. all deck builds will fail
VAll nvidia builds
Vetc. etc.
VFor example, most recently the Deck and Nvidia images failed
VExcept for asus-deck apparently, probably a quirk of that image
DI've noticed this in the log of bazzite-deck:kinoite
DVWhich I'm assuming is how it know it failed?
VBut again, as said in the past
VBuild failures are normal and expected
Dbut I don't think it failing over 8 days is normal
VYes, it can be
Tyeah i can... i got home from work rn so give me a second
VHow dare you
VI'm pretty sure the people working bazzite keep an eye on what builds
HIt's the BOOTX64.EFI that the UEFI on that computer doesn't like, just grab the grubx64.efi from whatever the other folder is called and replace BOOTX64.EFI with it.
Dwe gettin successful builds
KNew deck builds are out, this is a huge one because it adds all of the new packages for OLED support
KDon't swap just yet though, actual OLED decks will need to use the testing Branch for the meantime
KAlso @crushbutimbanned these builds have special considerations for deckhd
MAlright guess I’m giving it a try
KNote that this hasn't built yet, that'll be the next thing I work on
KThe reason it's relegated to testing is it will break secure boot on htpc users
KSo it's something we'll need to telegraph to users for a while before we can move it to stable
KThe new deck just needs too many kernel patches
KLastly, those same builds should now have working controls on the Ally
KI'll be sure to post here when that's done
Msome of us have tried (very unsuccessfully) to get parts of the OLED Deck running on Nobara so this is awesome to see 
EFresh images across the board now, including NVIDIA. It's all green
COh wow!
CStill no luck with 545 yet?
COhhh
CI thought they were available but not layering right yet
ENope. Let me dig up the URL
EI'm still seeing 535 in there
CGood to know it's probably more a matter of deployment delays than gnarly fixing stuff
E
PIs it safe for desktop?
Tit should be, yeah. those kernel arguments that are on the steam deck image are soley for the OLED deck, and HTPC users use the same image as the deck. secure boot on desktop images should be fine
Dnice. did you have to fix the issue yourself or was it resolved upstream?
Malso very interested in how you got all this figured out, I think Bazzite will be the first distro to have any deck OLED support
Tcan you change the name of the user?
Tpost setup or would this mess stuff up cuz it changes folder names
EYou'll be fine
Doled support came fast
