Leap 15 installer chokes on healthy NTFS partition - installation fails

Hello Forum,
I tried a fresh install of Leap 15 on my Leap 42.3 system but the installation fails after the partitioning dialog.
Unfortunately my Linux foo is not strong enough to recover logs from the failed installation - it’s all in memory and not persisted.
So I try to recreate the log message from my memory after booting into the (unchanged) old system…

The last entries in ylog tell me (roughly - this is a human memory transcript - the actual error messages have much more “details”):
exec bin/mount readonly /dev/sde5
failed
$MFTMirr does not match $MFT (record 24)
then a lengthy text which explains that my NTFS partition is broken (which is NOT the case - I checked it) or that I am using a fake RAID (which is also not the case)
exit code 13

This causes the installation to fail.
The bad thing about it is, that I didn’t find a solution to tell the installer to ignore /dev/sde* alltogether.
This is a Windows-only hard drive. (I keep both systems on separate disks and use the UEFI boot manager to select Windows (linux is the default))

So I don’t expect the installer to even touch /dev/sde - let alone fail the installation because of it…

Can I somehow convince it to keep its hands of /dev/sde (without removing the hard drive physically)?

Any help is appreciated.
Thanks
& Greetings
Bernd

Hi
I’m guessing it was mounted in your 42.3 install? If so, that means it exists in the /etc/fstab entry. You can either boot from the install media in ‘Rescue’ mode and mount / and manually edit the /etc/fstab file and rem out (use a # at the beginning on the mount entry) the mount of /dev/sdeX. Or during install, use the expert partitioner and set the /dev/sdeX partition to not mount. Then once up and running can figure out what is what…

  1. fast boot in Windows must be off
  2. you should be able to take full control of the install and set partitions as you wish. Do not accept the partition scheme until it is exactly as you need it since you have a odd setup you must take control. The install is not good at reading minds.
  3. In generally doing a new install the NTFS partitions should not be touched unless you tell the installer to mount them. I suggest you leave it unmounted until after the install you can always mount it later

That’s not always enough.

I have an NTFS partition that was working fine. And I have fast boot disabled (in Win 8.1). But, some time last year, I could no longer mount it. I had to disable hibernation in Windows before I could get it working again.

To describe differently – Windows cheats. It tells you that fast boot is off, but it still partially hibernates the file system unless hibernation is disabled.

Hello together,
thanks for the answers so far…

To clarify: this is a fresh install (I don’t upgrade).

  1. I discard the standard partitioning suggestion
  2. I only use /dev/sda1 - format: ext4 mount to mountpoint /
  3. everything else is set to “do not mount” / “do not format” as I take care of everything else manually after installation of the basic system

Despite this setting Yast seems to check every drive/partition it finds in the system and tries to determine “is this a windows partition?” - maybe to support dual boot scenarios where it needs to know, where the windows bootloader might be located (just a guess…)

And during this check the installation process fails with a bogus error message - apparently the NTFS driver in use has a flaw and does not accept the checked & correct windows partition (for whatever reason).

And I don’t find a way to tell the installation procedure to keep it hands of that drive - It is simply not needed in linux mode and not expected to be included into the system in any way.
Where can I put a feature request as I find that this would be a good feature in itself (forbidden drives - do not even look at them! Never ever!)?

Such a feature would give me the opportunity to continue - I’m lost right now.
I tried to install with autoupdate=1 - but that did not achieve anything… (I was hoping that there might be a patch that corrects an already known error)…

I’m still in hope, that there is a magic boot option that excludes either the test or the drive…
Any hint - anybody? :question:

Your help is appreciated.
Greetings
Bernd

They redesigned the partitioner for Leap 15.0. So we are all short on experience with the new partitioner.

Your best bet is to file a bug report on this.

When you run into the error (on a new install attempt), then:

(1) Use CTRL-ALT-F2
That will give you a root command line.
(2) Use the command “save_y2logs”
That will save the logs into a file, and tell you the name/path for that file.
(3) Mount a file system where you can copy those logs. You can either use a USB drive (but not the one you are installing with, if you install via USB). Or you can mount an available partition on the hard drive (must be already formatted). I seem to recall that I had problems mounting a hard drive partition, so I used a USB drive with a FAT32 partition and copied the logs there.
(4) File the bug report, and attach the saved logs.
openSUSE: Submitting bug reports
(5) Use CTRL-ALT-F7
That should get you back to the graphic installer, where you can abort the install and reboot.

Oops, that’s confusing. Abort the install (step 5) before you file the bug report (step 4). You need a session with a browser to file that bug report.

Done

https://bugzilla.opensuse.org/show_bug.cgi?id=1106265

Let’s see :slight_smile:

Greetings
Bernd

Thanks for reporting the bug. That’s how these issues get fixed.

Temporarily disable the drive in the BIOS?

That would actually be:

self_update=1

… but it is not enabled for openSUSE or TW. I still do not completely understand why. The answer I am given begs the question “…then why not create the repo”.