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.
Craig
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
USB XHCI 1.00
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
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:
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.
Thanks for the thoughts. Unfortunately, I think I was the person that originally reported that problem, so I’m painfully aware 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!
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
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.
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.
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)
From what I can tell, both my Pi’s are these revisions.