Unable to use existing partition setup for re-install

English Install/Boot/Login
1

I have decided to re-install my Tumbleweed system as I have a problem with KDE Plasmashell which seems unresolvable. So I downloaded the latest TW DVD iso and checked its validity - all OK. In fact I have already used this iso to install in a VM without a problem although in that case there is no partitioning to worry about.

Now the Installer loads OK on the native PC and gets to the partition setup, as I want to use my existing partitions I selected the Expert Partitioner to start with the existing partitions. All well and good. I have the following already in use for TW:-

/boot/efi 204Mb
/ 268Gb
/home 429Gb
swap 11Gb
rest of 1Tb disk is a private partition with my data on it to be added later

so I edit each existing partition to create the same mount points and format each one and then accept. At this point the partitioner throws an error saying I have no device for /boot/efi. I am unable to see why this is. The only thing I can think is that the format option only allows FAT and not VFAT. Anyway I am unable to continue with the install until I can fix this. The existing system partition layout works as I am using the system to write this.

Am I doing something wrong or is there a problem with the installer?

Stuart

2

Why did you (try to) edit the /boot/efi partitions? I would think that when the installer already deteceted it and wants to use it for /boot/efi, there isn’t much to change there.

3

Doing an upgrade rather then install will reuse exiting configuration

Are you sure /boot/efi is pointing to an existing partition?

Sure you are installing in EFI mode and not legacy? Previous install was legacy???

Show fdisk -l

4

Here is fdisk for the disk I am currently using


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 1D8E0E0A-42C6-46F6-A592-343B9AE73B2A

Device          Start        End   Sectors   Size Type
/dev/sdb1        2048     401407    399360   195M EFI System
/dev/sdb2      401408  524683263 524281856   250G Linux filesystem
/dev/sdb3   524683264  545648639  20965376    10G Linux filesystem
/dev/sdb4   545648640 1384513535 838864896   400G Linux filesystem
/dev/sdb5  1384515584 1953525134 569009551 271.3G Linux filesystem

I guess I could use update instead, had not though of that but can I be sure it will completely overwrite everything. I’m doing this because I have a problem which I have not been able to resolve so need a clean install.

Stuart

5

Yes it overwrites all system but leaves programs untouched. basic difference is the upgrade does not format /

6

Well I did an upgrade and it has not fixed my issue with Plasma which is very strange. The thread which reports it is https://forums.opensuse.org/showthread.php/529253-Configure-Desktop-seems-not-to-work-now and I thought would fix it by upgrading. Now the only thing I can do is a complete re-install.

Stuart

7

I found I still had the TW snapshot from 28th Sept 2017 as an ISO so created bootable USB stick and low and behold the expert partitioner works OK on that. On the most recent snapshot apart from the error I encountered the Options button throws an error rather than opening a pop up with the options. The old expert partitioner suggested to re-use my existing partitions and allowed me to set to format the /boot/efi and allowed the mount to be set where the new one if you set to format does not allow mounting.

So in that part of the installer at least there are some significant changes and I would contend some bugs as well. I’d rather use the newer one as there will be practically nothing to add following the install but if I use the 2017 one I will have 4 months worth of updates to install.

Stuart

8

When you have this misbehavior documented (specially that it worked earlier), please file a bug report at https://bugzilla.opensuse.org/index.cgi

9

Created bug 1077868 for this problem with the current snapshot.

Stuart

10

Today I have installed a new empty HDD in the PC and now I have been able to run the installer and set up an identical partition layout on the new disk without problems, although the Options button in the Expert Partitioner still says not implemented yet (or words to that effect) but at least on a new disk it works, however it still should work using the existing partitions on an existing HDD.

One other slightly annoying thing in the installer, when you get to the Software etc there always used to be options to disable the firewall etc and now this is gone. A backwards step in my view if it’s by design.

Stuart

11

I’m puzzled by this.

I have been doing what you describe, except for Leap 15. And I have not run into the problem you had.

As far as I know, Leap 15 is using the same partitioner as Tumbleweed.

I’m now downloading the Tumbleweed installer, to give that a try.

12

I have added a comment to your bug report, and marked it as confirmed. Your fatal mistake was to set the EFI partition to be formatted. The new partitioner loses the property that it is an EFI partition, and there’s no way to recover that. If you had reformatted all of the other partitions, but kept the EFI partition as it was without reformatting, it would have worked.

Still, it’s a bug that should be fixed.

13

I’ve found another issue (in my view) which I’ve added to the bug report. After install on the new empty HDD the fstab built references the system disks by device name and not UUID which means if the order in which the disks are plugged to the motherboard changes the system will not boot. The Options button (if it worked) from memory allows the option to change to use UUID for mounting. In my view UUID should be default anyway since that allows booting irrespective of the order of disks.

Stuart

14

Wasn’t that what I suggested in post #2 two and a half days ago?

While I admit that it is a bug that should be fixed, I also see no need to change anything on the EFI partition in the OP’s scenario. Thus by doing what I suggested we would have nailed down the bug rather soon I assume :frowning: