Due to the new crypto-policies-scripts sometimes if you add repositories in https://doc.mageia.org/installer/9/en/content/software.html Soma packages will reject to install due not valid certificate. This is like complaints in regular browser when you not have the right date and browse to https sites So I think that now this configuration should be a mandatory regular step before the step in the link
This is a surprise to me. If setting the date & time is not already mandatory, it should be. Are you sure the invalid certificates that you mention are due to wrong date?
CC: (none) => lewyssmithAssignee: bugsquad => pkg-bugsSummary: Set date & time zone should be a regular mandatory step => Set date & time zone should be a regular mandatory step; some certificates fail if it is not sensible
(In reply to Lewis Smith from comment #1) > This is a surprise to me. If setting the date & time is not already > mandatory, it should be. > Are you sure the invalid certificates that you mention are due to wrong date? Quite sure in one or my test, I just install without add repositories. Then add the repositories in the installed system, perform an update and see the complaints related Then I remember see and ask for that before and check the date, it was wrong. Late I do just other installation without add repositories, and in the summary step set timezone -> date, and select to make update and things goes better Currently, this setup is optional and is in the summary step, my proposal is move as part of the installation/updates/upgrade process.
Fascinating. It is in the docs: https://doc.mageia.org/installer/9/en/content/locale.html#selectCountry
Quote: Select your country or region. This is important for all kinds of settings, like the currency and wireless regulatory domain. Setting the wrong country can lead to being unable to use a Wireless network.
(In reply to sturmvogel from comment #3) > Fascinating. It is in the docs: > https://doc.mageia.org/installer/9/en/content/locale.html#selectCountry (In reply to sturmvogel from comment #4) > Quote: > > Select your country or region. This is important for all kinds of settings, > like the currency and wireless regulatory domain. Setting the wrong country > can lead to being unable to use a Wireless network. That make that not being a mandatory step in the installation/update workflow, even worst, in the part that is located right is not useful with the new crypto-policies-script, if you select add repositories in https://doc.mageia.org/installer/9/en/content/software.html you will find that some packages will not install and let you with no other choose to back to select not use additional repositories, and this is with just "few days" after the alpha 1 round 2 ISOs, I don't want to think if you try to install Mageia 10 after N months of his release(when be released).
(In reply to sturmvogel from comment #3) > Fascinating. It is in the docs: > https://doc.mageia.org/installer/9/en/content/locale.html#selectCountry Indeed. But it is true that you have to specifically choose to configure the timezone etc. In that sense it is optional: you can easily overlook it: "DrakX presents a proposal for the configuration of your system depending on the choices you made so far...You can check the settings here and change them if you want by pressing Configure". I think what José is getting at is that this step should be in-line unavoidable, like our own and other distribuion Lives.
I just tried an upgrade from the Round 2 CI, but when I attempted to add supplemental network media before proceeding it failed with one of these bad signature messages. At no time before that was there any option for the user to set date and/or time. There was language, EULA, install or upgrade, keyboard layout, then do you have a supplementary medium. And when I select HTTP or FTP on the network, it fails when trying to install the basic software to access the network. Upgrades will never work properly unless this is fixed. Upgrading the bug to release blocker.
CC: (none) => andrewsfarmSeverity: normal => majorPriority: Normal => release_blocker
Created attachment 15260 [details] Fail installing packages
Created attachment 15261 [details] Bug information
(In reply to katnatek from comment #8) > Created attachment 15260 [details] > Fail installing packages (In reply to katnatek from comment #9) > Created attachment 15261 [details] > Bug information I fake the date in my system and here are the results This is a clean installation
As I guess change to a terminal Ctrl+Alt+F2 set the right date/time date --set="<day> <month abbreviation in english> <year> <hour>" The bad thing is you have to pass utc hour or include information after <hour> like CST in my case So the recommendation have to be "Check your internal clock is right before try an installation/upgrade with additional repositories" if this feature can't be implemented in mageia 10
For errata if not solved In retrospect, should probably have been in earlier erratas too.
CC: (none) => friTarget Milestone: --- => Mageia 10Keywords: (none) => FOR_ERRATA10
(In reply to Morgan Leijström from comment #12) > For errata if not solved > In retrospect, should probably have been in earlier erratas too. I add a note in release notes where is more useful than in erratas, feel free of create the errata or remove the for_errata keyword
Keywords: (none) => IN_RELEASENOTES10
Great, thanks. And thank you for editing release notes and errata, usually I have been doing most of errata last years but I like to step back :-)
Keywords: FOR_ERRATA10 => (none)
We seem to agree that setting date/time is an essential step. It is currently offered only by the 'summary' screen, which clearly most users heed. Many other distributions - and I think our own Live ISOs - make it one of the initial installation steps. This bug is really an enhancement request for the Classic installer. It is not a release blocker. The fact is noted in ERRATA for the moment. For us, it basically means inserting an extra step early in the installation, copying (not moving) the code from its current placement; but leaving the relevant Summary screen & processes UNchanged. Assigning to tools for the Installer.
Assignee: pkg-bugs => mageiatoolsCC: lewyssmith => (none)Priority: release_blocker => High
I labeled this a release blocker when I thought it was what was blocking adding supplementary media for a Mageia9 to 10 upgrade with the 10alpha1 CI iso. It would seem that wasn't the case. I still have trouble adding supplementary media, but not because of this.
Change keyword to flag status
Keywords: IN_RELEASENOTES10 => (none)Flags: (none) => in_release_notes10+
The Configure Timezone screen does not set the date and time in the installer, it configures the timezone for the installed system and allows you to enable a NTP daemon (which will only start when you reboot into the installed system). It is an optional step because for new installs the installer guesses the correct time zone based on your language choice and for upgrades it reads it from the system being upgraded. So making this screen a mandatory step at the start of installation would not help to set the installer date and time. My best guess is that katnatek's problem arises from a dead battery on his motherboard which means the real time clock chip forgets the time when the machine is switched off.
CC: (none) => mageia
(In reply to Martin Whitaker from comment #18) > The Configure Timezone screen does not set the date and time in the > installer, it configures the timezone for the installed system and allows > you to enable a NTP daemon (which will only start when you reboot into the > installed system). It is an optional step because for new installs the > installer guesses the correct time zone based on your language choice and > for upgrades it reads it from the system being upgraded. So making this > screen a mandatory step at the start of installation would not help to set > the installer date and time. > > My best guess is that katnatek's problem arises from a dead battery on his > motherboard which means the real time clock chip forgets the time when the > machine is switched off. 1. My bios battery is fine, you miss the part where I say I have to put a bad date in my system to reproduce this reliably. 1.1 I get this randomly in guest installations in gnome-boxes, I guess, sometimes the guest system not get the right info from the host, but that is other history 2. Start an installation with bad time/date in the machine is not uncommon. 3. The guess of the country/time zone could be Bad for some users, I talk Spanish but not live in Spain neither my time zone is in Madrid. 3.1 Set the country to Mexico, change the time zone to Mexico City that is fine for me, but we have other time zones. 3.2 I not believe that is the only language where similar things happen, I can think in English & French 3.2 Set the time zone, allows selecting between UTC & local time, give you a more accurate date/time, that allows to make an update if you could not install additional packages in https://doc.mageia.org/installer/9/en/content/software.html and back to use only the repositories in the installer.
Please, one issue per bug report. You are talking about two separate issues. The summary of this bug report is wrong - it is not an incorrect time zone that causes authentication failures, it is an incorrect system clock. Changing from UTC to local time is not going to make a significant difference. Making setting the time zone a mandatory step should be a new feature request. I'm not greatly in favour. For a lot of users, where the installer guesses right, that would be at least one more screen to click through (two if we keep the current implementation). And for the users where the guess is wrong, they already have the ability to correct it at the summary screen.
(In reply to Martin Whitaker from comment #20) > Please, one issue per bug report. You are talking about two separate issues. > The summary of this bug report is wrong - it is not an incorrect time zone > that causes authentication failures, it is an incorrect system clock. > Changing from UTC to local time is not going to make a significant > difference. > > Making setting the time zone a mandatory step should be a new feature > request. I'm not greatly in favour. For a lot of users, where the installer > guesses right, that would be at least one more screen to click through (two > if we keep the current implementation). And for the users where the guess is > wrong, they already have the ability to correct it at the summary screen. It's the same issue just with 2 causes, but forget VM on gnome-boxes You can add a checkbox in the screen of connection success or in the repository selection, then the action still be present in the main flow of a clean installation for people that need set country and time zone early. As I say before if you start with a bad date/time value then you get the comment#10 errors and the summary is too late to fix that without have to back to use just the ISO repositories, then fix that in the summary step & choose to update
I think the issue is the installer assume the machine time is in UTC Or Is my impression when I get this in real hardware and run date in one terminal I set the date/time at same value but adding CST, and I can continue
(In reply to katnatek from comment #21) > As I say before if you start with a bad date/time value then you get the > comment#10 errors and the summary is too late to fix that without have to > back to use just the ISO repositories, then fix that in the summary step & > choose to update As I said in comment 18, if you change the timezone at the summary screen, that only changes it for the installed system, it doesn't affect the running system. So I would still expect failures if you try to install updates after the summary screen. We would have to change the installer to also update the system clock. (In reply to katnatek from comment #22) > I think the issue is the installer assume the machine time is in UTC Yes, because that is the convention for Linux. But if you dual-boot Windows, it is harder to achieve. You are seeing these failures a lot at the moment because cauldron is still unstable, and there's a good chance you'll be trying to install updates that were only created a few hours before (i.e. within the difference between your local time and UTC). It won't be so bad after Mageia 10 is released. Still, I'm becoming more persuaded we should move the timezone setting step, but it is a big change to the installer.
(In reply to Martin Whitaker from comment #23) > (In reply to katnatek from comment #21) > > As I say before if you start with a bad date/time value then you get the > > comment#10 errors and the summary is too late to fix that without have to > > back to use just the ISO repositories, then fix that in the summary step & > > choose to update > > As I said in comment 18, if you change the timezone at the summary screen, > that only changes it for the installed system, it doesn't affect the running > system. So I would still expect failures if you try to install updates after > the summary screen. We would have to change the installer to also update the > system clock. At less in one test it helps > > (In reply to katnatek from comment #22) > > I think the issue is the installer assume the machine time is in UTC > > Yes, because that is the convention for Linux. But if you dual-boot Windows, > it is harder to achieve. > > You are seeing these failures a lot at the moment because cauldron is still > unstable, and there's a good chance you'll be trying to install updates that > were only created a few hours before (i.e. within the difference between > your local time and UTC). It won't be so bad after Mageia 10 is released. > Not too different to a recent package moved from updates_testing to updates > Still, I'm becoming more persuaded we should move the timezone setting step, > but it is a big change to the installer. Yes I not wait is done for Mageia 10 Release, I change the Milestone
Target Milestone: Mageia 10 => Mageia 11
Flags: (none) => in_errata10+
OK, I've prepared and tested a patch to the installer that asks for the user's timezone and HW clock setting immediately after the Install/Upgrade question (so that it can read the existing settings on upgrade). It still asks the questions on upgrade in case the existing settings are wrong (a wrong HW clock setting could be masked if the system is running chronyd or ntpd). Do we want to get this into Mageia 10? It will mean the installer documentation needs updating.
(In reply to Martin Whitaker from comment #25) > OK, I've prepared and tested a patch to the installer that asks for the > user's timezone and HW clock setting immediately after the Install/Upgrade > question (so that it can read the existing settings on upgrade). It still > asks the questions on upgrade in case the existing settings are wrong (a > wrong HW clock setting could be masked if the system is running chronyd or > ntpd). > > Do we want to get this into Mageia 10? It will mean the installer > documentation needs updating. If it is possible, that will avoid the issue in this side at less
(In reply to Martin Whitaker from comment #25) > OK, I've prepared and tested a patch to the installer that asks for the > user's timezone and HW clock setting immediately after the Install/Upgrade > question (so that it can read the existing settings on upgrade). It still > asks the questions on upgrade in case the existing settings are wrong (a > wrong HW clock setting could be masked if the system is running chronyd or > ntpd). > > Do we want to get this into Mageia 10? It will mean the installer > documentation needs updating. WDYT Marja?
Flags: (none) => need_info?(marja11)
Good to get into documentation, but i think this improvement should get implemented even if it risk not being documented right now. It is self explanatory, and fixes problems.
(In reply to Martin Whitaker from comment #25) > OK, I've prepared and tested a patch to the installer that asks for the > user's timezone and HW clock setting immediately after the Install/Upgrade > question (so that it can read the existing settings on upgrade). It still > asks the questions on upgrade in case the existing settings are wrong (a > wrong HW clock setting could be masked if the system is running chronyd or > ntpd). > Sounds good, thanks! (In reply to katnatek from comment #27) > (In reply to Martin Whitaker from comment #25) > > > > Do we want to get this into Mageia 10? It will mean the installer > > documentation needs updating. > > WDYT Marja? I think it should go into Mageia 10, regardless of whether we manage to get the documentation updated or not and even of whether drakx-installer-help (the inline installer help) will work again. Note that Mageia 1 was released without any official documentation at all. There was no inline installer help, no inline MCC help and there were no manuals on our website. However, of course we should try to update our documentation! (In reply to Morgan Leijström from comment #28) > > It is self explanatory, and fixes problems. Indeed _______________________________________________________________________________ Will there be an anchor for a help text in that screen? If so, what would be the best text? "Please make sure your hardware clock and time zone settings are correct. Not doing so can lead to various problems ranging from... to..." (please fill that in, I'm confused. Will the "user's timezone" only be about the time zone, or about the country + timezone? And the advise should be to always set the hw clock to UTC? Do we need to care about what Windows does with the hw clock? I mean, does anyone still manage to boot into windows after installing Mageia on a "Windows with secure boot" system? _______________________________________________________________________________ In https://doc.mageia.org/installer/9/en/content/misc-params.html The line about Timezone: "DrakX selects a timezone for you, depending on your preferred language. You can change it if needed. See also Configure Timezone" Will need to be changed into: "If you made a mistake when configuring your time zone (right after deciding to install or upgrade), then you can correct it in Configure Timezone." Is that correct and are more changes needed? _______________________________________________________________________________ Already CC'in doc-bugs and i18n-bugs, so they'll be prepared.
CC: (none) => doc-bugs, i18n-bugs, marja11Flags: need_info?(marja11) => (none)
(In reply to Marja Van Waes from comment #29) > _____________________________________________________________________________ > __ > > Will there be an anchor for a help text in that screen? > > If so, what would be the best text? > > "Please make sure your hardware clock and time zone settings are correct. > Not doing so can lead to various problems ranging from... to..." What about only mentioning: "Not doing so can make it impossible to connect to various websites, including of your bank and hospital." ? > (please fill that in, I'm confused. Will the "user's timezone" only be about > the time zone, or about the country + timezone?
(In reply to Marja Van Waes from comment #29) > Will there be an anchor for a help text in that screen? It will present the same two screens as you currently see if you click on the Timezone Configure button in the summary stage. The first of those screens doesn't currently have any help text, but the second one does. > If so, what would be the best text? > > "Please make sure your hardware clock and time zone settings are correct. > Not doing so can lead to various problems ranging from... to..." The new problem that resulted in this BR is that rpm is now more strict when it validates the RPMs before installing them, and will refuse to install any package that appears to come from the future. This is particularly a problem for users in the Americas, where there is a large positive offset from UTC. It is possible for freshly built updates to propagate to the mirrors in less time than that difference from UTC. For a fresh install, the installer doesn't know whether the hardware clock is set to UTC or local time, so it assumes UTC (which is the recommendation for Linux systems, but not for Windows). If the hardware clock is actually set to local time, then the installer's clock could be out by many hours, and hence any packages fetched from supplementary network media, or as updates at the end of installation, could wrongly appear to have dates in the future. > (please fill that in, I'm confused. Will the "user's timezone" only be about > the time zone, or about the country + timezone? It's only about the timezone. The installer will guess the country from the language choice, and the user has the ability to correct that at the summary stage, as before. > And the advise should be to always set the hw clock to UTC? No, the advice should be to select the option that shows the correct time. That allows the installer to correct its clock. I think it would be good advice to change the hardware clock to UTC after installation (with the caveat about Windows) > Do we need to care about what Windows does with the hw clock? I mean, does > anyone still manage to boot into windows after installing Mageia on a > "Windows with secure boot" system? Not sure, as I only run Windows 10 in VirtualBox. > _____________________________________________________________________________ > __ > > In https://doc.mageia.org/installer/9/en/content/misc-params.html > The line about Timezone: > > "DrakX selects a timezone for you, depending on your preferred language. You > can change it if needed. See also Configure Timezone" > > Will need to be changed into: > > "If you made a mistake when configuring your time zone (right after deciding > to install or upgrade), then you can correct it in Configure Timezone." > > Is that correct and are more changes needed? That is correct. I thought it nice to still show the timezone at the summary stage, and give the user a second chance.
P.S. if you want a help text anchor in the screen that displays the list of time zones, I can try to add one.
commit 25f74ddb44213151a7547149e37b0b69a8308ff8 Author: Martin Whitaker <mageia@...> Date: Tue Jan 13 17:27:33 2026 +0000 installer: ask for user's timezone at the start of installation (mga#34909) This allows us to set the system clock to the correct time. This is needed to prevent rpm verification failures when very recently built packages are fetched from network media. The new Sequoia PGP backend rejects packages that appear to have been signed in the future. --- Commit Link: https://gitweb.mageia.org/software/drakx/commit/?id=25f74ddb44213151a7547149e37b0b69a8308ff8
Implemented in drakx-installer-stage2-18.72-1.mga10. Can be tested with the netinstall ISOs when that version reaches the mirrors.
I test and is working Thank you very much I'll update the notes in the wiki and when next round of ISOs be ready we can close this
Updated wiki information, until release of next round of ISOs I'll not remove the Erratas Information
Target Milestone: Mageia 11 => Mageia 10
(In reply to Martin Whitaker from comment #32) > P.S. if you want a help text anchor in the screen that displays the list of > time zones, I can try to add one. Thanks, it works. Just saw the screen: a list of cities in various time zones. If one shouldn't select Algiers instead of Amsterdam, or Perth instead of Beijing, because of things like default paper size (legal or A4), the currency and wireless regulatory domain, then it would be good to have a help text anchor. (In reply to katnatek from comment #35) > I'll update the notes in the wiki and when next round of ISOs be ready we can > close this Thanks!
commit 12ad753d9a26261fac9b77a381c74e1ede06544f Author: Martin Whitaker <mageia@...> Date: Sat Jan 24 18:28:08 2026 +0000 installer: add help text anchor to timezone selection screen (mga#34909) --- Commit Link: https://gitweb.mageia.org/software/drakx/commit/?id=12ad753d9a26261fac9b77a381c74e1ede06544f
(In reply to Mageia Robot from comment #38) > commit 12ad753d9a26261fac9b77a381c74e1ede06544f > Author: Martin Whitaker <mageia@...> > Date: Sat Jan 24 18:28:08 2026 +0000 > > installer: add help text anchor to timezone selection screen (mga#34909) > --- > Commit Link: > > https://gitweb.mageia.org/software/drakx/commit/ > ?id=12ad753d9a26261fac9b77a381c74e1ede06544f This will require new translations?
(In reply to katnatek from comment #39) > This will require new translations? For now I have copied the configureTimezoneUTC.html help file to provide the new configureTimezone.html help file. When I read that file, I found it was actually more appropriate to the first screen (configureTimezone) than to the second (configureTimezoneUTC). So the documentation does need an update.
(In reply to Martin Whitaker from comment #40) > (In reply to katnatek from comment #39) > > This will require new translations? > > For now I have copied the configureTimezoneUTC.html help file to provide the > new configureTimezone.html help file. When I read that file, I found it was > actually more appropriate to the first screen (configureTimezone) than to > the second (configureTimezoneUTC). So the documentation does need an update. Thanks, Martin. I'll try to do a network iso installation, it is easier to update help files when looking at the screens they're about. DrakX-inline.xml (the file which includes the help files for the installer https://gitweb.mageia.org/software/i18n/tools/tree/docs/docs/stable/installer/en/DrakX-inline.xml) needs to be adjusted, too, not just the help files themselves. I haven't yet found Calenco's text editor, only the wonderful new Calenco wysiwyg editor, which is great to get an idea of what a publication will look like. However, I find wysiwyg editors confusing when writing or editing a file, it seems easier to update the English files in our git and then try to push them to Calenco, like is done with the translations.
We have a bug here The first time the hours are correct Local time, show right local time UTC time shows something else When you reach summary stage if you enter to configure the time zone You will find Local time, show other time, not the right UTC will show the value of the local time Screenshots tomorrow
Set timezone stage https://www.imagebam.com/view/ME1A3N2P https://www.imagebam.com/view/ME1A3N2Q Summary stage https://www.imagebam.com/view/ME1A3N2R https://www.imagebam.com/view/ME1A3N2S In the last image both times are wrong The value in UTC time should be in local time
In the laptop test, I just change country and reboot to installed system with the right hour So I think once is setup in first time is not necessary to double check the time zone in the summary stage
(In reply to katnatek from comment #42) > We have a bug here Fixed in git.
Added 10Beta1 Keyword
Keywords: (none) => 10beta1
(In reply to Marja Van Waes from comment #41) > (In reply to Martin Whitaker from comment #40) > > (In reply to katnatek from comment #39) > > > This will require new translations? > > > > For now I have copied the configureTimezoneUTC.html help file to provide the > > new configureTimezone.html help file. When I read that file, I found it was > > actually more appropriate to the first screen (configureTimezone) than to > > the second (configureTimezoneUTC). So the documentation does need an update. > > > DrakX-inline.xml (the file which includes the help files for the installer > https://gitweb.mageia.org/software/i18n/tools/tree/docs/docs/stable/ > installer/en/DrakX-inline.xml) needs to be adjusted, too, not just the help > files themselves. And drakLive.xml needs to be adjusted, the existing dx2-configureTimezoneUTC.png screenshot renamed to dx2-configureTimezone.png and a new dx2-configureTimezoneUTC.png from the UTC/NTP screen created. I've done all adjustments locally, apart from the work on the screenshots, but I'll double check tomorrow.
@ Yuri I think I'm done updating the needed xml and png files in Calenco. The changed English files are: The "inclusion" files: DrakX.xml DrakX-inline.xml DrakLive.xml And the regular files: configureTimezoneUTC.xml configureTimezone.xml locale.xml misc-params.xml They're not, yet, in git, something went wrong when I tried to push them.
CC: (none) => yurchor
commit e12cee24f635b440f8280679523f61dc0124918c Author: Marja van Waes <marja@...> Date: Sun Feb 1 09:15:43 2026 +0100 Add a file and modify others, date and time are now configured early (mga#34909) --- Commit Link: https://gitweb.mageia.org/software/i18n/tools/commit/?id=e12cee24f635b440f8280679523f61dc0124918c