The library beneath the UI has not changed that much so data-loss is not to be expected. E.g. the commit summary will match the actual changes done to the system.
Not really. Finally I has been able to get all my data back, but it was a pain. I know what exactly happened but I am not able to reproduce it once again even on a very similar configuration - that is why I have not reported the bug at the end. But at least I can tell you... I had two primary partitions on my disk and one extended one with several 20GB partitions (did not know how much exactly) and one big home at the end. This partitioning was very, very old, so maybe there was something odd in the partition table. But it survived maybe tens of SUSE installation before. I moved to the expert mode. Installer showed me a list of 20GB logical partitions and a home. I picked up the last one to use it as a root and thus format it. Then I told the installer to leave my home partition as it is. Installer warned me in red it is going to format my 20 GB partition and nothing more. I was perfectly fine with this proposal. The installer formatted the partition for the root filesystem, installation failed then immediately because home could not be mounted. Weird. I have rebooted back to my original installation and did not suspect anything more than a messed up installation like usually. Unfortunately I did not save the logs, I wanted to have the installation to do some tests of my own, not because of general testing. But my home was lost. What really happened? Installer thought up one more partition that did not really exist, presented it in the list of the existing ones and I am pretty sure it told me that it has also 20 GB. The partition table after its action looked like this, sda8 did not make any sense, sda7 was unexpectedly small and contained just several basic directories created during installation and a few files in them: /dev/sda1 : start= 63, size= 41945652, Id=83, bootable /dev/sda2 : start= 41945715, size= 8401995, Id=82 /dev/sda3 : start= 50347710, size=438044355, Id= f /dev/sda4 : start= 0, size= 0, Id= 0 /dev/sda5 : start= 50347773, size= 41945652, Id=83 /dev/sda6 : start= 92293488, size= 41945652, Id=83 /dev/sda7 : start=134239203, size= 20980827, Id=83 /dev/sda8 : start=155220093, size=333171972, Id=83 BTW, this is the output of sfdisk. The real partition table was probably a bit messed up, because when I asked parted to remove partition 8 later, it was unable to do so... although it printed me something similar, during rm it did not believe in its existence. Many thanks to ext3 hackers for their great work because even it this situation it was possible to recover all the data from original sda7. When I found out what really happened (it was not that easy because I did not rememember the count of my partitions), I just had to find some superblock backup and the rest was a great work of fsck :-) Unfortunately, when I recreated settings similar to the original, copied the recovered data back and started the installation again, the bug did not appear again - the list of partitions was correct. I am very sorry that I was that dumb and I did not save the logs at the first attempt :-( Anicka --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org