Open m4tx opened 10 years ago
turn off automount for that partition?
I don't think that OS will even work without mounting it... Especially, it may cause problems when updating GRUB.
Not really. Boot partitions shouldnt automount and mine isnt.
Although it looks like automounting /boot/efi is a default behavior of Ubuntu and Ubuntu-based distros (and Debian maybe? I'm not sure) and since Steam supports this OS as "the way it's meant to be used", I think it should handle that.
In Ubuntu / Debian's case, I'm fairly sure that /boot/efi would be automounted so that kernel updates are able to be processed without any additional mounting/unmounting logic in the package manager. (Note: This is speculation, not fact.)
If the boot partition is automounted or not is not particularly relevent since both behaviors are generally accepted in practice.
@m4tx the bootloader and package manager (to do updates) should be the only elements of the system that should use data on the boot partition. Once the kernel is loaded into memory, it is an inert part of linux.
+1
Hello, is anyone still experiencing this issue on an up to date system?
Yes, it seems that on current Steam beta the issue is still here.
System information:
Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(TM) i7-6800K CPU @ 3.40GHz
CPU Family: 0x6
CPU Model: 0x4f
CPU Stepping: 0x1
CPU Type: 0x0
Speed: 3800 Mhz
12 logical processors
6 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 4.15.9-1-ARCH
X Server Vendor: The X.Org Foundation
X Server Release: 11906000
X Window Manager: GNOME Shell
Steam Runtime Version: steam-runtime-beta-release_2017-10-05
Video Card:
Driver: NVIDIA Corporation GeForce GTX 1080 Ti/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 390.42
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 59 Hz
VendorID: 0x10de
DeviceID: 0x1b06
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 3840 x 2160
Desktop Resolution: 3840 x 2160
Primary Display Size: 20.75" x 11.65" (23.78" diag)
52.7cm x 29.6cm (60.4cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 11264 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: USB Mixer
Memory:
RAM: 32078 Mb
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 217318 Mb
Largest Free Hard Disk Block: 97024 Mb
VR Headset: None detected
Recent Failure Reports:
Sort of a +1 here.... And yes, it's still doing it in May 2019...
There are people who create separate partitions for all sorts of non-Steam things. If someone wants to use a separate disk for /var/spool for some reason, Steam shouldn't be prompting to create libraries there. They probably created that mount structure for a good reason.
Proposal: Steam's "install game" dialog should only prompt to create a new library on filesystems mounted in /home, /mnt or /media. Users wanting to have libraries in other paths should still be free to create them via the settings dialog. Network paths under these should still be ignored as they currently are.
For reference, the standard directory structures and the expected use cases are listed here: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
I didn't look for the logic for this, but for some reason I'm not getting any choices for something like Team Fortress Classic, but do get it for The Witcher 2 for example... Weird.
Anyblue, it's also probably kind of weird to suggest '/' as well, especially when the answer for trying to install there is "New Steam library folder can't be the drive root" (as it should not be, really, though if one wants, it could be... really, but still!).
One may also get partitions such as '/var' and '/tmp' and they are often mounted as 'rw,nodev,noexec,relatime' so those would not work... at all.
Some checks for "can the user write and execute things over there" might be in order before listing them. :]
When you use UEFI, you usually have a separate partition for /boot (/efi) directory. That means that when you install a game, Steam proposes (I mean, displays in "Steam libraries" dropdown) this partition as able to choose it as location to install the game. This is of course wrong, since the partition is usually very small, and you don't want to install games in the place you have bootloader-related stuff, do you? Also, I have one question: is Steam able to install games on FAT32 partitions? If no, then there's one more reason to remove the /boot/efi partition from the list - the EFI partition is actually FAT32 (but, I think, it should be another bug report since it's not really related with UEFI).