linux is terrible because removing the entire root folder can brick your system it should be more like windows where removing system32 can brick your system
I’m a bit bias right now because I tried to install PopOS on a partition last night to see if i could play with it and make a media server. My VPN client failed to install properly, corrupted the OS and when I booted back to the live disk (Rufus made USB) I was able to format the partition but no longer install to it. The boot loader no longer works and it can’t get into any OS now.
I have to say I haven’t had this problem before, but working in IT and installing Windows on over 10 thousand computers in my career, this has happened to none.
(I’ll try another installer likely and format the partition over and see if another bootloader like grub will take and fix the issue).
Edit: changed course and said fuck it… formatted the entire drive and so much for the other data that was there. Clean install maybe the VPN client won’t botch everything this time.
Bootloader no worky can be caused by a hundred different issues. The installer may have removed the kernel or a CPIO archive (initramfs or processor microcode) that the bootloader needs. You could be missing some EFI program. If the boot entry is set to identify the root filesystem by its UUID, formatting/reinstalling would have changed the real UUID and then the bootloader wouldn’t be able to find it. Maybe installing the OS simply wiped or damaged that partition.
If you have to reinstall the OS, you should also reinstall the bootloader (the OS installer usually lets you do that from the GUI), or if you’re confident, update the boot entries to reflect the state of the computer. I strongly recommend using btrfs as your root filesystem instead of ext4, and use Timeshift to set up regular snapshots (btrfs) or backup clones (ext4) in case this happens again.
Darn, wish I would have read this prior to restarting the install after wiping the disk. I would have tried btrfs, it defaulted to ext4 as the machine was using mbr previously and not uefi for the boot, so I Rufus popped up with ext4 recommended and I ran with it
Ext4 is still perfectly fine. It’s a mature technology, and much more stable than btrfs. Your experience will not be any different because of this.
I still recommend using Timeshift. The only downside is that only the Rsync backup method will be available, which creates a full on-disk copy of your system files.
Thanks I’ll try it out once I set up the media server and figure out storage setup. Right now it just has an old 256ssd (sata) for the boot drive, originally was just taking 50gb for that and was going to use old 7200 drives for media storage. I assume I’ll need to have the time shift backups running to one of the other drives or it would be useless if the drive dies.
Yes, it’s best to store them on a separate hard drive. The target partition must be formatted as a Linux filesystem (ext2/3/4 or btrfs) in order to retain file ownership and permissions. I have a 512 GB partition on a hard drive reserved for the last three weekly backups and never ran out of space.
The mention of UEFI in this context likely means they are thinking of a deletion recursing through sysfs and by extension deleting all visible UEFI variables which, in some firmware editions and versions, causes it not to be able to get through post or into the setup menu.
I vaguely recall this and the general issue was very bad firmware design, but it was possible to make it impossible to even reinstall a system. If you were industrious in windows you could have done the same thing, so malware under windows could also brick such platforms.
Of course rm has more safeguards on it so you have to pass more flags and really really be asking it to try to screw things up.
Also the kernel makes those variable immutable by default now, except the well known standard ones, so even for buggy UEFI this is mitigated nowadays. Just pointing out it came from a once legitimate space as a consequence of “everything is a file in a monolithic file namespace”. Which on the one hand is bad if someone uses rm with all sorts of flags to overrule the “you don’t want to do this” protections in the utility. On the other hand what you accidentally managed to do in Linux represented a problem that windows malware could have exploited.
So, I would assume the firmware gave write access to a part of permanent memory, critical to starting the system.
I feel like that would be someone like me, thinking of it as a feature and giving the possible values for those variables in the readme. And of course, who reads the readme even though it says “READ ME”?
UEFI defines a structured way to have data shared with OS as read write variables, including the ability to create, modify, and delete variables that UEFI can see.
However, some firmware used this facility to store values and then their code assumed the variables would always be there. The code would then crash when it goes to read a deleted variable and not know what to do. The thing is deleting those variables per spec is a perfectly valid the due the OS to do, but firmware was buggy and the bugs not caught because normally OS would not bother those variables except for a few standard popular ones, like boot order.
linux is terrible because removing the entire root folder can brick your system it should be more like windows where removing system32 can brick your system
I’m a bit bias right now because I tried to install PopOS on a partition last night to see if i could play with it and make a media server. My VPN client failed to install properly, corrupted the OS and when I booted back to the live disk (Rufus made USB) I was able to format the partition but no longer install to it. The boot loader no longer works and it can’t get into any OS now.
I have to say I haven’t had this problem before, but working in IT and installing Windows on over 10 thousand computers in my career, this has happened to none.
(I’ll try another installer likely and format the partition over and see if another bootloader like grub will take and fix the issue).
Edit: changed course and said fuck it… formatted the entire drive and so much for the other data that was there. Clean install maybe the VPN client won’t botch everything this time.
Bootloader no worky can be caused by a hundred different issues. The installer may have removed the kernel or a CPIO archive (initramfs or processor microcode) that the bootloader needs. You could be missing some EFI program. If the boot entry is set to identify the root filesystem by its UUID, formatting/reinstalling would have changed the real UUID and then the bootloader wouldn’t be able to find it. Maybe installing the OS simply wiped or damaged that partition.
If you have to reinstall the OS, you should also reinstall the bootloader (the OS installer usually lets you do that from the GUI), or if you’re confident, update the boot entries to reflect the state of the computer. I strongly recommend using btrfs as your root filesystem instead of ext4, and use Timeshift to set up regular snapshots (btrfs) or backup clones (ext4) in case this happens again.
Darn, wish I would have read this prior to restarting the install after wiping the disk. I would have tried btrfs, it defaulted to ext4 as the machine was using mbr previously and not uefi for the boot, so I Rufus popped up with ext4 recommended and I ran with it
Ext4 is still perfectly fine. It’s a mature technology, and much more stable than btrfs. Your experience will not be any different because of this.
I still recommend using Timeshift. The only downside is that only the Rsync backup method will be available, which creates a full on-disk copy of your system files.
Thanks I’ll try it out once I set up the media server and figure out storage setup. Right now it just has an old 256ssd (sata) for the boot drive, originally was just taking 50gb for that and was going to use old 7200 drives for media storage. I assume I’ll need to have the time shift backups running to one of the other drives or it would be useless if the drive dies.
Yes, it’s best to store them on a separate hard drive. The target partition must be formatted as a Linux filesystem (ext2/3/4 or btrfs) in order to retain file ownership and permissions. I have a 512 GB partition on a hard drive reserved for the last three weekly backups and never ran out of space.
The mention of UEFI in this context likely means they are thinking of a deletion recursing through sysfs and by extension deleting all visible UEFI variables which, in some firmware editions and versions, causes it not to be able to get through post or into the setup menu.
I vaguely recall this and the general issue was very bad firmware design, but it was possible to make it impossible to even reinstall a system. If you were industrious in windows you could have done the same thing, so malware under windows could also brick such platforms.
Of course rm has more safeguards on it so you have to pass more flags and really really be asking it to try to screw things up.
Like you said, it was just some early implementations of UEFI. I haven’t heard of anything like this happening recently.
Also the kernel makes those variable immutable by default now, except the well known standard ones, so even for buggy UEFI this is mitigated nowadays. Just pointing out it came from a once legitimate space as a consequence of “everything is a file in a monolithic file namespace”. Which on the one hand is bad if someone uses rm with all sorts of flags to overrule the “you don’t want to do this” protections in the utility. On the other hand what you accidentally managed to do in Linux represented a problem that windows malware could have exploited.
More specifically it has done that for the last 8 years :-D
Nice to know.
So, I would assume the firmware gave write access to a part of permanent memory, critical to starting the system.
I feel like that would be someone like me, thinking of it as a feature and giving the possible values for those variables in the readme. And of course, who reads the readme even though it says “READ ME”?
UEFI defines a structured way to have data shared with OS as read write variables, including the ability to create, modify, and delete variables that UEFI can see.
However, some firmware used this facility to store values and then their code assumed the variables would always be there. The code would then crash when it goes to read a deleted variable and not know what to do. The thing is deleting those variables per spec is a perfectly valid the due the OS to do, but firmware was buggy and the bugs not caught because normally OS would not bother those variables except for a few standard popular ones, like boot order.
I see, in that case, that would not be someone like me :P as I tend to care about specifications.
This is a really useful explanation for someone who doesn’t know about the UEFI spec.