Hello,
Couple of days before, I got new computer with SSD. I want to format it, make partitions (I already did it, but if I made wrong it is no problem for me to do it again), but I see some partitions I don’t know if they have to be formatted (must I format this “efi system partition”). Exactly it is ‘/dev/sda1’ partition. This is list of partition:
/dev/sda1 2048 1026047 1024000 500M EFI System
/dev/sda2 1026048 43134975 42108928 20.1G Linux swap
/dev/sda3 43134976 168964095 125829120 60G Linux filesystem
/dev/sda4 168964096 468862094 299897999 143G Linux filesystem
I made partitions the way I first deleted old (swap and sd2) and then made partitions one by one. All but efi… I did not touch it. Just mounted it, because system said thet it probably would’t work if there was not that partition
Well all I can say is that whenever I install I always format the efi and root partitions, I normally do not format the home partition but if I am installing a new distro I would set up a new home and format it and then copy over the stuff I need from the old home once the install is finished. I have my efi, root and swap all on an SSD now.
I have to say that I asked this question because I thought that device could “get stupid” if formated (lose producer-insstalled software if it has any). Would it? Yes, I risk that my last sentence become stupid.
The main risk of formatting the EFI partition, is that you break Windows. But it looks as if you don’t have Windows installed, so that isn’t a real problem.
The reason why, the EFI partition is formatted as “VFAT” – FAT with long file names – is because the UEFI specification demands that, it shall be so …
Anything else will result in the Mainboard’s UEFI/BIOS not being able to read the disk’s boot information …
And, the current generation of Mainboards are more than a little picky about the disk’s boot area …
And a “clean” openSUSE/SUSE installation on a new, blank, disk will create a 500 MB EFI partition formatted as VFAT …
[HR][/HR]Yes, yes, VFAT is Microsoft but, in this case Microsoft is not the reason why the EFI partition is formatted as VFAT – despite SUSE/openSUSE using a Microsoft service to sign the UEFI Secure Boot certificate … >:)
If you don’t need the contents scrap the partitions. Run a security erase.
“This procedure describes how to use the hdparm command to issue a Secure Erase ATA instruction to a target storage device. When a Secure Erase is issued against a SSD drive all its cells will be marked as empty, restoring it to factory default write performance”
I am still wondering what you are after. You are just partitioning the disk and creating file systems on the partitions? what is that for?
As @dcurtisfra says, the openSUSE installer is very able to create an EFI partition and creating the correct file system upon it. It is also very able to suggest you a partitioning (including the creation of file systems) during installation. It will do so on the free, that is unpartitioned, space of the disk. Thus when you already partition the disk, there will be less (or even no) free space for the installer to use.
You can then alter the suggestion of the installer to your wish (larger/smaller/less/more file systems). And after that the installer will partition, create file systems, create /etc/fstab as wanted.
Thus I wonder why you are already partitioning, etc. if you indeed only want to install a fresh openSUSE, during which install the installer will do all that for you (and you can only hinder the installer in it’s good work by already occupying part ot whole of the disk).
If you allow the openSUSE installation to install on the complete SSD, all necessary partitions will be created on the SSD and, any existing partitions will be overwritten …
Yes, with fairly uncommon tools, if the SSD were to be stolen by the “opposition”, they could, maybe, retrieve whatever was previously on the SSD – maybe …
But, for all practical purposes, simply letting the installation use the entire SSD for the “new” partitions is sufficient for most purposes – yes, there are people where this is not sufficient but, they’re few and far between …
And, after time, whatever was on the SSD before, will be repeatedly overwritten anyway …
FAT vs. VFAT. Most of the time, when people talk of “FAT”, they mean VFAT (support for long file names).
Looking at my installed EFI systems, most use file names that fit the 8.3 requirement for non-vfat. But there is one that has a long name. Using systemd-boot, the efi binary is named “systemd-bootx64.efi” which requires VFAT.
The EFI specification does require support for FAT16 as well as FAT32. I think it also requires support for FAT12, though I never tried that. So the firmware likely supports these for removable drives. For the internal hard drive, it does say FAT32. However, since the FAT16 support is supposed to be there, most firmware will allow it.
I have participated in perhaps 100 or more threads on this forum that were related to EFI booting. I have seen only one case where a system would not boot with a FAT16 EFI partition, and the fix was to reformat that as FAT32. So it seems rare that firmware would only work with FAT32. Still, best practice is to use FAT32 for the EFI partition on your internal drive.
I am afraid of language misunderstanding. So: I got new computer with ssd instead of hdd. I wanted to partitioning ssd, and system suggested to me 1 swap and 1 native partition and also one called “uefi”. I did not know what to do with that uefi prtition and left it untouched. My question for this topic is woult it be some damage on ssd as device that saves some data, if I partitioned it?
**
Before I started this topic I partitioned ssd and left efi partition untouched, waiting for you to tell me is it dangerous in any way to format it (as I said - maybe it saves some datas that can not be restored). Now I have partitioned ssd with partitions created by the rules of partitioning (native, root, home partition), and uefi partition is still present.
The only question I asked was: may that partition be formated?
In case of clean install: during installation set EFI system partition first in order and format it as FAT32 + VFAT for compatibility with Windows and openSUSE.
Windows requires > 100 MB EFI system partition.
Nowadays we need to set its size with openSUSE installer > 512 MB to get FAT32 instead of FAT16.
You may format it manually to get FAT32 + VFAT with size < 512 MB before starting openSUSE installer.
Installing openSUSE as second/third/etc. OS on the same drive: do not modify EFI system partition. Leave it untouched.
You seem to be installing openSUSE by itself on a brand new SSD.
For this scenario, the easiest option that’s mistake-free is to start with removing <all> partitions from your SSD so that the entire disk is free, unpartitioned and unformatted space and then run the Install.
The openSUSE installation will see all that space and do everything that’s necessary based on a proposed layout which you can modify if you like…
But, I’d suggest not modifying the layout at all without special reason.
Hoping not to confuse you,
The layout the openSUSE installation will propose to you
Much smaller UEFI partition, typically doesn’t have to be the size you are suggesting
Different partition order, SWAP is now the last partition. Won’t make any difference on an SSD, but would on rotating rust.
I assume you’re defining two separate Linux partitions to separate the root partition from User “home” data. Although the default proposed openSUSE install layout can be modified for a separate “home” partition, the current 15.2 default layout does not do this… Instead, BTRFS is your file system, the entire disk is a single BTRFS volume and your “home” is configured as a BTRFS subvolume to separate it from root.
If you’re not in a hurry,
I’d encourage you to plan on a couple installs, your first install can be “experimental” where you can feel free to explore whatever you’d like.
As someone new to installing openSUSE, you may find my presentation slidedeck on openSUSE helpful, it includes screenshots of the installation
Meaning, “May the EFI partition be reformatted to use another file system?”
A general answer is no – the UEFI specification obliges
that the EFI partition shall be FAT32 with VFAT to allow long file names … ] – and, there is a suspicion that, Mainboard manufacturers will tend to comply with this obligation …
A specific answer is, maybe …
There may well be be some Mainboard manufacturers who have chosen to not comply with the UEFI specification’s obligation and, will support file systems other than FAT32 in the EFI partition …
But, one needs to determine which Mainboard manufacturers have chosen to take this course …
If you want to use another file system in the EFI partition, 1st contact your Mainboard’s manufacturer to determine if this is supported or not …
[HR][/HR]Bottom line:
The only danger
which may occur if the EFI partition is not formatted with a FAT32 file system, is that the system will not boot – you’ll have to reinstall and overwrite at least the EFI partition, to recover from the situation …
The EFI firmware must support the FAT32, FAT16, and FAT12 variants of the EFI file system. What variant of EFI FAT to use is defined by the size of the media. The rules defining the relationship between media size and FAT variants is defined in the specification for the EFI file system.
Conforming firmware is required to support the above variants. It’s up to the user to determine which of the variants are actually implemented by the vendors of their hardware/firmware and which of these are supported by their operating systems.
One of my systems has 100MB FAT16 and I am doing well since 2014. No problem encountered with dozens of installs since then.
The UEFI Specification version 2.8B dated May 2020 and released June 2020 hasn’t been changed in this area – same as the version 2.5 released in April 2015:
EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OS Type value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.
In other words, for a non-removable system disk – FAT32 …
Also, note the “support for long file names” – in other words: VFAT …