First install, dual-boot with existing openSUSE Tumbleweed

I grew tired of fighting against openSUSE strange behavior, so I decided to create a dual-boot with Manjaro. Here’s the current state of my SSD:

(screenshot taken from Tumbleweed.)

I downloaded the latest .iso from Manjaro’s website, launched it from a USB drive (I use Ventoy), but… No matter the partitionning scheme I choose, the installer crashes after 10 seconds, with an error:

Python.Boost [...error... problem with] "mount" [step]

I’m afraid I couldn’t even properly copy the error because the USB drive usually crashes after that… I found no help online, because everyone seems to get similar errors but with the “bootloader” step — not the “mount” one.

I can only guess it’s either a problem with UEFI or my partition table. (?) But I have broken my computers so many times playing with partitions I don’t trust myself enough anymore to try anything on my own… Help! ^^

Hi @ash13 and welcome to the Manjaro forum.

Did you verify the checksum of the ISO after downloading?

I didn’t, but I’ve tried two different ISOs, both from the official page, I’d be surprised that this is the problem… I’ll see if I can still check
Edit: please what’s the prefered way to check this? Both md5sum -b and sha256sum -b outputs are different from the site’s checksum (the hash part, the readable name is OK)…
Edit 2: neither does sha1sum… I guess you’re right and it is corrupted :confused: sould I try the torrent?
Edit 3: I get the same 3 hashes for the torrent… This makes me think I’m not running the right command and that my ISOs are fine…?

The name of the checksum file ends with .iso.sha512
So you’d use sha512sum on the downloaded .iso and compare the result with the checksum on the download page.
I suggest checking the .iso file that is actually on your Ventoy stick - not just the downloaded file on your disk.

I did both… As I said, USB/computer and sha1/sha512/md5sum: I get consistent results (even though none of them is the one of the website)…

What you said was:

so I was trying to tell you that you chose the wrong checks because you didn’t mention the correct one to use

Right, I’m sorry, powers of 2, my brain skipped the distinction between 512 and 256… The checksum is OK :confused: again I guess this problem comes from the disk, maybe something with GTP and MBR? It’s only a guess of course

Only you know what scheme you used - although the installer should not just crash with any scheme …
You only use the unallocated section of your disk and re-use the /boot/efi (that is what I’d do).
And perhaps also re-use the swap - but that could be problematic when the swap is used to store the hibernated state of one of the two systems.
I’d re-use it and just take care that the other system isn’t relying on hibernation to disk (which means: to swap)

only a guess here as well:
make sure you boot the installer in the same mode (bios/UEFI) than what your Suse install is using - which is EFI / UEFI by the looks of it.

That’s exactly what I tried first:

  • old EFI partition → /boot/efi
  • half of old MBR partition → unallocated → / of Manjaro
  • old swap partition → swap

I also tried adding a fourth “/boot” partition of 512MiB… Same result :confused:

The catch is, Tumbleweed does rely on hibernation “to disk” (btw it works only half of the time: it’s one of the problems I mentionned). But I know no “switch” in Tumbleweed to (de)activate this functionnality (I simply de-activated Secure Boot and then I could use it)… I don’t know how to turn it off

Oh, yes I can try that! I’ll be back

I’m sorry - I cannot make sense of this … :man_shrugging:

A disk is either partitioned as GPT
as MBR

… from what I know …

Maybe the installer cannot make sense of it either ^^’ Basically I’m just saying: start from the screenshot of the post, and format the empty space to ext4 and ask the installer to mount it on /. Does that make more sense?

You can always just format the free space as ext4 yourself - prior to starting the installer.
Or point the installer to the unused space and tell it to use it …

But it shouldn’t crash.

Ideally, it would do what you tell it to do - and if you tell it to do the wrong thing it could destroy your previous installation.

But it shouldn’t crash.

Why it apparently does - I don’t know
and have no idea of how to investigate.

Boot up you installer usb iso, open a terminal and type:

lsblk -f
inxi -Fazy

Copy/paste output here.

I will, but I need to sleep now! I’ll upload the info here asap. Thanks for your help so far.

Solution: I ended up erasing my disk and creating a GPT partition table, and then it worked. So the problem was “just” that my SSD did not possess a GPT partition table (I guess openSUSE used MBR).

Good luck to anyone who wants to dual boot those two on the same disk… I was forced to switch fully to Manjaro.

Probably because you either installed openSUSE in bios and not efi mode, OR

The installation program YaST can automatically detect whether secure boot is enabled.

It goes without saying that if you had setup SUSE as a UEFI system in the first place, you would likely not have had these difficulties. Oops, I said it anyway.

At least you won’t make the same mistake twice, right? :slight_smile:

I’ll mark it as solved for you. Cheers.

Thanks. I don’t understand though, I’m confident I installed openSUSE in UEFI mode… When I booted openSUSE I had my EFI partition mounted on /boot/efi, isn’t that…?

If your disk is already using GPT partitioning, then the installer continues to use that. If you are already using MBR partitioning, but boot the installer in UEFI mode, then it will want to switch to GPT partitioning (perhaps losing data). MBR vs GPT - #4 by nrickert - Install/Boot/Login - openSUSE Forums

This was a comment from 2016, so no, you most likely did not.

So that is probably the reason for what you call “strange behavior”