Hang with Kernel Starting on Raspberry Pi

Since I always seem to be bugging you guys, I made sure to donate to the project once again. I appreciate IPFire and this team!

I moved around my networking in my house. Doing that makes it possible for me to relatively easily connect to my Raspberry Pi 4b+ via serial console. To that end, I started testing that out with a test device and I’ve run into a hang after the “Kernels starting…” message. I downloaded the latest version, flashed the SD card, made the boot image changes, but kept serial console enabled instead of my usual change to turn it off. From the serial console, I see it booting up until it hits that message. (I will include the full console output below). On a whim, I connected a monitor and when I see that message on the console, I see a “dracut:/#” prompt on the monitor.

I also see this in the console log, but I don’t know if this is “normal” or not. I’m not currently in a situation to be able to reboot my active IPFire instance:

Unknown command 'bootz' - try 'help'

Thanks for any help or pointers.

U-Boot 2022.10 (Apr 14 2024 - 20:27:15 +0000) RPi4 - IPFire.org

DRAM:  3.9 GiB
RPI 4 Model B (0xc03114)
Core:  205 devices, 16 uclasses, devicetree: board
MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In:    serial
Out:   vidconsole
Err:   vidconsole
Net:   eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
scanning bus xhci_pci for devices... 2 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2820 bytes read in 14 ms (196.3 KiB/s)
## Executing script at 02400000
113 bytes read in 11 ms (9.8 KiB/s)
Load uEnv.txt...
Set console to ttyAMA0,115200n8
29479424 bytes read in 1245 ms (22.6 MiB/s)
38069 bytes read in 34 ms (1.1 MiB/s)

42074240 bytes read in 1776 ms (22.6 MiB/s)
Ramdisk loaded...
Unknown command 'bootz' - try 'help'
Moving Image from 0x80000 to 0x200000, end=1ec0000
## Loading init Ramdisk from Legacy Image at 02700000 ...
   Image Name:   
   Image Type:   AArch64 Linux RAMDisk Image (lzma compressed)
   Data Size:    42074176 Bytes = 40.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff3700
   Booting using the fdt blob at 0x2eff3700
   Loading Device Tree to 000000003df27000, end 000000003df368f1 ... OK

Starting kernel ...

I continue to have this problem unfortunately. I just cloned my previous IPFire (version 184) SD card that had been running in my firewall prior to my upgrade to 185. I updated the uenv.txt to turn the serial console. I’m seeing exactly the same behavior with that card as well, so at least I know it isn’t the preparation of my current card that is at issue.

Does anyone have any suggestions or things to try?

Another quick update. I think that maybe the device is actually started, but I’m not getting the console messages out through the serial console. As I was poking around from the “dracut” prompt, it appears it is a running Linux system at this point. I had to attach a monitor and keyboard to realize that fact, but that is certainly different than thinking the kernel isn’t starting at all.

If you are getting the messages via the hdmi & usb that suggests that you have modified the uENV.txt file for hdmi instead of serial as per the Note: section in the documentation page for the RPi 4B


Are you trying to have the RPi 4B work from both the hdmi and the serial at the same time?

Are you on two different RPi4B?

I was not intentionally trying to enable both at the same time. I just plugged in my monitor when it seemed like it wasn’t doing anything after showing the “Kernel starting…” message. My uEnv.txt is default:


I didn’t add an enable_uart=1 line to the config.txt file because it was already there by default.

Is there something else I’m missing?

Then I can’t help any more. I don’t use RPi with IPFire at all so I have no experience of the setup required.

I was just going by the comments in the documentation about serial and hdmi which made me think you could have one or the other but not both. However, I could easily be wrong on that.

Hopefully people who actually use RPi with IPFire can give you more input.

I do have two. I have an active one and a separate one that I decided to use to test serial console. I actually recently swapped, so the active firewall is the new device and the test device is the older one. I’m finding I still need to make the boot.scr changes and rebuild the image for both, so they are behaving the same way from that perspective.

The only thing that came to mind is that they are different revisions. The older Revisions should work fine and the newer Revisions need some help.

Do you know what Raspberry Pi Revision is the device that does not work?

1 Like

Thanks for the thoughts. Unfortunately, I think I was the person that originally reported that problem, so I’m painfully aware :slight_smile: From what I can tell, both my Pi’s are these revisions.

I have a routine now for creating new SD Cards with each new IPFire version where I follow the instructions and build the new image. In this case, I went through the process of creating a new SD Card, but did not do my usual step to disable the serial console. I left serial console ON and validated that enable_uart was also enabled.

I will keep digging on this, but if anyone else has any suggestions, I’d love to hear them!

and both devices have the same issue?

Does the CU 184 version still exist and does that work?

When you went from CU 184 to CU 185 did you do a backup and pakfire type upgrade? Or did you start over with a new SD?

I may be confusing things and, if so, apologies. I have two Pi4B’s involved:

  • One that is currently my active IPFire instance running 185. That was brought up by using a fresh SD Card. I ran through setup and then restored a pakfire backup from 184. I am not currently testing anything with this Pi, but it has behaved the same as the other.
  • Second Pi4B+ device I’m using for testing out using a serial console rather than monitor/keyboard for management.

All of my tests have been with that second device. I’ve tried:

  • Fresh SD card setup of 185 with serial console enabled
  • Copy of previous (184) SD card that had been active before, but with serial console enabled

None of this is (thankfully) active right now. I had wanted to see how well it would work before trying to use it “for real”. At this point it has become a bit of me versus the computer :slight_smile:

Ahh. Got it! That helps! I thought you had a serial console that worked and then stopped working…

You may have run into the same issue I did - the serial console stopped working for me.

does this sound like your issue?

That’s it exactly!

Can you add what you found to the bug report? Any and all details. Hopefully @arne_f can take a look. I had trouble with the older Revisions 1.1 & 1.2. Please add your Revision numbers to the bug report.

This will help make sure the Development team (a.k.a. Arne) reviews this information.

Information to add a bug report in IPFire Bugzilla:

I will do that, but I’m going to do a bit more digging around before that. I’d like to see if I can get this going on any other OS and, if so, what that may tell us. Now that I know it isn’t me being stupid, I will see if I can figure anything else out.

1 Like

If you reach the dracut shell the kernel is already bootet. Looks like the uSD driver is not working. I have tested core185 on all my RPi’s but i have none of the newer hardware revisions. (have you tried to rename boot.scr to force the boot via grub instead of u-boot?)

I didn’t know about the trick to force grub. When I do that, I see grub/EFI do the boot, but the console is still over on the monitor and not on the serial connection. I see it boot to the login prompt on the monitor, so it is fully booted. It is just using the “wrong” console.

Any guesses as to what might be going on there?

Still digging, but no answers yet. I have been looking at a couple of different sites that may provide some help:

One thing I found interesting was in the Linux kernel documentation was this comment: It is because kernel tries to register graphical consoles before serial ones. Is this related? I have no idea, but it is interesting nonetheless.

If you boot the first time via grub there is a “serial console” option which reconfigure grub to redirect the console to serial. (which was set permanently for the next bootcycles)

1 Like