I want to switch from Windows 11 to Fedora KDE Plasma. Although I have a computer science studies background, I never worked with Linux and I’m also not very into “SysAdmin” things yet, so really new field for me.
For the time being, I want to run a dual-boot setup on the same SSD drive before potentially switching completely. As far as I have read online, dual-boot setups work fine if Windows is installed first, then the Linux system. Eventually it might happen, that Windows will screw the bootloader, but then it is quite easy to fix by booting from a Live Version and repairing it.
As of now I have a 2 TB SSD Kingston drive where about ~ 500 GB are dedicated right now for Windows 11. So I want to use the same SSD drive to now install Fedora KDE Plasma. As this install is done while Windows already installed, this should be fine for the dual-boot setup.
I would like to ask the following questions:
How much space will I realistically need for my setup? Another 500 GB and I’m safe for the next years? : ) Can I choose how much GB I want to allocate for the installation in the installer? Or will it just take all the free space by default?
When installing Fedora on the same SSD, do I need to change something in BIOS in order to boot from the Fedora partition first? (So Grub will show up)
By default Fedora will use BTFRS right? I guess I will be fine with it if I don’t have special requirements right now?
I will have about 1 TB of unused SSD space left after the installation. I guess I can partition it later through Fedora and mount it to use it if necessary?
You may want to provide a partition shared by Windows and Linux. Linux can usually read NTFS, but writing to NTFS risks encountering changes Microsoft may make in the future.
There is the option to install Fedora in WSL2. Many “large enterprises” that don’t allow users to install linux on their workstations do allow users to run Fedora in WSL2. This allows you to decide if you can do without Windows or possibly use Windows in Linux VM rather than dual booting.
By shared partition you mean I could mount a HDD/SSD NTFS drive (already used in my Windows11 environment) within Fedora and also use it. At least this would make copying some files easier. I have a second drive with 2 NTFS partitions used by Windows, but just “normal” stuff and no system related things, so plain “storage”.
As for WSL2, I think I will just go with dual boot for some time, I dont think I will encounter so any issues. Thanks anyway for pointing out that possibility.
Anaconda will actually set up Fedora to assume the RTC is in local time, if it finds a Windows installation on the disk. (I raised bug 2374173 to request a user override for this.)
At my workplace, there’s an in-house desktop app where the users were reporting mysterious data sync issues. It wasn’t until our software development team mentioned that the clocks between the Windows workstations and the servers connected over 30+ miles of network fiber absolutely had to be no more than about 1-2 minutes difference, preferably much less.
Although all of the Windows workstations were online 24/7 with sleep/hibernate disabled, no two desktops had the same time (none were within 2 minutes; one was off by almost 10), unlike the lone Linux desktop that was off by only a few microseconds.
The primary problem is that Windows desktop editions from XP onwards default to a NTP polling interval of 604,800 seconds (7 days). In contrast, on most Linux distros, chrony defaults to a polling interval range of 64-1024 seconds and also compensates for local RTC drift.
I’ve got an old personal Window 7 PC that was fine for years, but over time the RTC has slowly drifted more and more with age. So like my workplace workstations, I disabled the Windows NTP client, replacing it with the more flexible open-source NetTime.
Maybe that is true today, but when I installed fedora on my new laptop (with windows 10) the RTC time was already set to UTC and fedora happily accepted that.
I have 2 different laptops with win10 and fedora dual booting and the time is not messed up. With win11 however it seems windows wants the RTC to be local time and causes a 5 hour discrepancy every time I switch from fedora to windows.
I used the command given by @gadget above and the problem was solved for win11.
(I mentioned in the bug report that the current logic is not completely predictable, which is another reason to let the user set it explicitly at install time).
The Windows “Enterprise” 10 laps issued at work with customized configurations were set to UTC, and also had better WiFi cards than the consumer versions of the same model.
I assume vendors selling systems with windows pre-installed can configure them to use UTC.
My laptop with win10 worked properly, but when I upgraded to win11 I was forced to make the mentioned entry in the registry to eliminate the time problem with windows.
I think it is completely predictable. Win10 does not mind using UTC on the RTC. Win11 forces the user to use local time on the RTC unless a registry entry is added/changed to support UTC.
I mean that the default applied by Anaconda is not easily predictable.
Both the machines I used already had Windows 10 on them [not 11] and the Windows installations had already been set up to use UTC for the RTC, so a Windows 10 vs 11 difference wasn’t responsible.
Importantly, nothing in the Anaconda code attempts to look inside the Windows installation and figure out whether the installed Windows is actually using UTC for the RTC (or even check which version of Windows is in use).
Anaconda sets the UTC or local flag in hwclock in the function time_initialize(). This uses the function bootloader_proxy.DetectWindows() to guess whether a Windows installation is present or not. If Anaconda thinks Windows is present, it uses local time for the RTC; if it thinks Windows isn’t present, it uses UTC.
That DetectWindows() works by (1) searching for NTFS partitions on the target device and then (2) checking whether any of them pass the tests in is_valid_stage2_device() (subclass implementation here, but a lot of the logic is in the superclass implementation here).
I haven’t stepped through all of the logic in the superclass implementation there, but it depends on various details of the low-level setup and seems like it would be pretty fragile to small changes in the details of how the disk is set up.
To do everything correctly, Anaconda would need to answer two questions:
Is Windows already installed?
Does the Windows installation use UTC or local time for the RTC?
As it is, it doesn’t even attempt to ask (2), and it doesn’t seem to answer (1) reliably.