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! ^^
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 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.
Right, I’m sorry, powers of 2, my brain skipped the distinction between 512 and 256… The checksum is OK 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.
half of old MBR partition → unallocated → / of Manjaro
old swap partition → swap
I also tried adding a fourth “/boot” partition of 512MiB… Same result
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
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.
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.
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?
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”
sould I try the torrent?
