I have RPI 3B+ with IPfire for some time. I updated it from 191 to 192 today. Update was OK, no errors but once rebooted, it was dead. I updated from WebUI. There are even no messages on serial console on UART, looks like boot process was totally broken.
I have checked microSDHC card in my PC with fsck and filesystem is clean, no corruption. I have checked microSDHC card with ValiDrive on Windows PC and no issue was found. This time it is not about faulty microSDHC card…
I verified that RPI3 HW is OK, it still can run microSDHC card with Raspbian.
My advice? Do not update RPI to IPfire 192. Do a backup before update!! Do I have a backup? No…
Once I will be in a good mood I will try to install IPfire 192 from the scratch…
I tried to update NanoPI R2S, from 191 to 192 and it was OK. I updated with pakfire from serial console. I was prepared for the worst, so I created full backup for recovery but it was not required, R2S runs IPfire 192.
Have you tried the hdmi output. The serial console on the RPI3+ is unstable because it use a software uart instead of the hardware one. (Its used for bluetooth)
I have tested this many times while development on both RPI3b and RPI3b+ but only via hdmi and not with the final image.
friday I updated from Core 190 to core 192.
After pakfire finished, I started “reboot + fsck”. system crashed and was not able to boot. No problems with hardware.
New install from scratch worked with hdmi, but I had to change serial from on to off.
Graphs ACPI Thermal-Zone Temp and hwtemp are fine.
I use ovpn n2n. Server cert was not restored by backup on client side.
Hardware: rpi 4b 8 GB. Using USB-Stick instead of sd-card.
Tried sd-card some years ago. It was sensitive to ac-power-loss.
I do not have any HDMI display. I have not tried that. I have somewhere HDMI2VGA adapter, I could try that. But I already found that Gargoyle-router has an image for RPI3 and I started to experiment with it. That is a distribution based on OpenWRT but with different GUI…
I need a travel router where WAN can be easily switched from wired LAN to WiFi client or Android Tethering (LTE modem). IPfire failed in this mission as changing WAN (RED) interface is difficult, I need a serial console or HDMI display with USB keyboard to run setup. And there are issues with Android Tethering (changing MAC is an issue).
Other issue with IPfire is that it has to be shutdown in the right way otherwise there is a high chance that filesystem on micro SDHC card is corrupted. This is not always possible with travel router, so I corrupted filesystem several times…
I ordered MANGO router from GL.inet and that is a good travel router. Firmware is based on OpenWRT but it has nice support for MultiWan in GUI and it is easy to switch between wired Ethernet, LTE modem (Android Tethering) and WiFi client. This device replaced my RPI with IPfire. IPfire is much advanced solution but it comes with trouble that I do not want on travel router…
I would like to have similar device on RPI so I started to experiment with Gargoyle router yesterday. So far I cannot start WiFi AP with external USB adapter (RT-5370) and it doesn’t have MultiWan configuration. It is easy to connect to WiFi as a client and switch WAN between wired Ethernet and WiFi client. There is a note how to connect Android phone as a modem…
I already tried NanoPI R2S as travel router that can run IPfire. It is heavy (massive metal case that works as a cooler) and when I want to access serial console, I have to remove board from the case, that is not good because IPfire needs serial console to change RED interface mode… When I run FriendlyWRT on it, it is OK but I failed to find compatible USB dongle to have WiFi AP… It has two Gigabit RJ45 ports but the device doesn’t have power to use full potential of those ports so speed was limited to 30% or 40% of gigabit Ethernet (I am not sure now but it was definitely not 90% of gigabit speed).
This isn’t pertinent to your current issue, but just an fyi, I ran into the same issue with my RPI of the sd-card getting corrupted whenever there was a power outage.
The solution for me was to turn on journaling for the root file system.
tune2fs -O has_journal /dev/mmcblk0p3
I think that I saw something a while ago about a patch to turn on journaling for all IPFire installations regardless, but haven’t checked if that was done.
