Hi,
Six years ago I formatted a 4TB HDD, two partitions (/ 50GB; /home [the rest]). It was no easy quest; I had to create manually some tables/auxiliary partitions, etc. I can’t really remember the particulars.
Now I want to reformat the same HDD in a similar way.
Six years is a long time. Is it possible those particulars aren’t relevant any more? Can I just use GParted or KDE Partition Manager without thinking twice? If not, please suggest the recommended way to do the subj.
Short answer: Yes, you can.
Longer answer: There are two types of partition tables in use on the x86-64 platform, namely GPT and MBR (also known as MSDOS). Technically, both are supported whether the machine boots up in legacy BIOS mode or in native UEFI mode, but there are a few caveats…:
Even though the UEFI specification supports booting from an MBR partition table, many UEFI implementations do not. This is why, if your machine boots in native UEFI mode — which is the recommended mode in Manjaro when the machine supports it — it is best to create a GPT partition table.
If the machine boots in legacy BIOS mode but you wish to use a GPT partition table, then you need to create an additional unformatted partition of about 2 to 3 MiB in size of type bios_grub, and mark this partition with the boot flag. This is because the GRUB boot loader would otherwise overwrite the partition boundary of the first partition.
Therefore, the easiest rule of thumb is that if the machine boots in native UEFI mode, then you should use GPT, and if the machine boots in legacy BIOS mode, then you are best off using MBR, which does not require a bios_grub partition.
You mean, UEFI is an alternative to BIOS? I guess I have to use bios_grub partition, since the box definitely got BIOS. Am I correct?
UEFI is the successor to the legacy 16-bit BIOS — UEFI runs in 64-bit long mode, although some older (and rare) UEFI implementations run in 32-bit mode, even if the processor is 64-bit. In contrast, the legacy BIOS runs in the processor’s 8086-compatible real mode, which does not support multitasking and can only access 1088 KiB of RAM.
However, just to add to the confusion, most people today still refer to the UEFI as “the BIOS”. But that is technically incorrect nomenclature.
UEFI has already been around for ages, and all computers manufactured in the last decade have a UEFI instead of a BIOS, although UEFI supports a BIOS emulation mode — which can be disabled — for booting legacy operating systems like for instance MS-DOS or Windows XP.
The Wikipedia articles above explain the difference.
You only need a bios_grub partition if you opt to go with a GPT partition table on a machine that boots in legacy BIOS mode, and if you have multiple physical drives, then you only need it on the drive that GRUB will be installed on. You do not need it on MBR-partitioned drives, nor on data drives that the machine will never boot from.
But I have to use GPT on a 4TB drive, haven’t I?
How can I tell if my box uses UEFI? I suspect I’ve never seen it 
. I even updated BIOS on my box once…
Yes, that is correct.
If your machine was built in the last 10 years, it’ll be a UEFI. One of the tell-tale signs is that if you can use a mouse in the firmware setup utility, then it’s UEFI.
Another indicator is if you have an EFI system partition on your drive. UEFI needs that for storing the boot loaders. This EFI partition is formatted as vfat (FAT32) and is commonly between 256 and 512 MiB in size.
Another way to check is the following command, provided that you are currently booted up in GNU/Linux on that machine… 
[ -d /sys/firmware/efi/efivars ] && echo This system boots in EFI mode.
The system is not bootable right now. All the current partitions, which survived for 6 years are built with my sorry hands.
The good thing: I found the manual shipped with my board MS-7680. It’s BIOS.
On my now unbootable system that bios_grub partition is just 1MiB. Could it be the cause of the death of my system?
No, because technically speaking, 1 MiB should still be enough. I generally advise something a bit larger only for future compatibility reasons, but at present time, 1 MiB is still sufficiently large.
What exactly are the symptoms of that machine?
In theory, it can be HDD crumbling, but the trouble followed a routine kernel upgrade.
Can you be more specific?
Actually, I can’t. Just a kernel upgrade, then GRUB error. Chroot won’t help. Since my root partition turned out to be too small anyway, I’m going to back up my home partition, reformat my HDD, and reinstall.
Do you recall what the error was? Because it could indeed end up being a hardware problem.
I can’t recall, yet I still can [unsuccessfully] reboot the sorry thing. A bit later, probably tomorrow
Thanks for the trouble you take!
It might be a good idea to post the output of inxi -v7azy to give those who help information on your hardware and system.
Attempt at reboot:
file /boot/vmlinuz-... not found
you need to load the kernel first
Chroot (from manjaro-kde USB stick):
$ manjaro-chroot -a
grub-probe: error: cannot find a GRUB drive for /dev/sdb1. Check your device.map
==> Mounting (ManjaroLinux) [/dev/sda3]
--> mount: [/mnt]
--> mount: [/mnt/home]
--> mount: [/mnt/mnt/out]
[manjaro /]# pacman -Ss manjaro
error: failed to initialize alpm library:
(root: /, dbpath: /var/lib/pacman/)
could not find or read directory
When the USB-stick system is running, my HDD /home directory gets mounted without a hitch; the data seems intact. That’s all I can tell.
Is /dev/sdb the 4 TB drive, or is it /dev/sda? 
Find out with:
lsblk
…from the live environment.
/dev/sda is the 4TB HDD
At this point, I would recommend trying to reinstall the system, thereby starting with a fully blank drive and recreating all the required partitions, as was your initial plan. Then you’ll know soon enough whether the problem was caused by a hardware failure or not.
Thanks! To be continued…