Install Leap without secureboot/EFI

Due to a move interstate and all my stuff being in storage I have only just been able to install Leap onto my dual boot with Win8.1 and replacing 13.2 as the primary. I must say after 4 days of faffing about I am not a fan. I didn’t like the installer, I didn’t like the partition setup nor the way it kept wanting to nuke my windows drives. Anyway, after much angst I finally managed to get Leap installed and found that through the whole process had ignored my windows partition for dual booting (probably in a fit of peak because it wasn’t allowed to overwrite it), so now my dual boot is an escapade of shutting down, restart, goto bios, select different drive reboot. I realise that there is an issue with EFI/secureboot whatever, but after the aforementioned 4 days I cannot be bothered any more to try and fix it, I have more important things to do. I just want the old way back, I am happy to revert to 13.2 or try something new, maybe Mint, but would prefer to actually succeed to install Leap in a dual boot.

So I am going to nuke all the BTRFS partition and reinstall on an EXT4 and set it up the way I want to rather then what the installer wanted me to.

The question is, that I have finally got to is: How do I install Leap onto an ext4 drive that I have set up the way I want it without the installer trying to take over and stick in stuff I don’t need or want anyway, can it be done or have we wandered into an Apple world of our way or the highway… Secure boot is turned off in my bios and the Windows drive is MBR (which is probably what the problem is, but the installer neglected to mention all that). At this point I do not need uefi or secureboot.


Having a Win 8.1 in a MBR disk (presumably MsDOS partition table) sounds odd, so please make sure about it.
To have a dual boot it is essential that the DVD installer boots in the same manner as the Win disk (Legacy /MBR, according to the info you provide); otherwise you are likely to have to resort to BIOS to boot the other system.

That said, an MBR dual boot (Legacy mode, CMS, UEFI disabled or whatever it is called on your BIOS) should be quite straightforward if you manage to prepare your disk(s) beforehand the way you want them.
When the installer proposes a default partition setup, choose Expert Partitioner instead, then:

  • Rescan Devices
  • edit each partition adding mount point etc. (Right-click > Edit)
  • When satisfied with your setup, Accept.

Go on with the install, then Grub2 should recognize your Win8.1 and setup a boot entry for it by default.

BTW, the Leap DVD installer cannot boot with SecureBoot enabled (a known bug fixed after release), but if the installation is started in UEFI mode, SecureBoot can be turned on after the installed system has been updated to the last packages available in the Update repos.

Please write back if you still face problems.

Thanks, I think the step I missed in my umpteen attempts was ‘Rescan Devices’. So I’ll have a go with that.

BTW. Win 8.1 definitely on MBR disc.

If you already have a full disk openSUSE will of course propose removing stuff to have space to install. Select upgrade to reuse the current Linux install rather then installing a NEW os. You can of course use the expert mode to tell the installer exactly what you want. The installer can not read you mind so you may need to take control. Doing an update also perseveres all installed programs.

As to that, I didn’t, I had a completely empty 1TB hdd for it to play with and I couldn’t do an upgrade as the first attempt with efi and btrfs trying to take over the world had already nuked my 13.2.

Anyway, I finally got it installed on ext4 and it booted, a few tweaks with Grub2 and I even had a working dual boot Leap/Windows 8.1. Quite a few problems with Leap though, periodic lockups where I twiddle my thumbs for a few minutes until it decided to play again to the stupid, cannot change icon picture because the folder with the new icon in having been selected in the process refuses to become active, so the new icon cannot be chosen. I fiddled around with this and other stuff, copying back saved files and restricted formats and the like before rebooting to…a black screen with a mouse pointer. Another 4-5 hours wasted loading windows to search for solutions and rebooting to try them out and failing continually. Eventually I hit on the solution and fixed all the problems in one fell swoop. I reformatted the drive and reinstalled 13.2. Woohoo, success and it has only taken me 6-7 days to get to exactly where I was.

Opinion- Whilst I thank the volunteers who give a lot of blood, sweat and tears to develop openSUSE, I think Leap 42.1 is a disaster and the throwback naming to the original release is actually disrespectful given the heap that this is. It should be quietly packed away and marked as SUSE’s Millennium Edition and locked in a cellar somewhere where it can never inflict itself on people again. I have been using SUSE since about 6.2 and can honestly say that Leap has been the worst SUSE experience I have had, actually it is the worst Linux experience that I have ever had, not just the installation which was a 4-5 days epic in its own right but once installed and running as well - THE.WORST.EVER.

The installer is a disgrace, actually more the philosophy behind it is a disgrace, using BTRFS is a joke and indicates more about ideology than computer use. This is supposed to be a mature release, after years of development from openSUSE and SUSE Linux. Instead of mature we got a dog’s breakfast with numerous failures and even the basic stuff failing. I do not know if the fault is KDE or SUSE, but at this stage I don’t care, openSUSE is supposed to be the flagship of KDE integration, the best use of KDE in a Linux distro. From my experience your ship is on the rocks and breaking up.

I think openSUSE should back pedal and reboot 13 from .3. I will continue with 13.2 but on the basis of my experience I will never use Leap or BTRFS again and when updates for 13.2 stop I will move on.

Need to do a full update the release had some troubling bugs but it that has settled down with a lot of fixes

Leap is a leap it is transitional release with the base system coming closer to SLES releases and KDE moving to plasma5 which is still in the waddling stage.

A full update may have been a fix, but I never got even close to being able to - continual lockups and the need to hard boot to get past them (prior to the last time when I actually thought I was getting somewhere, Leap - into the darkness of a black screen and mocking cursor)

But what you say proves my point, it is a transitional release full of bugs. It is not gold and never was and should not have been released as anything more than a sandbox test release. 13.3 should have been the release and this Heap could have been Tumbleweed 2, because it is not even good enough to be Tumbleweed. The may cause some spluttering but I think that the users have been badly let down by this release. As a long term user I feel a bit betrayed.

A lot of people are using it and seem more or less happy with it. If you had come here for help we could have got you around the problems. nouveau.was a problem with some NVIDIA video cards for one but that problem is solved. You can boot to command line and do a zypper up as root to get the updates that most likely would fix most of the problems

So I am replying to this after some delay. I relented / cracked and gave it another go. I laid a circle of salt around my desk and made an offering that allowed me to install and do a full install to, apparently, a more stable state. Few small things but we seemed to be up and running. Three / four days in then disaster, boot to a black screen (Not graphics as I haven’t yet plucked up the nerve to install the AMD drivers after a bit of a disaster a few times ago, but nothing. A bit of faffing about and I find the problem, /tmp has filled itself all the way upo and will not allow the machine to boot. I manage to empty /Tmp and we boot as normal. More faffing about and I find an apparent fix which involves a few lines in /usr/lib/tmpfiles.d/tmp.conf. I set the empty time to 7d as per the thread and…3 days later same problem. Same fix empty /tmp, change empty to 1d, still no good, today no boot and /tmp full.

So I found a solution:

Download Knoppix live DVD (or CD) when opensuse 42.1 doesn’t boot - which is a depressingly regular occurrence, reboot with live dvd (or CD) clean out /tmp using a reliable and stable operating sytem, reboot into opensuse 42.1. Rinse and repeat as necessary every 2 - 3 days.

Oh, and my keyboard map is **** and I have no ctrl key.

So it appears that the problem is you do not provide enough space for root. Assuming you went back to ext4 you need 20 gig min with 30 gig being comfortable. It of course depends on your usage since any system wide database lives on root also.

Seems something specific to that install… on Ext4 I see:
main install (Gnome): total used / 9.5 GB, /tmp 20 MB
test install (KDE on VBox): total used** / 6 GB**, /tmp 1 MB (not used everyday, but sure more that 7d cumulative usage…).

Maybe seeing the output of:

# du -ch -d 2 /tmp

might help tracking down the offender…

Oh, how I laughed.
Ext 4 / is 73.24 gig, /tmp is filling with 63+ gig every 4-5 days, since yesterday /tmp has increased in size by 12.6gig, can we please just get cron back. It is certainly more automated than a post-it note saying 'Empty /Tmp every 24 hours. stuck on the side of the monitor.

Seems something specific to that install… on Ext4 I see:
main install (Gnome): total used / 9.5 GB, /tmp 20 MB
test install (KDE on VBox): total used** / 6 GB**, /tmp 1 MB (not used everyday, but sure more that 7d cumulative usage…).

Maybe seeing the output of:
# du -ch -d 2 /tmp
might help tracking down the offender…

linux-9fbx:/home/lilolme # du -ch -d 2 /tmp
4.0K    /tmp/systemd-private-9fc359ee0ac24633b4601e4bad1237c3-rtkit-daemon.service-TF7ixg/tmp
8.0K    /tmp/systemd-private-9fc359ee0ac24633b4601e4bad1237c3-rtkit-daemon.service-TF7ixg
4.0K    /tmp/gpg-AdFkjK
4.0K    /tmp/.Test-unix
4.0K    /tmp/gpg-ylLuHE
4.0K    /tmp/plasmapkg2-esL3sP
4.0K    /tmp/plugtmp-5
4.0K    /tmp/.esd-1000
4.0K    /tmp/gpg-HjTbku
4.0K    /tmp/plasmapkg2-AZ5P6P
4.0K    /tmp/plasmapkg2-6x9GOv
4.0K    /tmp/systemd-private-baaa0906dfa7487293c5f340172fd621-rtkit-daemon.service-8tc0Sy/tmp
8.0K    /tmp/systemd-private-baaa0906dfa7487293c5f340172fd621-rtkit-daemon.service-8tc0Sy
4.0K    /tmp/plugtmp-1
4.0K    /tmp/acroread_1000_100
4.0K    /tmp/systemd-private-06a5debbf1c54defb1978840443786e6-rtkit-daemon.service-AzYGY5/tmp
8.0K    /tmp/systemd-private-06a5debbf1c54defb1978840443786e6-rtkit-daemon.service-AzYGY5
4.0K    /tmp/YaST2-08686-tQXHAU
648K    /tmp/lu1611h3vpvl.tmp
4.0K    /tmp/plugtmp-2
4.0K    /tmp/systemd-private-77a85a7f783c4486a3905679e5897203-rtkit-daemon.service-cFBJ8z/tmp
8.0K    /tmp/systemd-private-77a85a7f783c4486a3905679e5897203-rtkit-daemon.service-cFBJ8z
4.0K    /tmp/.font-unix
12K     /tmp/YaST2-08686-pXIx4D
4.0K    /tmp/ssh-VvUdcLpbrxVz
8.0K    /tmp/kde-roger
12K     /tmp/dolphin.ZK6989
4.0K    /tmp/ssh-9rkPDFUEa7hQ
4.0K    /tmp/.ICE-unix
4.0K    /tmp/plasmapkg2-ZRvNub
3.2M    /tmp/lu349847dc4c.tmp
4.0K    /tmp/ssh-7mENTOq7PL7H
4.0K    /tmp/gpg-BJj7fl
4.0K    /tmp/ssh-jvNbYEPJhyTi
4.0K    /tmp/systemd-private-0deeba33dad24b07b85a925357e6ec86-rtkit-daemon.service-zmlKWO/tmp
8.0K    /tmp/systemd-private-0deeba33dad24b07b85a925357e6ec86-rtkit-daemon.service-zmlKWO
4.0K    /tmp/plugtmp
4.0K    /tmp/hb.2551
4.0K    /tmp/systemd-private-31845bcd504646959ac0b39e49597388-rtkit-daemon.service-oKR1ow/tmp
8.0K    /tmp/systemd-private-31845bcd504646959ac0b39e49597388-rtkit-daemon.service-oKR1ow
4.0K    /tmp/gpg-Srr08i
380K    /tmp/mozilla_roger0
16K     /tmp/plugtmp-3
36K     /tmp/hsperfdata_roger
4.0K    /tmp/osmc_mnt
4.0K    /tmp/plugtmp-4
4.0K    /tmp/systemd-private-2baf74c137794f78847bdc676fe465db-rtkit-daemon.service-L4hFbW/tmp
8.0K    /tmp/systemd-private-2baf74c137794f78847bdc676fe465db-rtkit-daemon.service-L4hFbW
4.0K    /tmp/gpg-TAXfmf
4.0K    /tmp/gpg-L93qP0
4.0K    /tmp/plasmapkg2-fLmiQF
4.0K    /tmp/systemd-private-69d15e3fad5048dca7e56d55e2b8ef72-rtkit-daemon.service-Zyzu6D/tmp
8.0K    /tmp/systemd-private-69d15e3fad5048dca7e56d55e2b8ef72-rtkit-daemon.service-Zyzu6D
4.0K    /tmp/gpg-sYHtV2
4.0K    /tmp/.XIM-unix
4.0K    /tmp/systemd-private-651673e8cd6a4d13b9e73fb784e22297-rtkit-daemon.service-JlW1ky/tmp
8.0K    /tmp/systemd-private-651673e8cd6a4d13b9e73fb784e22297-rtkit-daemon.service-JlW1ky
4.0K    /tmp/.X11-unix
4.0K    /tmp/gpg-rgY852
2.1G    /tmp
2.1G    total

This is highly unusual, to say the least, never seen something like that.
Since the listed subdirectories don’t add up to anything near 2.1G, the offender might hide in many single files or a few very large ones that should be clearly visible in /tmp.
Maybe one of the following commands might help spotting the offender:

# du -ach -d 1 /tmp

# ls -al /tmp

Since the output might be too large (or too disclosing) to be posted here, try to spot the largest files or the largest number of similar files yourself and see if those point to an unusual application, mail service, DB or the like.

How about log files a recurring error can make huge logs.

How about log files a recurring error can make huge logs.

It is definitely the /tmp folder that is the problem, there are no large log in there, good thought though. The only real thing that I have noticed and recurring every time /tmp needs emptying is video files listed as (for example) dolphin.A12345.part. At present with 6gig in /tmp most of that is that type of file. And these are not files that I have played on the system but may have passed through my system from maybe a hard drive to my server. So from it seems that Dolphin is retaining some sort of memory/copy of these files, for what reason I have no idea.

Hi, xxxx.part files are usually temporary stores for bit-torrent downloads and the like but should be deleted or renamed (to xxxx.iso for instance) once the download has finished. They might be a remnant of a copy or transfer as you suggest, but I don’t use Dolphin so regularly to be of help here.
I suggest you open a thread in the Applications subforum with an eye-catching title to get the attention of Dolphin specialists.