On 2 disks I have found my existing partition table corrupted after installing Elive (next to Ubuntu) on them. Apparently “gparted” does not play nice with GPT and the “fdisk” utility in Elive cannot handle it either. Installing “gdisk” later on is a solution there but I’m wondering if the installer might be to blame.
I always create a large “/home” and about 20G “/” partitions manually, when I install. Maybe it’s time to start getting used to LVM. 
Anybody any thoughts there?
This is a very important bug, can you report it to http://bugs.elivecd.org too ? (reference this trhead on it)
To improve the betatesting, which Ubuntu version is? what options are needed to know to install it over a virtualbox to reproduce the issue ?
Yes that is possible, the installer includes some calls of gdisk when gpt is found but it was minimally tested
About LVM, if you talk about Elive install this is automatically done from the "auto partitioning", using an optimal combination of lvm and/or encryption with it
Also, do you used the “report debug data” of the installer when you had these problems ? if so, which email you used on it ?
No, I didn't as the "problem" did not show during install, only on subsequent boot and sometimes not even on the first boot. The disks are SATA SSD over USB, usually done on a faster machine than the final destination machine for speed reasons. 
Admittedly Elive gives a warning (and isn't very helpfull) about installing to USB but as I'm not using flashdisks I don't really pay much attention. The disks usually have had Win, Ubuntu, Debian, etc on them in multiboot configurations and often a shared /home partition.
Often I use Clonezilla to simply clone /home partition on the new install, sometimes I clone the whole existing disk (that should include the MBR afaik) if I've installed a lot of extra stuff or needed something special. Heh, I've got a 3T disk with clones of /home partitions at least 5 years old up to a week ago. 
Methinks the trouble lies therein that ubuntu and windows use UEFI and on some machines then get quirky using "legacy boot" so I've heard rumoured.
So today 30 March the installer missed out while installing on a disk that previously had Ubuntu on it. It should have sent the debug info through *my_username) at protonmail.com and has a reference: 6103508f175f7a9dd5d09202c7f7d36623933
I chose "default" option. Will try to install on a self partitioned disk with standard prima partitions.
Anyway, IMHO LVM sucks when needing to recover data once the disk is corrupted.
I see some errors in one of these reports, but this should be not the cause:
grub: warn: gpt partition has no bios boot partition, embedding wont be possible
the commands that were send to the gpt partitions with GDISK is:
t
3
8300
w
Y
q
Which basically are the same commands that you will interactively run with gdisk to the disk, maybe these commands were bad set
After to try them in a virtual machine they does:
- t: change a partitions type code
- partition to modify is 3
- type is 8300 (standard linux partition)
- writes and quit....
That was on a 12gb partition with the original code 0700 (microsoft basic data), @triantares what was this partition before for ?
What was exactly the partitions 1, 2 and 3 for ? I see them with these sizes: 23,5 gb, 6 gb, 12 gb, then a fourth partition of 196 gb (this one should be the OS and/or HOME)
They would indeed have been win, swap, ubuntu and /home....I always keep /home separate on standard partition scheme.
Actually they should've been wiped. I used the default option: "entire disk" and LVM there.
Methinks that's the old partition table getting revived from backup or not getting removed at all....but why?
Will try again when I get a chance.....a similar report should have been sent a short time later when i tried another disk. Same email addres but obviously different disk. Iirc a 1000Gb disk but I'm not 100% sure as I don't have access to those disks atm.......a short weekend in away from ships and home. 
Well, in the end there’s not much possible to do here, but looks like there’s a bug in the installer for sure, we should do new tests in next Elive betas (which also includes newer tools, newer kernel and gdisk etc), in a way to reproduce it
If by installing an ubuntu in a virtualbox (please tell me the install details for that) I can reproduce the issue, it will be easy to fix (virtualbox has snapshots so i can come back to the previous moment of the bug and see what is happening in every step)
The strange thing is that, on one of the disks I created a completely new (non GPT) partition table using gparted on another ubuntu machine and then went on to install Elive that disk. Both disks haven’t been touched since and are available for testing.
Mmh, i dont think it will be very easy to test on those disks, if they are broken (or not) is not possible to know “what” causes it, the best thing is to reproduce the problem,
How I can install the system (ubuntu? version?) in teh same way you had it with gpt mode ?, i will do that on a vbox
That's not going to be easy.
In general the laptops come with some windows version pre-installed. I usually shrink Windows, remove lenovo back-up partitions (but keep a copy with clonezilla in case I want to return or sell the machine) after which I installed Ubuntu (that will have been 16.04 upgraded from 12.04).
In general I keep a large /home partition which I sometimes clone over through clonezilla from a previous backup or machine. That does create problems with the UUID but can be repaired by simply editing /etc/fstab...well not always that simple but that's another story/thread.
If, after a while I find better use of the win partition I will usually install perhaps another unix flavour in it's place.
In this case I used a broken Thinkpad Helix2 (the one with the noisy fan) and installed on msata over USB 3.0 (I'm slightly wary of perhaps being underpowered there).
The second install I tried was on 1 Tb sata disk over USB3.0 on the same helix2 which previously had 1 single ntfs partition, then a cloned elive system (which wouldn't boot on its own), then ubuntu 18.04 which was then replaced by a fresh elive install using lvm.....but never a windows partition.
There should be a report of that a few hours later than the partition scheme you showed me before with the same @protonmail.com address (I didn't write down the reference hash, this time).
I'm be quite interested in seeing the data you recieved there as well as that of the previous disk, so I can compare. If you would send me a copy to my protonmail I'd be grateful.
Writing this down I realize that Clonezilla is also a common factor and might be to blame for "false" partition sizes.
If you're still in Barcelona I could actually send you the 1 Tb disk through the post (snail mail) this week ....and as far as I'm concerned, you can permanently keep it too.
Just as a small token of my gratitude towards your work.
I'd love to bring it personally but I don't have the time . I've got one ship to load on Tuesday in Zeebrugge, Belgium (that's where the 1 Tb disk is), another to unload in Roeselare on Wednesday whereas I'm at home now in Terneuzen, the Netherlands, enjoying my weekend 
UPDATE:
I checked what clonezilla had to say about the partition setup and methinks I’ve found the culprit.
The partition table according to Clonezilla as specified by blkdev.list:
KNAME NAME SIZE TYPE FSTYPE MOUNTPOINT MODEL
*loop0 loop0 215.8M loop squashfs /usr/lib/live/mount/rootfs/filesystem.squashfs *
sda sda 238.5G disk TOSHIBA_THNSNF256GMCS
*sda1 |-sda1 2M part *
*sda2 |-sda2 6G part swap *
*sda3 |-sda3 23.5G part ext4 *
*sda4 `-sda4 196.9G part ext4 *
sdb sdb 3.8G disk iso9660
and blkid.list:
/dev/loop0: TYPE=“squashfs”
/dev/sda1: PTTYPE=“dos” PARTUUID=“7f7c8e18-6ec3-4121-a718-e1d538c9c9e2”
/dev/sda2: UUID=“58603e47-e21b-4519-9053-52ff3837f327” TYPE=“swap” PARTUUID=“5db51baf-eb15-43de-9bac-2e9acf521a57”
/dev/sda3: LABEL=“Elive_OS” UUID=“3501bf84-3c82-40d8-a58d-9d19d738b126” TYPE=“ext4” PARTUUID=“c2421657-d74d-41f7-a9e6-7c30df176044”
/dev/sda4: UUID=“9f3c5921-8053-4edd-9683-8a25381509c4” TYPE=“ext4” PARTUUID=“49bc50fb-4682-464d-a93f-f33d1e546dab”
/dev/sdb1: UUID=“2019-01-08-09-10-02-00” LABEL=“2.6.0-37-amd64” TYPE=“iso9660” PARTUUID=“495d5b6a-01”
Where the 12gb partition would be the rest of the 256 Gb disk i.e. unused in the scheme but was part of the prior Ubuntu install.
sda-gpt according to clonezilla:
Number Start (sector) End (sector) Size Code Name
- 1 2048 6143 2.0 MiB 0700 *
- 2 462249984 474898431 6.0 GiB 8200 *
- 3 6144 49315839 23.5 GiB EF00 *
- 4 49315840 462249983 196.9 GiB 8300*
This is the first time I’ve had these issues with clonezilla
lolTotaly resolved, yessir. 
