Booting on Firewire (IEEE1394) broken in Fedora

Question

Something prevents booting on Firewire (IEEE1394) in Fedora 36 (kernel 5.19.6-200.fc36.x86_64).

Fedora hangs for long here:

The final output of the Dracut Emergency Shell:

I have the log /run/initramfs/rdsosreport.txt (1843 lines). Extract:

mac2011-linux% cat '/media/alba/sauve/rdsosreport.txt' |grep -E "fw|firewire"
[    2.786192] fedora kernel: firewire_ohci 0000:04:00.0: added OHCI v1.10 device as card 0, 8 IR + 8 IT contexts, quirks 0x0, physUB
[    3.290214] fedora kernel: firewire_core 0000:04:00.0: created device fw0: GUID a4b197fffe435f8e, S800
[    3.291200] fedora kernel: firewire_core 0000:04:00.0: phy config: new root=ffc1, gap_count=5
[    8.368893] fedora kernel: firewire_core 0000:04:00.0: created device fw1: GUID 0030e002e0011462, S800

ls /lib/modules/5.19.6-200.fc36.x86_64/kernel/drivers/firewire returns firewire-core.ko.xz firewire-ohci.ko.xz.

modprobe -c|grep fw returns a score of lines like alias symbol:fw_bus_type firewire_core.

I have tried four SATA devices (3 SSD and one rotative), three Macbook pro (2009, 2010, 2011), two different Firewire interfaces and two different cables.

No problem when the device is attached internally on SATA or for booting Mac OS X El Capitan or Sierra. It also works with Ubuntu (kernel 5.15), although I have observed ocasional failures.

The problem is proper to Firewire and Fedora.

It can be reproduced neatly as follows:

1. Make a fresh install of Fedora with one HFS+ partition for the EFI file system and one Ext4 partition for the root file system.
2. Boot this new installation internally.
3. To prove that a Firewire driver is installed, check that you can mount another device on Firewire, or, if you do not have another device, watch modprobe -c|grep firewire.
4. Try to reboot on Firewire. It will fail after the Plymouth stage (press escape when you see the Fedora logo to see the log).

Can somebody reproduce or help fix?

Answer 1

So you're in the emergency shell of the initramfs phase of the boot process. That means: the firmware has loaded GRUB and then GRUB has loaded the kernel and initramfs and started the kernel. At this point, the system has basically one goal: to get the real root filesystem mounted. To do that, the initramfs file can contain kernel modules to support any necessary hardware, and scripts to perform any necessary set-up. Once the root filesystem is mounted, the real process #1 binary will be executed, and will replace the temporary one provided within initramfs, and that process will decide how the boot process will continue.

The messages in your pictures indicate that the kernel has successfully loaded the firewire-core module, and detected the presence of a Firewire device. However, the core module needs another module, firewire-sbp2 to support Firewire-based storage devices.

In your case, the initramfs apparently does not include the firewire-sbp2 module (assuming that your firewire-spb2 in the comments was just a typo in the comments and you typed the modprobe command correctly). That module is needed to support Firewire-based storage devices. So the missing module is the most likely reason why your Firewire-based boot fails: without that module, the kernel won't be able to access a root filesystem that is located on Firewire storage, and since no other filesystems have been mounted yet, initramfs is the only place the kernel is able to access at this early stage of the boot process.

Initramfs files are initially created whenever a new kernel version is installed (assuming that particular kernel is configured to need/use one). An initramfs file is specific to the kernel version it is built for, and may or may not be somewhat bespoke to the system it was built in, depending on the initramfs generator process your distribution uses: some initramfs generators identify the driver modules required to access the root filesystem when initramfs is being created, and include only the necessary modules to keep the size of the initramfs file small.

So, if your initramfs file was created while the disk was connected via SATA, the Fedora initramfs creator (dracut) may have omitted the Firewire storage support module: "Since the root filesystem is not on a Firewire disk, I see no need to add this module to the early boot procedures. If needed later, it can be automatically loaded from /lib/modules once the root filesystem is mounted."

If you are in the habit of moving system disks between SATA and Firewire, you might need to tell the initramfs creator to always include the firewire-sbp2 module to initramfs, even if it doesn't seem necessary at the time.

For dracut, you can do this persistently by creating a *.conf file in /etc/dracut.conf.d/. For example, you might name it /etc/dracut.conf.d/01-always-include-firewire-storage.conf. It would need to contain the following line:

add-drivers+="firewire-sbp2"

(Since the files in /etc/dracut.conf.d/ are processed according to an alphanumeric order of their names, there is a convention to add a two-digit prefix to the filenames to make the ordering explicit.)

Once this file has been added, you'll need to rebuild your initramfs file. To do it for the current kernel, you might need to type only

dracut --force

To do it for a different kernel version, the command would be:

dracut --kver <kernel version> --force

The --force option is needed to overwrite an already-existing initramfs file.