"Use the same regional options as this user's" fails to set time zone #2499
Comments
|
I'm going to need the beginning and end of the log. You can truncate a bunch of "Copying" messages, but I do need to see pretty much all of your log outside of this. You can also zip the file and attach it to the issue. Or you can split it over multiple posts. There are more than one way to provide a log, even if GitHub says it's too large to copy/paste. |
|
Ok, so I replaced the GUIDs and the username, the Extracting-Creating-Lines and the Lines about all the drives that are detected. As it might cause canfusion: I did a first run with another Win10 ISO that included the bad block check. During the check I noticed I picked the wrong but I waited for the bad block check to finish before I aborted. I removed that part from the log. The checkdisk is in German, it says "no problems found, no actions required" Log |
|
Well, duplicating the regional options does not implicitly mean duplicating the timezone settings, and the explicit purpose of Rufus with this is to avoid the user being interrupted by the installation process to select its regional options. So, the fact that it applies a timezone that is decided by the default regional option and might not be the actual one the user wants is outside of the actual design goals of Rufus with this feature, which means that we don't really have a reason to want to address this (since again, our goal is to shortcircuit any element that make the Windows installer prompt the user instead of pressing forward with the installation, so that the user can get to a fully installed and running Windows, that they can then finish customizing to their liking). But I hear you. It would be nice if the timezone could also be duplicated when the user selects to duplicate the regional option, so, considering that there is an answer file setting that does just that, I'll see what I can do (though I have to state that, since Windows requires the use of crappy designators such as |
pbatard
changed the title
|
Well, regional settings of the creating OS were Germany, German keyboard, timezone Germany, German language, German regional format - its no non-default combination like German keyboard and Australien timezone. The IoT ISO does not provide German language, of course, but keyboard was set correctly and so was the country and the regional format. I do not expect anything and I am thankful for rufus (without it I might have to use shitty tools like balenaEtcher or even pay for an other tool), I just wanted to let you know because I thought this was clearly a bug. If timezone is not part of "regional options" I just suggest to mention this when the option is shown to the user (like "Use the same regional options as this user's (timezone not included)" or similar. I assume that many people expect that timezone is an "regional option" You removed the "Windows 10 IoT Enterprise LTSC 2021" from the title, are you sure that this does apply to non-IoT ISOs as well? It's been a while since my last Win 10 Pro Windows To Go, but I do not remember that I had to set the timezone in Windows to Go back then - but I may be wrong about this. Or maybe each ISO has a default timezone and for the en IoT Enterprise that is a US timezone and for the German Pro ISO that is timezone Germany so maybe Rufus did not tranfer the setting but as the default timezone of the ISO happens to be the one of the creating host OS I did not notice that it did not do that. |
Yes, because if I set timezone for nonstandard region for non IoT (e.g. German region with Australian timezone), then regardless of whether this was an IoT issue (which I will NEVER look into) or not, this will either get fixed for IoT, or this is a pure Windows bug that will have nothing to do with Rufus in the first place. All Rufus can do is set region/timezone settings from the answer file. If that doesn't work, then it means that it's a Windows issue with how it processes answer files (since I'm pretty confident Rufus does set it exactly as Microsoft documents) and not a Rufus issue. As such, the part about it not working for IoT or Windows To Go becomes irrelevant, and the only part I am planning to look into, since it's not something Rufus is doing right now, is carry the timezone settings from the user when they select to use the same regional options and, outside of trying to keep issue titles short (because a title shouldn't be the place to give specifics, but to briefly summarize the nature of the problem), that's why I changed the title to something more digestible. |
|
TimeZone replication is a feature that will be part of the next Rufus release. |
|
Awesome just another time. Thanks! |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
Checklist
<FULL LOG>below.Rufus version: x.y.z- I have NOT removed any part of it.Additionally (if applicable):
(✓)button to compute the MD5, SHA1 and SHA256 checksums, which are therefore present in the log I copied. I confirmed, by performing an internet search, that these values match the ones from the official image.Issue description
As the log is huge an I am supposed to not redact it I did not provide it - feel free to close this because of this, but I wanted to let you know about this:.
Using "Use the same regional options as this user's" for Windows 10 iOT Enterprise LTSC 2021 (windows To Go) did correctly set the keyboard layout, but it failed to set the timezone correctly.
The iso name is en-us_windows_10_iot_enterprise_ltsc_2021_x64_dvd_257ad90f and I verified the checkums via heidoc.net
Rufus x64 v4.4.2103 (Portable)
Log
The text was updated successfully, but these errors were encountered: