Welcome to a larger world. IF you ever need dual boot working well on linux, I found the best robust method is install Windows first, leave space for more partitions. install Linux and make a separate boot efi partition. Many distros offer to probe for foreign OS. this will find windows and add a chainloader entry to grub. Set the Linux partition as the boot one in BIOS/EFI. Grub will start and if you choose Windows it handsover the boot to Windows boot ( and Windows doesn’t know it). Windows will leave your EFi linux boot alone. You can also share a ntfs partition between them if needed
Thats why you have two. windows efi and linux efi on separate partitions. Windows never knows the other one exists and ignores the rest of what it sees as unalloated space. it even lets you shut down a windows update, boot linux and come back to windows later which continues the update. I have been running this way for 7 years, Windows has not touched my other EFi partition.
Should still be fine if you set BIOS/EFI to only boot from the Linux EFI, and it has chainload entry to Windows. If you left it up to some Windows Dual boot thing it will wreck you for sure
You could boot on an USB, mount the filesystem and change the permissions. But if the dude changed a whole lot of permissions, reinstalling might be the smart thing to do…
There’s got to be other tools though that could change the file permissions on chmod, right? Though I suppose you’d need permission to use them and/or download them.
You can dump the permissions from the working system and restore them. Quite useful when working with archives that don’t support those attributes or when you run random stuff from the web 😁
Yeah, a very unfortunate one: probably, the most painful to recover from. I’d just reinstall, honesty 😅 At least with mine I could simply add the necessary stuff from chroot or pacstrap and not spend a metric ton of time tracking all the files with incorrect permissions
@jordanlund@fl42v I think this one could be recoverable if they had a terminal still active by using the dynamic loader to call chmod — or by booting from a liveCD and chmodding from there.
That'd likely get you to a 'working' state quickly, but it'd take forever to get back to a 'sane' state with correct permissions on everything.
This is where someone tracks down an upgrade path chart you didn’t know existed and points out some goofy intermediary release, not an lts for some reason, that you were supposed to upgrade to first…
Linux Mint: removed all taskbars from the desktop. I was hoping it would just allow me to reset them to the default. But in reality, it breaks the GUI and it’s very hard to reset from the GUI. Suddenly my keystrokes weren’t being detected and I couldn’t open up applications with any sort of regularity. After a lot of dicking around, I got the terminal working so I could reset Cinnamon.
It’s not the worst way I’ve broken a machine. But it was one of the most annoying.
One thing I learnt a while back is that if you break your GUI you can always use Ctrl+Alt+F<1-9> to go to different terminals to try to solve it. Worst case scenario I would do something like mv .config .config.bkp and sudo systemctl restart that should hopefully get you back to default settings on the UI.
Source: been there, done that. Not exactly your error but similar enough.
Daaem, I guess the poor dude at the receiving end did not consider it particularly fun. Well, at least they had sbin working, so probably possible to recover without a live cd. Huh, guess who’s now spinning up a VM to check it out 🤣
Checked it out: on arch that results in inability to run tty on reboot, then you’re dropped into initramfs’s rescue shell where you can simply +x new_root’s /usr/bin/* and be back up and running
Before installing Arch on a USB flash drive, I disabled ext4 journaling in order to reduce disk reads and writes, being fully aware of the implications (file corruption after unexpected power loss). I was confident that I would never have to pull the plug or the drive without issuing a normal shutdown first. Unfortunately, there was one possibility I hadn’t considered: sometimes, there’s that one service preventing your PC from turning off, and at that stage there’s no way to kill it (besides waiting for systemd to time out, but I was impatient).
So I pulled the plug. The system booted fine, but was missing some binaries. Unfortunately, I couldn’t use pacman to restore them because some of the files it relied on were also destroyed.
This was not the last time I went through this. Luckily I’ve learned my lesson by now
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.
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 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.
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 :/
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.