This one took a stupid amount of time to debug - but on the other hand, when grub failed it did with “can’t find any bootable thingy” and not “missing configuration file” as, in my later opinion, it should.
One that I can remember many years ago, classic trying to do something on a flash drive and dd my main hdd instead.
Funny thing, since this was a 5400rpm and noticed relatively quick (say 1-2 minutes), I could ctrl-c the dd, make a backup of most of my personal files (being very careful not to reboot) and after that I could safely reformat and reinstall.
To this day it amazes me how linux managed to not crash with a half broken root file system (I mean, sure, things were crashing right and left, but given the situation, having enough to back up most things was like magic)
Many years ago I was dual booting Linux and Windows XP. I was having issues with the Linux install, and decided to just reinstall. It wasn’t giving me the option to reinstall fresh, only to modify the existing install.
So I had the bright idea to just rm -rf /
Surely it’ll let me do a fresh Linux install then.
Immediately after hitting enter I realized that my Windows partitions would be mounted. I did clearly the only sensible thing and pulled the plug.
I think I recovered all of my files. Kind of. I only lost all the file paths and file names. There was plenty to recover if I just sorted though 00000000.file, 00000001.file, 00000002.file, etc. Was 00000004.file going to be a Word document or a binary from system32 directory? Your guess is as good as mine!
which is why I like to add a set -u at the begining of a script.
The second one is not with a Linux box but a mainframe running AIX:
If on Linux killall java kills all java processes, on AIX it just ignore the arguments and kill all processes that the user can kill. Adios the CICS region 😬 (on the test env. thankfully)
On a real UNIX (not only AiX) killall is part of the shutdown process - it gets called by init at that stage when you want to kill everything left before reboot/shutdown.
Linux is pretty unique in using that for something else.
killall typically sends SIGTERM by default. It accepts a single argument, the signal to send - so shutdown would call it once with SIGTERM, then with SIGKILL. killall is not meant to to be called interactively - which worked fine, until people who had their first contact with UNIX like systems on Linux started getting access to traditional UNIX systems.
It used to be common to discourage new Linux users from using killall interactively for exactly that reason. Just checked, there’s even a warning about that in the killall manpage on Linux.
First time trying Linux I went with an arch install because I Googled “best version of Linux” and went with arch. Followed a guide to the point of drive formatting and I decided to go with a setup with drive encryption. I didn’t understand what I was doing, ended up locking myself out of my hard drives and couldn’t get windows to reinstall on them. I used a MacBook for a week until I installed Ubuntu and managed to wipe and reset my drives and reinstalled. Needless to say I am going to read up a little more before I try that again.
Archinstall python script is your friend 😄😉 I tried install arch manually, but as I learned that not even sudo is included in the Linux essential packages, I stopped the process and went back to aromatic script install, lol, got no time for that S*** 😂
I once deleted the network system in alpine. I’d been having some trouble with with the default one (I think wpa_supplicant) so I decided to try the other one (I think iwctl). But I thought that there might be problems with havung both of them so before I installed iwctl I deleted wpa_supplicant (thinking that it was more of a config utility than the whole network system), only to find that I couldn’t connect to the internet to install iwctl.
I have a stupid one, but far from funny… I’ve been using and building computers for a very long time so I’m far from a noob, but I’m still quite cautious, bordering on paranoid, so I like to unplug all other drives when re/installing an OS just to avoid stupid mistakes. I go through the installer on the livecd, there’s only one drive to choose from so I don’t think much about it, select that it should erase everything, I set up the new partition structure, and start the process. After about a minute I begin wondering “why is it taking so long?”, and “what is that ticking noise? SSDs shouldn’t be making any sounds when written to”, when I realize that I had unplugged the wrong drives and that I was currently overwriting my main storage drive. Of course I had backups of the most important things like photos and code, though not really synced for a couple of months so I lost some stuff permanently.
I’m in the process of switching my main server over from windows to Linux
I went with Deb 12 and it all works smoothly but I don’t have enough room to back up data to change the drive formats so they’re still NTFS. I was looking at my main media HDD and thought “oh, I’ll at least delete those windows partitions and leave the main partition intact.”
I found out the hard way that NTFS partitions can’t just reclaim space like that. It shuffles all the data when you change the partition. It’s currently 23 hours into the job and it’s 33% done.
I did this to reclaim 30 MB of space on a 14 TB drive.
You mean you’ve removed the service partitions used by windows and grown the main one into the freed space? Than yes, it’s not the way. 'Cause creating a new partition instead of growing the existing one shouldn’t have touched the latter at all :/
I didnt break anything, but there was this one time i was setting up a new lxc container i had just spun up. I installed nginx, and a bunch of other packages, started writing new config files… Then i noticed my prompt was user@desktop$ instead of user@server$
Whoops… I was in the wrong terminal window, typing commands into my desktop instead of the container i was setting up.
Oh, I just remembered another one or three. So, resizing the partitions. My install at the time had a swap partition that I didn’t need anymore. Should be simple, right? Remove the partition and the corresponding fstab entry, resize root, profit. Well, the superblock disagreed. Fortunately, I was lucky enough to be able to re-create the scheme as it was, and then take my time to read the wiki and do the procedure properly (e2fsck, resize2fs and all that stuff).
Some people I’ve met since, unfortunately, weren’t so lucky (as far as I remember, both tried to shrink and were past mkfs already) and had to reinstall. The moral is, one does simply mess with superblocks; read the wiki first!
I wanted to use fio to benchmark my root drive. I had seen a tutorial saying that the file= parameter should point to the device file, so I pointed it at /dev/sda. As you might expect, the write test didn’t go so well.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.