PDA

View Full Version : Uninstalling a linux system



lsatenstein
27th November 2017, 11:35 PM
When a linux system is uninstalled, what I typically do is delete the biosboot, /, swap and /home.
However, the master boot record (mbr) still points to a non existent biosboot partition.
is there a way or is it necessary to zero out or reset the mbr? I do not want to destroy the other partitions on the terrabyte drive.

Kobuck
28th November 2017, 02:01 AM
When you delete "biosboot" and "/" you've rendered the disk non-bootable right?
So even though the "MBR" would try to transfer to the biosboot code, as long as you don't point to the disk as your "boot" disk it will not try to execute the boot code.
The partition table will still be valid( even though /, /home, and swap are zeroed out.) and any other partitions will still be accessible. The same will be true if its a GPT disk.
The only issue I see is that it will TRY to boot if you point to it as a boot drive.

Am I missing something??

srakitnican
28th November 2017, 08:48 AM
With dd!
First 446 bytes seems to be the boot loader data. So something like the following should erase it. Make a backup of MBR first with the same command in case this is wrong.


sudo dd if=/dev/zero of=/dev/sdX bs=446 count=1

Longer explanation: https://unix.stackexchange.com/a/71390

antikythera
28th November 2017, 09:05 AM
MBR drives don't need /biosboot. that is GPT specific for systems with using BIOS instead of EFI firmware. please don't confuse a GUID partition table (GPT) with a master boot record (MBR). you can have one or the other on a drive, not both.

amiga
28th November 2017, 10:00 AM
MBR drives don't need /biosboot. that is GPT specific for systems with using BIOS instead of EFI firmware. please don't confuse a GUID partition table (GPT) with a master boot record (MBR). you can have one or the other on a drive, not both.

This is quite wrong and somewhat shocking. All GPT formatted drives have a protective MBR which marks the entire disk as used to pre-GPT formatting tools to prevent accidental erasure. In BIOS/GPT booting the first 446 bytes of this protective MBR can be used to point to the second stage of a bootloader such as the grub2 core.img contained in a 1 MiB biosboot partition. I use GPT partitioning and BIOS/GPT booting.

Every GPT formatted disk has a protective MBR. It is part of the GUID Partition Table standard. After the protective 512 B MBR is the actual GPT partition table. You are apparently confusing the existence of an MBR (which both MBR and GPT disks have to a different degree) with actual MBR disk formatting. The OP is using GPT formatted disks with biosboot partitions to store the grub2 second stage and performing BIOS/GPT booting.

https://en.wikipedia.org/wiki/GUID_Partition_Table#Protective_MBR_.28LBA_0.29

https://en.wikipedia.org/wiki/BIOS_boot_partition

antikythera
28th November 2017, 12:09 PM
I'm well aware of the configuration leslie uses at present and I'm not making any shocking mistakes here. the protective MBR doesn't contain any boot partition information the system uses. the protective MBR is not an actual partition table or layout in it's own right as referred to in GParted when setting up a drive. You have two partition table choices, ms-dos (MBR) or GPT.

IN GUID layout the protected MBR component is for want of a better term a compatibility shim within the GPT layout data designed to make the drive appear full to old partitioning tools preventing accidental erasing of partitions due to it being identified as empty, is only there to instruct legacy BIOS machines the drive is GPT layout. it doesn't serve any other purpose, is not a separate entity in it's own right and certainly does not contain any details about the location of any partition or their file system type which is the information leslie is concerned about losing.

fact is, leslie is about to upgrade his system completely. if he uses EFI mode, /biosboot isn't necessary as I stated.

bobx001
28th November 2017, 09:51 PM
my $0.02

since using GPT drives, and being "semi-hinted" (forced?) by linux to create a /boot/efi partition, I have mistakenly done so, and given them too little space (say 300Mb), that has caused on several of my machines here at home the annoying situation of failing any yum upgrade with a "you need to free up space for the kernel". Which made me have to erase the older kernel (yum remove kernel-n.old.n.n*). Annoying to say the least.

I have now gone back to my old practice of swap=2x ram , / = 50GB , rest is unformatted (mount it later as /home), I encrypt it always later (important to **not** use luks from the getgo, as there is no plausible deniability and you're always prompted to give the PW at boot, jail time at the next airport if you don't provide it), usually using the old truecrypt.

lsatenstein
30th November 2017, 03:17 AM
May I clarify my situation

I was trying to address my multi-disk environment. Before... /dev/sda... /dev/sdf had 5 linux distributions, all Fedora (test partitions as std-ext4, btrfs, std-xfs, lvm file systems, with Gnome, xfce and KDE mixes) and what happened when I removed one of one sandwiched Fedora installation.

When I cleaned out, /dev/sdc (a disk that had a Fedora linux sandwiched between /dev/sdb and /dev/sdd, I ran into a problem. I normally boot from the /dev/sde, the most recent SSD disk that I added 18 months ago.

When I deleted that sandwiched linux, the grub for /dev/sde Fedora only showed the sde Fedora itself, instead of showing itself and the other Linux setups, one on each of the remaining drives.

Restoring /dev/sdd with a placeholder Fedora 27, repaired grub for the SSD on /dev/sde. It shows all installed distributions.

My question was really asking what do I have to do after I remove a Fedora install that is situated between two other disks having Fedora on them? As noted, I like to make a clear partition by deleting the BiosBoot, /, /home and swap. I do not want to zero the disk and rebuild the GPT. I want to protect the other used partitions on the same /dev/sdd.

Some experiments I tried for recovery
For each installed partition, I ran grub2-install /dev/sdx (x is one of and c,e), followed by
grub2-mkconfig /boot/grub2/grub.cfg.

It did not work. Problem persisted until I added to /dev/sdd a Fedora 27 place holder. I think I could have used any older 20-26 Fedora distribution.

My current grub.cfg is attached as grub.cfg.txt if you want to review it.

bobx001
30th November 2017, 08:21 AM
my $0.04:

frankie, look into this: " TCSunBow M-SATAII Internal Solid State Drive Speed Upgrade kit for Desktop PCs MacPro (M1 32GB) "
just saw it on klamazon. I would have say 5 of these, each with a different distro. At 30 bux each. pffff. 32GB is good enough for any distro, you can share swaps in a real SSD somewhere else. Maybe you can but the boot thingy in the SSD which has the swap partition.
/home always in an encrypted large multi-terabyte thing somewhere else of course.
I will get 2 of these now, and start playing with them, and post some results.

HaydnH
30th November 2017, 12:52 PM
[B]May I clarify my situation


This doesn't sounds like a grub issue to me, grub would use the UUID these days to figure out which disk is which, see this device map section for background info:

https://www.gnu.org/software/grub/manual/grub/grub.html#Device-map

To me this sounds like your BIOS is finding the wrong partition to look for the boot loader after the delete, are you sure it's not finding what was /dev/sdf before the delete? You say you tried to install grub to /dev/sd{c,e} - if it was on /dev/sde before the delete, wouldn't you want to install it to /dev/sdd (e minus 1) afterwards?

lsatenstein
30th November 2017, 05:34 PM
HaydnH, As I stated for each disk/iso, I ran it's own grub2-install, followed by grub2-mkconfig. This is the first time in 5 years of multiboot that I encountered this problem. Since it works properly for all the other systems, I just solved the problem by doing an install from backup. All is well that does not end in hell.

amiga
30th November 2017, 09:44 PM
I'm well aware of the configuration leslie uses at present and I'm not making any shocking mistakes here. the protective MBR doesn't contain any boot partition information the system uses. the protective MBR is not an actual partition table or layout in it's own right as referred to in GParted when setting up a drive. You have two partition table choices, ms-dos (MBR) or GPT.


I don't need you to explain this to me as I was giving links to pages to try to explain this to you. However your understanding is incorrect as in a BIOS/GPT boot the first 446 bytes of this protective MBR is used to point to the second stage of a bootloader with C/H/S instructions just as it would with a BIOS/MBR boot. With Grub2 the second stage core.img is placed in a biosboot partition as there is no "MBR gap" between the MBR in an MBR formatted disk and the first partition.


doesn't contain any boot partition information the system uses

Legacy BIOS firmware doesn't understand any partition scheme either MBR or GPT. The first stage in the 446 bytes uses cylinder/head/sector addresses to point to a bootloader's second stage. So a legacy BIOS doesn't use any boot partition information.


In GUID layout the protected MBR component is for want of a better term a compatibility shim within the GPT layout data designed to make the drive appear full to old partitioning tools preventing accidental erasing of partitions due to it being identified as empty,

Again this was what I was trying to explain to you


is only there to instruct legacy BIOS machines the drive is GPT layout.

Actually legacy BIOS machines can't tell the difference between MBR and GPT layout as they don't understand any partitioning format.


it doesn't serve any other purpose, is not a separate entity in it's own right and certainly does not contain any details about the location of any partition or their file system type which is the information leslie is concerned about losing.

Again the first 446 bytes of this protective MBR still points to the second stage of a bootloader with C/H/S instructions as it would with a traditional BIOS/MBR boot. This is what makes BIOS/GPT booting possible. Legacy BIOS can't tell the difference between MBR and GPT partitioning. It also can't understand any file system at all. Only the bootloader second stage can understand file systems. With Grub2 the only difference is that with BIOS/GPT setups the second stage core.img is inside a biosboot partition as there is no "MBR gap" with GPT disks.

When you type grub2-install /dev/sda on a GPT format disk it places the first stage in the first 446 bytes of the protective MBR which points to the second stage core.img inside the biosboot partition.

The second Wikipedia page I linked has a nice diagram showing this in detail and compares BIOS/GPT with BIOS/MBR. Have a look.

https://en.wikipedia.org/wiki/BIOS_boot_partition

srakitnican already explained how to zero this pointer


Re: Uninstalling a linux system
With dd!
First 446 bytes seems to be the boot loader data. So something like the following should erase it. Make a backup of MBR first with the same command in case this is wrong.


sudo dd if=/dev/zero of=/dev/sdX bs=446 count=1



fact is, leslie is about to upgrade his system completely. if he uses EFI mode, /biosboot isn't necessary as I stated.

Where in this thread is this stated ?

lsatenstein
2nd December 2017, 01:15 AM
Maybe I am a half amateur linux user, and semi-competent linux expert, so, for every rpm or file I install into my Fedora distribution, that I want to keep, I have a script into which I register that rpm name. I can reinstall Fedora and run that reinstallation script. An example of that script is available in the list of my tag line. I always use a network install of Fedora, and thereafter the reboot, my script.

I typically wait to end-of-day to do a reinstall of Fedora, and follow up with my reinstall script. I do this as a fast lazy way to solve problems. True, I do not drill down into logic bug, I just solve my issues.

Kobuck
2nd December 2017, 05:29 AM
However your understanding is incorrect as in a BIOS/GPT boot the first 446 bytes of this protective MBR is used to point to the second stage of a bootloader with C/H/S instructions just as it would with a BIOS/MBR boot.

@amiga you are only partially correct. You are correct that there is still boot code in a GPT Protective MBR. However, modern versions of the MBR boot code will check for INT 13 extensions and use LBA disk addressing if available. This is true whether MBR or Protective MBR(GPT) sector 0 has been implemented.

Also a GPT disk still has an MBR Gap (AKA Post-MBR Gap), its just in a different place. Located at sectors 34-2047 in default partition layout. I use this space to define my BIOS Boot partition. As you said GRUB uses this partition to write the "core.img" boot code ( currently sized at ~28K )