Plasma Rolling LIVE USB issue

[mlcarson]

I downloaded the Rolling Plasma ISO, validated its checksum, and installed it to a 32GB USB stick. I booted to the USB via UEFI, got the first menu, but attempting to boot the default option gives me the following:

The following installation problem was detected while trying to start Plasma:
$HOME directory /home/linux is out of space.
Plasma is unable to start.

The download of the Rolling Cinnamon ISO did not give me this issue. I'm simply using the DD method of creating the bootable USB stick from Debian linux. I've not tried a Suse version of Linux in at least 5 years and wanted to give it a shot via Geckolinux but this isn't off to a promising start. Any idea what might be wrong? Computer is using AMD Ryzen 3900 and it does have an Nvidia 1080TI card but that's generally not an issue with the default Nouveau driver. I've never seen this issue before so am kind of at a loss as to why it occurred.

[geckolinux]

Hi, what dd command exactly did you use to create the live USB?

[mlcarson]

And I definitely wrote to the drive (/dev/sdg) and not to an individual partition. I deleted all partitions before doing DD in both cases. The expected behavior of DD is definitely not to partition a drive to it's capacity as you showed when using UEFI. UEFI is going to need a FAT partition containing the EFI/BOOT folder. This latest ISO seems to assume that the ESP partition doesn't exist and tries to use its space rather than the unallocated space for COW. Note how it changes the BOOT partition label from BOOT to cow and changes its format to EXT4. The USB drive becomes unbootable from UEFI once that happens. The working version leaves the ESP partition alone and utilizes the unallocated space for cow.

So my guess is that the current ISO works fine for legacy MBR systems but is failing for UEFI based on the above.

[geckolinux]

I definitely can't make heads or tails of it, since all the ISOs are generated in the exact same way. But at any rate, could you please test this ISO?

https://sourceforge.net/projects/geckolinux/files/Rolling/staging/GeckoLinux_ROLLING_Plasma.x86_64-999.210509.0.iso/download

Thanks a lot for the help.

[mlcarson]

That version works fine. It creates the COW ext4 partition from the unallocated space on the USB drive and doesn't touch the Boot partition.

[geckolinux]

Thanks a lot for confirming that. Still doesn't make sense how a single ISO could behave differently from all the others that were created in the same way, but I guess it's easier to just release a new ISO for now. Once I finish testing those 210509 ISOs I'll mark them for release. Or if there is some other issue then I'll have to recreate them at a later point, and I'll ask you to beta test the Plasma version again if need be. Thanks for the help.

[geckolinux]

@mlcarson Would you mind testing the latest GeckoLinux ROLLING Plasma ISO just to confirm if this issue appears or not? Thanks a lot for the help.
https://sourceforge.net/projects/geckolinux/files/Rolling/999.210519/GeckoLinux_ROLLING_Plasma.x86_64-999.210519.0.iso/download

[2wing]

Just downloaded 210519 Plasma Rolling. Rufus 3.14 and "DD" method with GPT from within Win10pro to 32GB usb. (after failing boot with "iso" method).
Does boot from second option "2" (am using one-time boot list F12) but never seems to complete.
Does boot from first option (not numbered) and eventually gets to green water drops ... but it takes many minutes for each and every mouse click. Never actually got system monitor to display. Dolphin never got past "not responding".
After 20 minutes without any useful function abandoned and returned to Windows.

Previous attempts with Static on external ssd have also failed (similar to discussion #231 on General).
In my case it fails to boot after first successful boot and full upgrade.

But can boot and use the same Static from a usb with full functionality.
A beginner with Linux so unable to get further .... but will try a different usb.

[geckolinux]

It's still possible to set the Windows 10 bootloader as the default bootloader in the UEFI settings if that's what you want. That's the easiest solution for now.

Another option would be to reinstall GeckoLinux to the external drive, but selecting the EFI partition on the primary drive as the one to use for GRUB.

[2wing]

Solved the win10p boot issue now with help from "TenForums".
Command line to delete the EFI and remake.

Your second suggestion to use the EFI on primary drive is what I had ...
But it seemed to only be "enabled" if the external was connected .. would fail to boot from any partition on any drive otherwise.

As for Gecko ... very much want Linux separate from Windows so am having another go at a previous method that I did not do correctly first time round (many attempts at all this over last week).

Namely remove primary nvme drive with w10p on it.
Then do all Gecko installing with only the external ssd and the live usb. Then refit the primary.
I am very happy (prefer) to use the bios F12 bootlist for Gecko and keep the primary drive as default Windows.
That way I should have a portable Gecko installation ?
Or have I missed an elephant ?

[2wing]

Seems to be resolved now:
You were correct that the installed version runs very much faster than the live version.
Now on external ssd only install booted from /dev/sda2 with primary nvme drive removed.
Processor idling most of the time (as per usual). Mouse clicks get quick response.
But still issues with system/local time. Correct local time reset before install - now showing plus two hours (accepted settings that matched existing for time zone).
This is set to UK for language and keyboard (which in this case has stayed as selected) but time zone is France.
So baling out of this topic and will move on to using it !
Paul

[geckolinux]

Thanks for your persistence, I'm glad you figured it out.

Regarding the EFI partition, it could have been accomplished with the Calamares custom partitioning option without juggling hardware, but I just mention that for the sake of completeness and for others who run across this issue. It is a valid criticism that Calamares should offer the choice of which EFI partition to use in the easy guided installation options, and the request is open here.

The timezone confusion is due to the fact that Windows sets the motherboard clock to the time in your timezone, whereas Linux by default sets the hardware clock to UTC (Greenwich) and then adjusts the time offset it shows you via software according to the timezone you choose. So to keep Windows and Linux from fighting over the time format, open YaST Date and Time and disable the option Hardware Clock Set to UTC. While you're in there, under Other Settings... you might want to enable NTP automatic time updates.

[2wing]

Solved as far as I can see ...
Thanks for pointer to UTC, that works too.
Over and out.
Paul