Linux

My biggest thing when switching to Linux was understanding why I didn't have permission to alter half of my file structure. I was trying to take ownership of my /usr directory as a user and had to have multiple people explain why that was a bad idea (and why simply making any changes as a super user via terminal was more than adequate for the results I wanted).

My mindset was a result of so many user files being spread across dozens of branches of the Windows file structure. Some very close to the root of the drive, some a few directories deeper. I didn't really understand the benefit of having all my stuff in /home (and am now a full convert. Just thinking about navigating a Windows drive makes my skin crawl now).

chmod'd all my home directory's files and folders recursively. First to 600, which prevented me from listing any folders, then to 700, which broke a few programs, then to 755, which broke ssh.

Mine falls along with the people who were distracted. Was doing two deployments for work on night and on one I need to clear a cache. As I was typing the cd command, I happened to glance at the instructions for the other deployment and for some reason my mind switched to the deployment folder. I then typed out rm -rf *, and as I hit return realized I wasn't in the cache subdir. Blew away our prod environment and it took hours to get it all restored. The restore kept asking the guy to go pull tape #xxx. It was nerve wracking because depending on the tape, there was a chance it was moved offsite. Got it all restored and turned it back on, and then had to start back from the beginning since the backup was from the night before. The other people doing deployments weren't too happy, but I owned up immediately and we ended up changing the procedure. First, the cache clearing was done via a script after that, and I won my argument about not having to do two deployments simultaneously!

The Arch installation tutorial I followed originally advised using LVM to have separate root and user logical volumes. However, after some time my root volume started getting full, so I figured I would take 10GB off of my home volume and add it to the root one. Simple, right?

It turns out that lvreduce --size 10G volgroup0/lv_home doesn't reduce the size by 10GB, it sets the absolute size to 10GB, and since I had way more than 10GB in that volume, it corrupted my entire system.

There was a warning message, but it seems my past years of Windows use still have me trained to reflexively ignore dire warnings, and so I did it anyway.

Since then I have learned enough to know that I really don't do anything with LVM, nor do I see much benefit to separate root/home partitions for desktop Linux use, so I reinstalled my system without LVM the next time around. This is, to date, the first and only time I have irreparably broken my Linux install.

I was setting up fail2ban on an sftp server at work.

Guess who got admin permanently banned from that machine.

Can't remember exactly what happened but it involved changing permissions on /bin /sbin and similar. You know for security ...

In the end I didn't have permissions to run chmod, su or sudo

Fortunately there is little that can't be fixed by booting from a live image.

My buddy was in a class doing a programming test. It was a couple minutes until turn in time, so he went to zip up the source files. He had already ran the appropriate zip command previously, so he pressed up three times and then enter. It appears he had miscalculated, because the command that ran was rm *.c. There were no backups.

Not me but a colleague of mine wrote a bash script that had something like this and ran it on a server:

FOO="/home/bar"

... Many lines later ...

rm -rf $FOOT/*

Reminder that bash will resolve uninitiated variables to the empty string.

Luckily he halted the process after it had only nuked /boot and /bin. If it had gotten to /var and the mounted data storage within, we would have been in trouble

For this very reason, I have aliased rm -rf with trash-cli

I once just uninstalled sudo and replaced it with doas. Turns out, the shutdown process needs sudo and a lot more. So I am still using my system since then, without shutting down.

No joking, I use Fedora Atomic and can not break my system... unless you mess up your dotfiles, and a lot more.

I also put a drive into my /etc/fstab once without the nofail argument.

No idea why that is not set by default, but when removing that drive my system couldnt boot and I exited to a very scary dracut shell.

$ grub-mkconfig -o /boot/grub/grub.conf

Thaaat... took me a stupid amount of time to fix.

I have a story that most of here might have faced. I ran dd on my external drive instead of my usb stick to create an iso. 1.8TB of data poof.

Was trying to get corectrl configured and I was blindly copying text to paste into config files.

Next thing I know, I can't get my system to boot up again. 🤣

Time to reinstall. Again. 😅

I just finished doing a fresh install this morning, because my wifi card wasn't working. It honestly needed to be done anyway because I was out-of date, but the wifi card finally got me to back-up all my data and do it.

Fresh install, and wifi still won't even toggle-on. Was about to look for manual install of the driver, and so on and so forth... and then I noticed my folly

Fucking keyboard has a toggle switch to turn the wifi off. Not the worst and glad I didn't pull my hair out over it, but damn... felt pretty dumb this morning

Force uninstalled glibc on my Gentoo, which basically broke every shell and binary on the system. Was able to repair in place because I

1. Had already compiled busybox statically
2. Still had a copy of the stage 3 tarball on / which I could use to 'restore' glibc libraries

Run sudo apt dist-upgrade -y right after an upgrade to the Kubuntu 24.04 beta on a semi production system.

This is right after the xz thing happened. Also while Ubuntu made the t64 migration (Replaced packages with a 32 time variable with a 64 bit one, the packages are renamed. E.g. lib2geom1.2.0 to lib2geom1.2.0t64)

Packages based on the compromised xz had been removed from the repositories, but I already had some newer ones installed which where dependent on them. Also they already wanted the packages with the t64 addition, which by now where nowhere present in the system.

So dist-upgrade did what it could to upgrade 5 packages and bring the system into a consistent state: It uninstalled half of the system including some somewhat essential packages.

I noticed one of them scrolling by and hit CTRL+C. Afterwards I had the choice of saving the data and restoring from a backup a few weeks ago, or to patch it up by hand. So I did the second and created transitional packages like an empty lib2geom1.2.0t64 which depends on lib2geom1.2.0 which was in the repositories back then. 20 of these later I could install packages to get the GUI somewhat working and now weeks later all the t64 migrations are back in the repos and the system is fully functional again :)

Lessons learned:

• Be very careful with dist-upgrade
• Manually trigger a backup before a release upgrade

In now upgrade with
sudo apt-get update && sudo apt-get upgrade -yV && read -p "Flatpak Update? (yj/n): " choice && [[ $choice = [YyJj] ]] && sudo flatpak update --noninteractive
and equivs-build ( sudo apt install equivs) came in really handy in building the transitional packages fast.

dir="$(something that ultimately resolved to "")"

rm -r $dir/*

on a company server

I also once completely destroyed the data in a db that wasn't backed up for that same company while trying to restore from a dump (which was deleted as part of the script i was running).

Luckily both of these mistakes happened on staging servers so no one really cared. (prod is backed up though so if i did it there, not that i have access to prod, it also wouldn't be catastrophic)

I've deleted my DE a couple of times from not reading the "The following packages will be REMOVED"-list.

There's a lot of gun refference in that school class. Are you by any chance in the US?

Let a narcisist bipolar family member onto my home server for phaseI. For phaseII I granted too much access in sudo because I was busy. Fast forward a year or two and a downswing triggers the victim rage and he attempts to wreck my server after a minor argument -- would have, too, if I wasn't keenly aware of a conversation he had a few weeks before where he detailed "how to fuck with someone horribly" to a peer and I used that recollection to reverse the damage. It was a lucky thing, and 25 years on I have better security and backup processes.

I still regret that. #family, right?

Once I omitted a semicolon after an “rm -rf”and the next command. The script was supposed to reduce downtime vs typing the commands manually, but instead it deleted the production site and the “.bak” backup of the site instantly.

Typed "rm -r" in "/home/myuser" instead of "/home/myuser/Documents/ThingINoLongerNeed"

Used gparted to wipe and format the device mounted at "/" instead of the external drive I meant to reformat. I've done this one TWO WHOLE TIMES in my life, three if you count wiping a device that was mounted at "/home/myuser/MyTwoTBDrive4DocsPicsMusicGamesEtc".

• Accidentally did a partial upgrade of Arch Linux in which I upgraded libssl but not systemd (which depended on it) (which refused to start becuase one of its dependencies had been upgraded to an incompatible version) (which caused the kernel to panic immediately on bootup because the init process died) (writing init=bash on the kernel command line gave me a shell but not network access) (i had to boot off a liveusb, chroot into my /, and run pacman -Syu from there in order to fix it)
• Use Ubuntu, at all, for anything, ever

1. Have Nvidia card
2. Change the driver to see if I can fix a weird graphical issue I was having.
3. Rebooted computer and got stuck in boot loop because there was an error with the driver.

I once spent a month automating the production of repositories for each kernel version supported on our HPC and rested every step exhaustively in isolation.

When I was satisfied I ran it with root permissions and hosed the VMs it was running on because a recursive chmod evaluated to /.

Oops.