Transitioning an existing alarm install to the new fedora

With the new distro announcement I am wondering what the process will be like to move over. Will the installer give the option of moving the current install to a asash_old directory or some such and then install the fedora version for instance in the existing partitions? Or are we basically deleting and starting completely from scratch?

I am not it a rush to do this transition, but having a little more knowledge of what to expect when I do is good.

I customized my install and while it isn’t a huge deal, it would be nice not to have to copy everything off(backups are good) and back on(annoyance) during migration.

1 Like

As with any other Linux distro change, unfortunately it’s a complete reinstall. You can, however, manually back up and restore your home directory to keep most of your files and settings.

In particular, both distros use different filesystems (ext4 vs. btrfs) and the way our installer works there is no easy way to do what you want even if the filesystem were the same. Plus we’re taking the opportunity to switch the default OS firmware version we use. It’s not completely impossible, but it would be a huge amount of development and testing for a one-off thing, so it’s not really worth it.

2 Likes

Ok, thanks for that info. I am not really familiar with the redhat distro variants(updating, building packages etc) so I am in no rush transition just yet, but will probably do it sometime this fall.

Regarding firmware, what is the process of updating it? I know that it can be updated in macOS simply by updating the computer, but is there currently a mechanism/method to update it in Asahi(either version) when that happens that doesn’t require a reinstall? Or is it mostly what was installed when you installed is what is installed?

To update system firmware you update macOS, but to update OS firmware for Asahi requires a reinstall of the boot components. It’s totally possible to do this in the installer, I just haven’t written the code for it yet. Your actual OS install would remain intact.

This will become important in the future when newer features (GPU stuff in particular) depend on newer firmware, but right now there is no reason to update yet.

The manual/hacky way is to back up your ESP partition contents, delete the stub and ESP partitions (keeping your OS root/boot), reinstall in UEFI stub only mode, restore the ESP partition contents, and fix any fallout from the changed partition UUID manually. But don’t do this: there is no reason to (other than for developers), and by the time there is reason to do it we’ll provide a proper tool for it in the installer.

The process will look something like first updating macOS, then launching the installer again from macOS or recovery mode, picking the upgrade option, then going through the same process as initial install (creating the stub, rebooting into recovery for the second step). After that you reboot back into your existing OS, now running on newer firmware.

As for launching system firmware updates directly from recovery mode or Linux, we’re not there yet. This is one of two reasons why you need to keep at least a small macOS install around. The other one has to do with machine authentication being tied to the macOS install for the time being (until we implement that). Once both of those two issues are figured out you should be able to completely remove macOS and rely on just Linux and recoveryOS for all your update needs.

2 Likes

Ok, good to know. Thanks for the detailed explanation.

Fedora not called firmware usually, and as you can see it confuses people when that term is used. Commonly its called software.

Firmware is the code that goes into bits of hardware to make them work with the OS software and the code to boot the OS, like the EFI BIOS.

Hector was not referring to Fedora as firmware. The firmware handling on Apple silicon is different than on other systems. The firmware is not redistributable but this is not a problem as the devices come with the firmware.

There are two sets of firmware(s): the system firmware and the OS firmware. The system is required for the bootloader and is common for every OS installation on a system. the OS firmware(s) are bound to specific OS installations (different macOS versions, Fedora). The OS firmware(s) are only updated when this specific OS is updated.

Apple presumably does this to avoid keeping the firmware compatible with drivers from previous releases. They still have to do that for the system firmware(s) but that is a much smaller set.

The os firmware is the EFI modules that are in /boot on an x86 Fedora system?
The shim, grub etc?

It’s all firmware for devices. The only difference is where the firmware is stored and who loads the firmware.

  • System firmware is global per system and loaded by the bootloader.
  • OS firmware is stored on each macOS / Linux installation but still loaded by the bootloader.

Part of these firmware(s) would be in an eeprom or loaded by the BIOS/EFI on a classic PC. We still have some classic device firmware like linux-firmware which is loaded by the OS.

I find that backing up and migrating to a wholly new system is always a good thing - it forces me to identify which files I care about, take an inventory of packages I use, and move my dotfiles to GitHub. It’s like moving to a new house - you get rid of a lot of junk, and organize the rest.

No, OS firmware is part in the APFS stub partition, and part in the vendorfw subdirectory of the EFI partition. Both are unique concepts for Apple machines and have nothing to do with standard Fedora/etc components used on other systems.

1 Like

Thanks for the background explanation.

I took the plunge a few days ago and migrated to Fedora Asahi Remix on my Mac Studio.
It was surprisingly smooth and everything works beautifully.

1 Like

FYI, there’s no need to expand macOS back if you are just switching (and want the same allocation, so you’re going to resize it again). The installer will happily install into existing free space :).

Also the “OS Name” isn’t the hostname, it’s the volume name, which determines what you see in the Boot Picker and macOS (it’s the volume name of the APFS stuff). Linux actually can’t see it at all, you get to pick the hostname later in setup.

The main reason for the disclaimer about things not being ready yet is that we’re still poking around stuff, so it’s entirely possible that users that install early will encounter breakage with updates or have to manually install/fix stuff, etc. We’re only committing to mostly seamless upgrades after the release :slight_smile:

1 Like

Thanks! I modified the blog post to fix those two things :slightly_smiling_face:

I’m not sure what I was thinking about the hostname since I remember having to set it in /etc/hostname afterwards (it must have been my burning desire to include an xkcd comic reference ;-). But I do remember thinking to myself that I should probably give Fedora Asahi Remix more than 500GB, but then decided against it after reallocating the freed space because 500GB has been far more than what I need, and I still have to occasionally boot back into macOS to teach iOS development and Adobe courses that chew up an insane amount of storage.