Look, I admit I was selfish for not preserving the logs - I did the MX tools clean-up of 19b3 and deleted all left over stuff before taking a clean snapshot of my son's X1 g4 for cloning it on my other X1 g5.dolphin_oracle wrote: Thu Oct 10, 2019 1:30 pmif any installs are still present, we copy it over to /var/log on installation.bpr323 wrote: Thu Oct 10, 2019 1:19 pmSorry, I didn't keep the logs after the final try which ended with successful install - I was stoked it finally worked for me!dolphin_oracle wrote: Thu Oct 10, 2019 12:34 pm
I would love to see /var/log/minstall.log files for those 2 install cases.
BTW, if you formated the whole disk, you actually just made 1 big partition, so partition was involved, just not multiple partitions. This is an important distiction for the debugging, and it makes the difference between d and e interesting.
Also, what options did you use to create your LUM usb device? "Full-Featured" or "dd" mode.
I assumed the "live" logs would have been blown away anyway. But it's really easy to replicate just following my use cases :)
For LUM I used full-featured + optionals ticked for force gpt and force ext4 even if it exists
I do have some photos I was taking of Gparted screen with (i)'s related to missing data in failed partitions - do you want them?
In essence, the only path that worked was to create a new gpt partitions table and leave it unformatted w/o creating any actual partitions.
I'm guessing you want to make Minstall to trap the errors and do some overriding steps to process them as exceptions?
The biggest problem is the use case where user installs side by side with to keep a Windows install - then my "whole-disk" workaround would be a disaster.
But I didn't try those scenarios with "custom" (manual partitioning) install - if I need Windows, I'll install it on a "free" VMware workstation Player/Pro.
I think it's a deathwish to try and install Linux side by side with Win on the same disk - unless you're a masochist, of course
I saw that only your one path worked, and the difference between the logs for d and e may tell us *why*. that's why the logs are so verbose. anything less than crazy amounts of output leaves us guessing to an extent.
I was working on a theory, but your stated method doesn't fit that theory 100%, so even the succesfull log will be useful.
Since:
a) I'm doing it anyway (it will blow away my 19b2.1 I'm running now), and
b) I was planning to test minstall of a snapshot from A to B, and
c) I assume installing a snapshot is the same as installing the "factory" ISO - I will do the following test plan:
Here's my X1 g5 partitions table that I will be upgrading from 19b2.1 to 19b3 using my son's X1 g4 snapshot
1) I will burn the USB on 19b2.1 using LUM (full + gpt + ext4)
2) I will try and auto-install 19b3 snapshot over 19b2.1 existing partitions - this should be a clean install, but one can't be sure
3) Even if it works, I will boot up again from USB and gpt to msdos partition table and will format whole disk to NTFS (a very plausible scenario for a virgin install) + auto install
4) Then I will gpt the disk to gpt partition table and format whole disk to ext4 + auto install
Note - 3 & 4 will fail but will produce the logs for you
5) then I will do my "silver bullet" trick with gpt table and no partitions (this should work)
AS a bonus, I can try custom install to 19b2.1 existing partitions IF (2) fails - please tell me EXACTLY what to do on the next screen (what should go where)
Have I missed anything? Have I mentioned my son is 7 year old (yes, seven) minecraft fanatic? )))
, I'm just starting to test it as well...
...really good...
cHeeRs 2 your prOjekT ! 
