Temporary Deleting Partition?

[bester69]

One thing, Ive the grub installed in /dev/sda; deleting sda1 I suppose there's not problem and I suppose once I restore table partition I wont lose grub neither.

I guess you mean that GRUB boot image is installed in the MBR of /dev/sda. But where are GRUB core image and the /boot/grub directory ?
If either is in the partition /dev/sda1, then GRUB won't work when the partition is deleted.
In any case, you won't lose GRUB after the partition table is restored unless you messed with GRUB parts.

ok, Installation is in sda2 so there is boot image. I checked partition table is MSDOS, I think there's no problem with sfdisk, im about to commit ,. lets cross the fingers

[bester69]

This disk is currently in use - it is not advisable to recreate partitions. Unmount all file systems and undo all the sharing partitions on this disk. use the --no-reread indicator to eliminate this check.

Is there much risks by commiting in live session??, I already did it, but i'd like to know for the next one.
sudo sfdisk /dev/sda < sda.ptbl --no-reread

failure to read the partition table again .: device or resource occupied the kernel still uses the old table. the new table will be used at the next restart or after you execute partprobe (8) or kpartx (8).

I executed partprobe to load the new table, and everything seems ok.

[wizard10000]

...This is exactly what sfdisk does, in a format that can be used to restore the original partition layout without the need for any tedious and error-prone manual operation.

You could also do it with dd; the reason I picked fdisk was so OP could understand the process.

No. The filesystem UUID is not stored in the partition table entry but in the partition data area, which is untouched.

Yeah, I got my GPT and MBR mixed up

[bester69]

sfdisk WORKS like a charm!!!

I did it with success, I didnt see mayor risks in using sfdisk in live session, I did many tests, and kernel didnt explode in the way, so my conclusion is THIS IS a GREAT procedure!! I will document it for myself, We can use this workaround to bypass a temporary 4 partitions limitation.

The only care i see we must take, is not to overlap the "deleted partition" with the "temporary new one", So i'd recommend to leave a gap of 1Gb between both adjacent partitions.

As for me, Its a fixed case.

Thanks to all, for your help.

[p.H]

You could also do it with dd

Yes in the specific case of this thread because you only touch the primary partition table which is stored in the MBR.

But not in the general case if you touch a logical partition. Each logical partition entry is in a separate extended partition table stored in a different sector, the first one being the EBR at the beginning of the extended partition. So with dd you would need to save the MBR and all these sectors (after determining their positions, which is not trivial).

We can use this workaround to bypass a temporary 4 partitions limitation.

By the way, may I ask why you need a primary partition and not a logical partition ?

PS : I just remembered that recent fdisk has interactive commands to save/restore the partition layout with the same format as sfdisk.

[bester69]

...
By the way, may I ask why you need a primary partition and not a logical partition ?

PS : I just remembered that recent fdisk has interactive commands to save/restore the partition layout with the same format as sfdisk.

I dont have enought free space in my hard disk, so i have to play with additional partitions, The extended partition is well defined as you can see in the picture, and everytime i wanted to install something I needed to use the extended partition to create a logic one,. Now thanks to your help, i can make use of the windows partition (sda1), to make free temporary space for a testing installation., or i could use free space of sda2 (system installation) to use it for a testing installation as I can delete sda1 for a while and bright it back eventually. Its really great!!, I was missing this workaround for long, ill write it down in my personal How-book.

Thanks, p.H.

[andre@home]

Taking a temporally (cheap) disk would have been a lot more comfortable.
The limits of only 4 partitions is a very known issue, and if you wanna go beyond that limit you need partition manager that can handle that.
Even if you do know that on before that, I would advise not to use that route, as any change of partions is a risk of loosing data.
So whatever you you ... you will need that extra disk anyhow. So the workaround seems a more theoretical and not a very practical route to be advised. I hope you saved all your data from your disk that you wanna change on at least 1 preferably 2 backups disks. Else you're playing with fire... "
and we might have expected a new question from you...: "Help I lost my data while I tried to delete and later recover a partition....
You were lucky..... all went ok...

[bester69]

Taking a temporally (cheap) disk would have been a lot more comfortable.
The limits of only 4 partitions is a very known issue, and if you wanna go beyond that limit you need partition manager that can handle that.
Even if you do know that on before that, I would advise not to use that route, as any change of partions is a risk of loosing data.
So whatever you you ... you will need that extra disk anyhow. So the workaround seems a more theoretical and not a very practical route to be advised. I hope you saved all your data from your disk that you wanna change on at least 1 preferably 2 backups disks. Else you're playing with fire... "
and we might have expected a new question from you...: "Help I lost my data while I tried to delete and later recover a partition....
You were lucky..... all went ok...

Thanks, but I can manage my own risks, i usually like to take them, other way you wont never advantge in kowledges.. I have all that i need in several redundant backups in clouds.
The workaround proposed by P.H. works as a charm and its trustworthy and very easy to apply. It cant failt never, its only a writting the table partition, so unless you overlap data, you cant get yourself in a mess. I proposed to let unless 1Gb of gap to not overlapping data accidentally, this is whole risk.

[pylkko]

Another, not-so-directly-related-to-the-issue question is: why are you not using GPT?

[p.H]

why are you not using GPT?

The current partition table gives the answer to that question : because Windows is installed in BIOS/legacy mode on this drive, which requires MSDOS partitioning.
Using GPT would require to reinstall Windows in EFI mode, assuming the machine is UEFI-capable.

A workaround is to create a "hybrid MBR" combining both an old-style MSDOS partition table for Windows and a new-style GPT partition table for GNU/Linux. I have tested it and it works, but it is an ugly and unreliable hack.

[pylkko]

Okay, I see. I was wondering because I have installed Debian on almost exactly that hardware/BIOS (Acer Extensa) version using GPT without issue. I suppose reinstalling Windows is not the simplest thing either.

[andre@home]

Starting from ~3TB you must use a GPT table, below that you have a choice.

[andre@home]

Thanks, but I can manage my own risks, i usually like to take them, other way you wont never advantge in kowledges.. I have all that i need in several redundant backups in clouds..

OK !

It cant failt never, its only a writting the table partition, so unless you overlap data, you cant get yourself in a mess. I proposed to let unless 1Gb of gap to not overlapping data accidentally, this is whole risk.

Never say never...
And
"It cant failt never"
is a so called "double ignorance"... I believe (I'm not native English).... so it actually means:
it can fail....

[p.H]

Starting from ~3TB you must use a GPT table

Above 2 TiB (~2.2 TB). Not quite near 3 TB.
Also note that a partition table is not mandatory.

below that you have a choice.

Not always.
If you have Windows and BIOS, you must use MSDOS.
If you have Windows and UEFI, you must use GPT.