I am running a Raspberry Pi 3B+ on my network with red on the “internal” ethernet and green on a USB network adapter. This has all been working fine until I tried to update to 162 today. After the device failed to come up, I connected a monitor and was getting errors about boot files. Figuring it was a lost cause and that I could just use backups, I proceeded to grab the 162 flash file and install starting from scratch. Unfortunately, 3 hours later I’m still without a working device (with network cables and such strewn around the room).
I’ve walked through the initial setup of 162 (and even tried to drop back to 161), but I cannot get the red interface to come up and connect via DHCP to my ISP. If I try to connect to the green interface with my laptop, I receive an IP address from the DHCP server in IPFire, but attempts to access the web interface fail. I have web based backups, but I don’t know how to use them in this state and I don’t know what to do to get out of this state either. FWIW… I have validated that connecting my laptop directly to the ISP network properly configures via DHCP. I even went so far as to change out both the SD Card AND the Raspberry Pi I was using thinking maybe the ethernet port was somehow trashed.
Can anyone suggest next steps for me? I’ve been troubleshooting things all night and I’m just stuck on what to try next. I know that the last time I had to rebuild from scratch it went completely without issues, so I’m not sure what has changed.
Your update failure could be caused by the update failing to delete the large /boot/dtb… directory that hangs over from core 160 and that results in the boot partition filling up. A fresh install of core 161 should avoid this issue.
A fresh install of 162 has worked for me on ARM hardware. I also put red on internal interface.
DHCP on red does seem to be a problem, because the process can time out. Can you get a fixed address from your ISP ?
Relative to the update, that sounds like it might have been the issue. Too bad, but I was willing to reinstall… I just didn’t expect to get tripped up there. For the moment, I’m having to count on the security of my wifi router, which makes me feel a little exposed
In terms of DHCP, while it is possible for me to get a static IP, it costs extra and is not automatic. I’ve been running fine for a long time without a static IP using dynamic DNS updates. Has something changed here? If I can manage to get through installation/recovery, will I still have DHCP issues? I’m thinking I could cheat temporarily and use my last provided IP address statically to get through an installation if that would behave better relative to DHCP.
could you please post these log messages here so we can investigate what went wrong exactly?
This sounds like you are getting a publicly routable IPv4 address via DHCP from your ISP.
To the best of my knowledge, Core Update 162 did not change anything on this end. However, screenshots and relevant log messages would be really helpful to determine what happens here.
Unfortunately, I don’t have them. I was in a bit of a panic last night trying to get things back in working order and I didn’t capture the details. I just assumed my SD Card had gone bad and proceeded to start creating a new one, planning to restore from my backup.
I can try to get that information this weekend. At the moment, I’m hesitant to do much that might put me back in a bad spot. What would I be looking for if I recreate? Also, did you have any thoughts on whether installing using a static IP and then switching to DHCP might work any better?
oh, that’s a common reason for trouble indeed. You can try to verify the SD card being damaged by treating with something like
badblocks -swv /dev/[SD card]
A rather profane solution would be having two SD cards at hand: One having the last working Core Update installed and running properly. On the other one, you can install the latest one, and switch back to the other SD card in case things are not peachy and vanilla.
This would at least allow to recover from whatever trouble you are experiencing quickly.
This should not make any difference. Setting up things with DHCP in the first place is (or at least should be) completely fine.
well, this might be an overkill, but especially for larger setups, I recommend having some staging or testing firewall where you can test the latest version of IPFire for your scenarios - preferably while it is still in the testing phase.
The reason for this is simple: We cannot predict all possible ways our users are running IPFire, and neither do we have all the hardware they use it on. Hence, feedback is always appreciated.
Please don’t mistake my frustration with my situation as frustration with you or the project in general. I use this for my home setup because I like what it does and how it works. I’ve donated in the past and will likely donate yet again. My frustration is squarely on myself for not being better prepared when I did this update. I’m a long-time software engineer and should know better. The previous upgrades have gone so smoothly that it lulled me into a false sense of security!
I also owe some testing of 162 on my Pi 4b+, but due to holidays and family I just haven’t had much time to play with anything.
