chronicledmonocle

@chronicledmonocle@lemmy.world

This profile is from a federated server and may be incomplete. Browse more on the original instance.

chronicledmonocle,

I’m just waiting for Valve to support their new Quest SteamVR app with Linux hosts. Once they do I can destroy my Windows 256gb install with impunity.

chronicledmonocle,

An engineer at Valve said they’re working on Linux support for it, so it’s definitely something they’ve got their eye on.

chronicledmonocle,

12 yr old me: My username will be StrokeMyMagnum

18 yr old me: That’s still a badass username

chronicledmonocle, (edited )

That right there is the most important engineer in Starfleet.

chronicledmonocle, (edited )

So when I was more of a newb, I had a media server that I had a storage drive mounted in fstab using the /dev/ path, rather than the UUID. I had my main boot drive mounted as / and my storage drive mounted to /mnt/storage. The root drive was /dev/sda and the storage drive was /dev/sdb.

So this was stupid, but not nearly as stupid as what I did as a hack to work around a problem I had. Transmission Daemon would set the ownership of files to the user “transmission-daemon”, rather than my user account, so when I accessed files I downloaded via torrent over SMB. I was constantly having to chown the files to myself as sudo to fix them via SSH before I could manipulate them via SMB. There is a setting in transmission to change the UID/GID that it uses by default in the JSON configuration file, but I screwed with it for about an hour, couldn’t get it working, got annoyed, and gave up. I got so frustrated I just made a cron task that ran /5 minutes to chown the directory to nobody:nobody and chmod recursively to 777 permissions. When I moved the files after download they’d change to my user permissions when cut and pasting, so it was good enough for me until I could revisit it another day (which I never did until I reaped the consequences of my actions).

So here is how it broke: One day I needed to rewire my server to make room for additional storage. I accidentally, it seems, swapped the SATA cables for my boot and storage drive, which resulted in /dev/sda and /dev/sdb swapping places so that sdb was my boot drive and sda was my storage drive. My fstab then mounted /dev/sdb, my boot drive, to /mnt/storage, which was basically recursive infinitely. / was /dev/sdb, but if you went to /mnt/storage, you would then go /mnt/storage/mnt/storage/mnt/storage…and so on. And then the fireworks happened. My crontab script kicked off and since it was “chown -R nobody:nobody /mnt/storage/" and "chmod -R 777 /mnt/storage/” it immediately re-wrote all of the permissions of my root partition to have nobody as the owner and group permissions with all read/write permissions allowed. This broke…basically everything. And it was ext4, not ZFS or something, so I couldn’t roll back to a snapshot or anything. I spent 2 hours trying to fix permissions one directory at a time until I just gave up, reinstalled, and set things back up again from scratch. Since it didn’t touch my storage drive and I had an rsync backup to a second drive, I just eventually figured it was faster to fix my operating system/software by reinstalling and then re-mounting the drives.

I learned/was reminded of two things that day:

  1. Always use UUIDs for fstab mounts
  2. Don’t write stupid, hack scripts to work around a problem you’re running into that you leave for 2 years because you’re a lazy SOB.
  • All
  • Subscribed
  • Moderated
  • Favorites
  • localhost
  • All magazines
  • Loading…
    Loading the web debug toolbar…
    Attempt #