This is modestly different in that the package manager actually accepted the task and went to install what should have been a replacement automatically. A person could even reasonably argue that this is evidence there's a missing dependency somewhere; nominally, I'm pretty sure debian still supports sysv enough that you're supposed to be able to use it, and apt is supposed to handle dependencies enough that switching should work, it's just a really low-priority / undermaintained path.
I moved IO.SYS, MSDOS.SYS and COMMAND.COM into the DOS folder to tidy things up a bit. Then I had to wait until someone could lend me a bootable floppy.
Cattle not pets. Carve a new partition with gparted, install new OS, mount the old partition and copy over any valuable data. (Hopefully you have this backed up anyway)
This works when you have automated setup of the services, configuration, etc. I can't speak for you, but my home machines don't have the same love and care for that step as parts of my kubernetes cluster.
I hope the answer the interviewer expects is "Did your current guy do that? Is that why you're interviewing? Was it you?"
I've been a unix and linux jackofall since '96 or so, and I could not answer that question better than "probably a big mess"
Though it would certainly not be points against if they did happen to say "I tried that once just to see". That is good curiosity and tinkering, but I never happened to try it once just to see myself.
I guess it could be a valid question just to see if the response shows some flavor of shock and alarm. IE everyone is expected to say "I don't know" but if the response is blank as though the question were not remarkable, that's not encouraging.
I guess my answer would be "Holy sh... we don't have time for this, take me to the machine right now." haha Or just "I dunno but I'll clean it up."
As /u/theamk said, this is analogous to deleting windows32… at some point, if you do stuff like that, without knowing what you are doing, you have to take responsibility for borking your system.
This is not analogous to deleting windows32. The original poster didn't go around deleting random files on their hard drive - they used a known interface, apt/dpkg, in the manner it was meant to be used, further evidenced by the fact that the fix basically boiled down to running more apt commands (and getting wired internet, which you'd have to do if you used apt to remove wireless configuration tools). It's entirely reasonable to ask for a "rollback" feature in this case.
Since the NT days, Windows uses the system attribute on most things in that directory, which prevents delete from working unless forced. You'd think apt would scream bloody murder about dependencies, but apparently not.
Hard disagree. The op went out of their way to remove an essential package without any knowledge about it, or about Linux as a whole for that matter, of course something ends up breaking! Not everything can be optimized for stupidity (with no offense intended, we all do stupid stuff and learn the hard way to not do stupid stuff, that doesn’t necessarily mean we are stupid)
What would this magical "apt rollback" do anyway? Rollback to what state? Should it rollback the auto remove and the remove? Or just the auto remove since it’s the last command?
I accidentally deleted su once. Not directly; I was cleaning up a botched upgrade and uninstalled linux-utils. Sudo was still there but couldn't do anything useful. This was on a qnap NAS device so eventually I used an arduino as a USB-to-serial-to-JTAG to manipulate the boot parameters, boot into single user mode, and edit the sudoers file.
In college, many aeons ago, I bought a used Sun workstation (mainly for the copy of FrameMaker on the machine). At some point I was trying to clean up the root filesystem and deleted the root shell (I can't remember the details but I think there were two shells, one used to boot the system, and one for the user shell).
That's how I learned that SunOS machines at the time had an extensive set of features for booting the machine (like, a built in EFI shell) and providing kernel params, so I was able to finally boot into the machine by telling the kernel to launch the user shell, which was enough to boot the machine to user space. The SunOS machines also could do pretty much everything over serial- including installing an entire OS.
I updated my arch installation once, but an incompatible version of glibc was installed. Unfortunately, pacman, which you use for all packages, links itself to glibc and refused to run. Directly attempting to replace the glibc binaries caused a kernel panic. I had to reboot and chroot from a recovery disk to my installation and upgrade/repair glibc and pacman there.
You can do that if you had the forethought to edit your /etc/securetty file before nuking su, to allow root logins on the ptys used by sshd. If not, logging in on a physical console would work or rebooting to single either mode or whatever.
Because it's security escape hatch. It's not needed. Suid programs caused many vulnerabilities. There must not be a way to get more privileges, only less.
Came out of the cave expecting a critical jest and call to action "Delete systemd" the sprawling Linux overseer that flouts the Unix philosophy, with a host of arguments supporting why it's ripe for replacement in the name of simplicity.
