Kyrios I am aware that the command fixes the issue, however its something that shouldn't be required.

We will be releasing 4.1 Soon (tm). Be patient with us, please!

sudo eopkg rdb

We have no plans at this moment in time in supporting F2FS.

For the record, i managed to install an other distribution (elementary OS) without taking care of nouveau nor altering anything, with the same hardware of course.

Sorry for the delay, i was away this week-end.
I tried

nomodeset

, then

rd.driver.blacklist=nouveau

, then, in despair,

nomodeset rd.driver.blacklist=nouveau

but i still got the same result... :/

Have you tried blacklisting the nouveau driver?

@Rashguir is a friend of mine.

Does a regular nomodeset not work?

Well that is of course something you can't argue with.

We have no plans on supporting PXE booting or network-based installs.

Ah I think I misunderstood. The solus-image-*desktop* repos have recent commits, but no new release for Solus 4, that's why I was confused.

Like this.
I am also interested in knowing how I could build an iso with local packages. I gave it a try recently but fetching all the packages needed, building the index and pointing all this on a local web server, but it was complaining it wasn't finding the system.base component although I had all the packages of that component available.

Yeah that's what I thought, but I didn't find anything else. How are they built nowadays?

@der_eismann just look at the commit dates and you'll get to know if solus-image-gnome is still used 😄

Closing due to lack of response.

TL;DR : sudo localectl --no-convert set-keymap de-latin1

In T7449#140956, @DataDrake wrote:

Despite what you may think, I'm honestly just tired of closing tasks for things we don't need.

Despite what you may think, I'm honestly just tired of closing tasks for things we don't need.

@DataDrake No need for spite. At least we now know how things stand. Which is a good thing. Thanks.

No. We have our own installer for a reason, even if it does have fewer features at the moment.

Looking at the current installer sources (https://github.com/getsolus/os-installer) it seems that creating /etc/kernel/cmdline.d/50_keymap.conf would be rather trivial since there is already code to create the resume file here: https://github.com/getsolus/os-installer/blob/master/os_installer2/postinstall.py#L708

Got it. I opened https://github.com/getsolus/help-center-docs/pull/186 to add some hints to the help center docs in the meantime.

Yes, it's a bug in the installer. It won't be addressed until we rewrite the installer.

This seems to still be an issue on the 3.9999 release. I configured disk encryption and a German keyboard layout in the installer. After finishing the install and rebooting I got the US layout at the password prompt. Manually modifying /etc/kernel/cmdline.d/50_keymap.conf did the trick. Is this a bug with the installer?

I can confirm that blacklisting nouveau fixes this issue.

The easiest way is to just install it on a separate USB drive.

In T7309#138171, @DataDrake wrote:

To my knowledge, what you are trying to do requires grub for both BIOS and UEFI installs. We only support GRUB for BIOS installs, not UEFI. So yes, if you want UEFI support it will need to be a separate install.

Note: Solus is not intended to support both BIOS and UEFI at the same time. There is no practical reason that a desktop user would need that.

To my knowledge, what you are trying to do requires grub for both BIOS and UEFI installs. We only support GRUB for BIOS installs, not UEFI. So yes, if you want UEFI support it will need to be a separate install.

In T7309#138154, @DataDrake wrote:

You can boot from grub, just not on UEFI. We use systemd-boot for UEFI.

You can boot from grub, just not on UEFI. We use systemd-boot for UEFI.

In T7309#138133, @DataDrake wrote:

We aren't a normal distro so expecting a normal install doesn't make any sense. Solus is intended to be installed on a normally partitioned harddrive. It also doesn't use grub for UEFI installs which is likely part of your issue. Sorry, but what you are asking for is not something we support.

We aren't a normal distro so expecting a normal install doesn't make any sense. Solus is intended to be installed on a normally partitioned harddrive. It also doesn't use grub for UEFI installs which is likely part of your issue. Sorry, but what you are asking for is not something we support.

In T7309#138119, @DataDrake wrote:

Solus isn't intended to be run as a live system from a USB for everyday use. You can install it to a USB drive that is treated like a normal HDD/SSD. Our live environment is configured significantly differently from other distros which is why you are having so many issues. MultibootUSB installs may be more common in the Linux realm, but they are not as common as you think.

Solus isn't intended to be run as a live system from a USB for everyday use. You can install it to a USB drive that is treated like a normal HDD/SSD. Our live environment is configured significantly differently from other distros which is why you are having so many issues. MultibootUSB installs may be more common in the Linux realm, but they are not as common as you think.

In T7309#138105, @Girtablulu wrote:

Solus has a helpcenter entry regarding USBiso

https://getsol.us/articles/installation/preparing-to-install/en/ I suggest using etcher

Solus has a helpcenter entry regarding USBiso

We have zero interest in using someone else's installer. Ours is overdue for an overhaul, but I have higher priority projects in my queue.

You can always fix partition errors yourself by moving partitions around (assuming the filesystems contained in them support it). But that's also going to copy everything in the partition around.

Asus and Lenovo SSD equipped laptops here. Important question: whatever fix arrives, will it require a new Solus installation or not? Thanks...

I was making a note for myself on how to fix it. You don't need to do anything :)

I just checked what happens if you have the installer resize a windows partition, and it does the same behavior. It leaves 32 sectors between the partitions, which causes the alignment to be off.

Looks like all we need to do is add:
https://github.com/storaged-project/blivet/blob/a4aaaa0a236f68ec0176e9382898cdaebc701b7f/blivet/devices/partition.py#L658

I am also experiencing this issue on an LVM on LUKS install. Had to manually include in fstab with: /dev/SolusSystem/Swap none swap sw 0 0.

Any updates here?

Not sure if it's the same problem but here's what I have tested:

Is this still an issue with the latest ISO? I have successfully installed EFI full encryption via qemu with it.

In T4297#87108, @Erwhann-Rouge wrote:

But then I didn't found the "Login Screen" button mentioned by franklinovitch.

I also encountered this issue with the budgie and plasma iso 3.9999. However no problems with the previous iso.

We are no longer adding new functionality to eopkg, I will however take this under advisement for the next package manager.

There are tons of utilities that can do this

In T4941#131717, @DataDrake wrote:

Can someone verify this is still an issue with the latest ISO?

Small correction, the only item I was going to work on was getting the I.P. address of the user, which was done previously via a /location endpoint. This was replaced with our new infrastructure. The issue at hand is not explicitly related to geolocation but rather network connectivity. I don't see this being resolved until we have some new installer.

I think this is Low Hanging Fruit for the next ISO.

Assigning to @JoshStrobl since he is planning on working on geolocation stuff.

Can someone test this for the latest ISO?