Bugzilla – Bug 1212560
language is after the installation is wrong (plasma)
Last modified: 2023-09-13 09:13:23 UTC
Created attachment 867713 [details] yast installation with the installation i was asked which language i will have. i chose the language German but after the installation the language was English.
Moving to openSUSE Kalpa product section
This is a YaST bug: 2023-06-21 07:43:28 <1> install(4326) [libsolv] PoolImpl.cc(logSat):133 job: install providing namespace:language(de_DE) but later: 2023-06-21 07:52:23 <1> install(4326) [Ruby] modules/Language.rb(GetLocaleString):534 locale en_US.UTF-8 2023-06-21 07:52:23 <1> install(4326) [Ruby] modules/Language.rb(run_locale_command):1432 Making language settings persistent: /usr/bin/systemd-firstboot --root /mnt --locale en_US.UTF-8
So, there was a YaST installation, you selected German at the YaST language selection workflow step, you got German for installation. Then I see it setting the German keyboard layout: 2023-06-21 07:52:23 <1> install(4326) [Ruby] modules/Keyboard.rb(Save):147 Saving keyboard german/de-nodeadkeys to system 2023-06-21 07:52:23 <1> install(4326) [Ruby] lib/cheetah.rb(record_commands):163 Executing "systemd-firstboot --root /mnt --keymap de-nodeadkeys". And that went okay AFAICS. But then it still set the English locale: 2023-06-21 07:52:23 <1> install(4326) [Ruby] modules/Language.rb(run_locale_command):1432 Making language settings persistent: /usr/bin/systemd-firstboot --root /mnt --locale en_US.UTF-8 2023-06-21 07:52:23 <1> install(4326) [Ruby] lib/cheetah.rb(record_commands):163 Executing "/usr/bin/systemd-firstboot --root /mnt --locale en_US.UTF-8". Which begs the question whether or not, since this is a MicroOS derivative, there even is support for other languages, or if that is somehow restricted by the product's configuration in control.xml. > <globals> > ... > ... > <timezone>UTC</timezone> > <readonly_timezone config:type="boolean">false</readonly_timezone> > <readonly_language config:type="boolean">true</readonly_language> ...and BINGO: https://github.com/yast/yast-installation/blob/master/doc/control-file.md "(boolean) readonly_language - The user only could change the language of the installer, but not for the installed system which will use en_US by default." And this is exactly what happened here. So please discuss this with the product / release managers of that product; YaST behaves 100% as specified.
It would be nice if the logging would clearly state that this ignores the user's language selection for the target system because of that parameter in control.xml, but that would be no more than a nice-to-have feature.
Please don't close this, it's still a bug that needs to be fixed. (In reply to Stefan Hundhammer from comment #3) > And this is exactly what happened here. So please discuss this with the product / release managers of that product; YaST behaves 100% as specified. MicroOS without desktops doesn't support locales but with desktops it does. Is it possible to define this per system role? (In reply to Stefan Hundhammer from comment #4) > It would be nice if the logging would clearly state that this ignores the > user's language selection for the target system because of that parameter in > control.xml, but that would be no more than a nice-to-have feature. Fully agreed. This would've saved everyone time.
(In reply to Fabian Vogt from comment #5) > MicroOS without desktops doesn't support locales but with desktops it does. > Is it possible to define this per system role? I don't think so. But since the very purpose of this product is to provide a stable minimalistic platform for containers and FlatPaks, based on a KDE Plasma desktop, it might make sense not to override the defaults with this setting. That would be a decision of the product or release manager. Who knows, maybe they even took this over from the default MicroOS, unaware that a desktop should really get some language support. But again, this is not a YaST bug. Please find somebody to take over from here.
(In reply to Stefan Hundhammer from comment #6) > (In reply to Fabian Vogt from comment #5) > > MicroOS without desktops doesn't support locales but with desktops it does. > > Is it possible to define this per system role? > > I don't think so. But since the very purpose of this product is to provide a > stable minimalistic platform for containers and FlatPaks, based on a KDE > Plasma desktop, it might make sense not to override the defaults with this > setting. That would be a decision of the product or release manager. This is clearly a bug. Regarding the MicroOS philosophy, this is the "works OOTB" part. > Who knows, maybe they even took this over from the default MicroOS, unaware > that a desktop should really get some language support. Yes, this is the case. The desktops support language switching already, it's just that the default after installation is wrong, which means the user has to navigate settings (in the wrong language) to change it, then log out and in again to have it fully effective. > But again, this is not a YaST bug. Please find somebody to take over from > here. The question is how to fix it. The locale set during installation should be kept in the installed system and I don't see any way to achieve this without cooperating with YaST, as YaST is the only tool that has this info. Does YaST store the installation settings somewhere where some firstboot service could pick it up?
Simply remove that <readonly_language> from control.xml or explicitly set it to 'false', and YaST will behave as usual, storing the installation language in the target system.
(In reply to Stefan Hundhammer from comment #8) > Simply remove that <readonly_language> from control.xml or explicitly set it > to 'false', and YaST will behave as usual, storing the installation language > in the target system. This would change it for all system roles, not just the desktop ones. The non-desktop MicroOS does not support changing system locale.
Then this is a chicken-egg problem that should have been considered when designing those MicroOS desktop products. Does it really make sense to even have a non-desktop MicroOS role in a dedicated desktop product? Aren't we creating artificial problems here? If a user really wants pure MicroOS, why not simply use a pure MicroOS ISO? Do we really have to make everything extra complicated? The bane of YaST (the old YaST1 as well as YaST2) since the late 1990s has always been nobody willing to commit to any decisions, thus we always have to make everything configurable, which keeps creating unnecessary problems down the line all the time. It makes reliable testing pretty much impossible, and we constantly have to plug holes introduced by a neverending demand for even more configuration parameters; the sheer number of possible combinations is killing us. That's the main reason why every other year there is somebody who comes up with a "new, much simpler installer" ("how hard can it be?" etc.), and 90% of the company is enthusiastic about it, completely neglecting that they are the same people who keep demanding more and more parameters that make everything complicated. I'll check if there is a possibility to define this per role, but I can't make any promises.
JFTR: Roles support only limited set of features. They are extended if there is a business need, usually through Jira request.
From IRC just now: <lslezak> HuHa: IIRC roles can override any setting in the control.xml so it chould be possible to configure per role.
For samples, please check out those "role" packages / repos: https://github.com/yast?q=system-role&type=all&language=&sort=
(In reply to Stefan Hundhammer from comment #10) > Then this is a chicken-egg problem that should have been considered when > designing those MicroOS desktop products. > > Does it really make sense to even have a non-desktop MicroOS role in a > dedicated desktop product? > > Aren't we creating artificial problems here? If a > user really wants pure MicroOS, why not simply use a pure MicroOS ISO? Do we > really have to make everything extra complicated? Yes, I'm also thinking that meanwhile a dedicated .iso for the desktops makes more sense. GNOME might soon move to only image based installation (with literally 0 options) anyway. > The bane of YaST (the old YaST1 as well as YaST2) since the late 1990s has > always been nobody willing to commit to any decisions, thus we always have > to make everything configurable, which keeps creating unnecessary problems > down the line all the time. It makes reliable testing pretty much > impossible, and we constantly have to plug holes introduced by a neverending > demand for even more configuration parameters; the sheer number of possible > combinations is killing us. > > That's the main reason why every other year there is somebody who comes up > with a "new, much simpler installer" ("how hard can it be?" etc.), and 90% > of the company is enthusiastic about it, completely neglecting that they are > the same people who keep demanding more and more parameters that make > everything complicated. Yes. https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html describes the result nicely. > I'll check if there is a possibility to define this per role, but I can't > make any promises. Yes, this is why I'm asking for alternate options, but all of them require getting the information from YaST somehow. (In reply to Stefan Hundhammer from comment #12) > From IRC just now: > > <lslezak> HuHa: IIRC roles can override any setting in the control.xml so it > chould be possible to configure per role. Yay! I'll try that.
Here's the documentation: Adding a New System Role https://github.com/yast/yast-installation/blob/master/doc/installer_extension.md#adding-a-new-system-role It really says: In this case it just configures the default software patterns but it is possible to define any other defaults like partitioning, etc. But there still will be some limitations "anything". System Roles https://github.com/yast/yast-installation/blob/master/doc/control-file.md#system-roles Te Globals section does not seem to be mentioned though.
(In reply to Fabian Vogt from comment #14) > (In reply to Stefan Hundhammer from comment #12) > > From IRC just now: > > > > <lslezak> HuHa: IIRC roles can override any setting in the control.xml so it > > chould be possible to configure per role. > > Yay! I'll try that. Works perfectly, thanks a lot for the help! https://github.com/yast/skelcd-control-MicroOS/pull/70
OK, so we can close this now AFAICS.
This is a non-issue going forward, as Kalpa will be following Aeon, and not using Yast for installation. It just takes time, as Richard and the Aeon team haven't fully nailed down what that's going to look like yet.
(In reply to Shawn Dunn from comment #18) > This is a non-issue going forward, as Kalpa will be following Aeon, and not > using Yast for installation. It just takes time, as Richard and the Aeon > team haven't fully nailed down what that's going to look like yet. IMO the YaST installation method needs to stay for the time being as at least the kiwi based image deployment has terrible UX.
(In reply to Fabian Vogt from comment #19) > (In reply to Shawn Dunn from comment #18) > > This is a non-issue going forward, as Kalpa will be following Aeon, and not > > using Yast for installation. It just takes time, as Richard and the Aeon > > team haven't fully nailed down what that's going to look like yet. > > IMO the YaST installation method needs to stay for the time being as at > least the kiwi based image deployment has terrible UX. Your opinion is noted, but we will not be retaining YaST, that is certain. I would have appreciated being involved in the review as this has now impacted Aeon users who are still using the legacy MicroOS YaST installation media I would have much preferred that everything there remained static while I work on the new Aeon install media