[dimerr]

Problem

On a board with no Ethernet PHY the boot never reaches a login prompt. The console fills with this, about once a second:

udhcpc: read error: Network is down, reopening socket

Seen on a YI V831 camera (no Ethernet port). The MAC driver registers eth0, but sunxi-gmac fails ndo_open when no PHY answers, so the interface can't come up.

S40network runs ifup eth0 in the foreground. busybox udhcpc only acts on -b (or -n, -t) when poll() times out. On this interface every poll ends in a read error, so the timeout path is never reached. S40network doesn't return, rcS doesn't finish, and getty never starts.

Fix

In start(), try to open eth0 and only run ifup eth0 if that succeeds. sysfs can't answer this beforehand: sunxi-gmac only looks for the PHY in ndo_open, so before the first open eth0 looks the same with or without one.

The interface goes back down before ifup so that it can still apply hwaddress, which some drivers refuse on a running interface. The cost on boards with working Ethernet is one extra open and close at boot, which may restart link negotiation. An unplugged cable doesn't affect the probe.

Testing

• sh -n passes.
• The hang was reproduced on the camera before the change.
• Not yet boot-tested on hardware, either on the camera or on a board with working Ethernet.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Skip eth0 DHCP when the interface cannot be opened

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Probe whether eth0 can open before starting DHCP, preventing a boot hang on boards without a PHY.
• Bring eth0 back down after probing so ifup can still configure its MAC address.
• Apply the guard to normal startup and the wireless-without-credentials path.

Diagram

graph TD
  S["Network start"] --> P["Probe eth0"] --> D{"Open succeeds?"} -- Yes --> I["Run ifup eth0"] --> B["Startup continues"]
  S --> W["No WiFi credentials"] --> P
  D -- No --> B

Loading

High-Level Assessment

Keep the targeted open-and-close probe: interface existence does not establish that eth0 can open, and udhcpc timeout or background options do not resolve the reported read-error loop. Hardware boot testing remains the key validation step.

Files changed (1) +9 / -2

Bug fix (1) +9 / -2

S40networkGuard Ethernet DHCP with an interface-open probe +9/-2

Guard Ethernet DHCP with an interface-open probe

• Adds eth0_openable(), which brings eth0 up and back down to check whether it can open. Normal startup and the wireless-without-credentials path now call ifup eth0 only when that probe succeeds, avoiding the reported udhcpc boot hang.

general/overlay/etc/init.d/S40network

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Boot fix has no on-hardware proof 📘 Rule violation ☼ Reliability

Description

The new eth0_openable probe decides whether ifup eth0 runs during every boot, and the PR
description states the fix is "Not yet boot-tested on hardware with the fix". Only the pre-change
reproduction is offered as hardware evidence, so a wrong probe result would leave Ethernet cameras
without a network or stall boot before getty on boards without a PHY.

Code

general/overlay/etc/init.d/S40network[R30-32]

+eth0_openable() {
+	ip link set eth0 up 2>/dev/null && ip link set eth0 down
+}

Evidence

The shell change alters boot behaviour on cameras, which triggers the rule. The description states
the fixed boot has not been tested on hardware, which is a listed failure condition, and the only
evidence given is the pre-change reproduction, so the required before/after output from a real
camera is missing.

Rule 3: Hardware evidence is present and honest
general/overlay/etc/init.d/S40network[30-32]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `eth0_openable` probe in `S40network` changes whether `ifup eth0` runs during boot. The PR description says the fix is not yet boot-tested on hardware, so there is no evidence the boot reaches a login prompt after the change.
## Fix Focus Areas
- general/overlay/etc/init.d/S40network[30-32]
- general/overlay/etc/init.d/S40network[37-50]
## Recommended Fix
Boot the V831 camera (no PHY) and a board with working Ethernet using the patched image. Capture the serial console log up to the getty prompt, plus the output of `ip link show eth0` after boot. Replace the "Not yet boot-tested" line in the PR description with those logs. Keep the before-change reproduction as the symptom evidence.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Network-root cameras hang during boot 🐞 Bug ☼ Reliability

Description

eth0_openable() brings eth0 down after probing it, even when that interface carries the mounted
root filesystem. On builds booted with root=/dev/nfs, the earlier network-profile script makes the
subsequent ifup eth0 a no-op, leaving rcS to continue reading init scripts over a link the probe
has disabled.

Code

general/overlay/etc/init.d/S40network[31]

+	ip link set eth0 up 2>/dev/null && ip link set eth0 down

Evidence

rcS runs numbered init scripts in order, so the NFS-root profile is installed before S40network.
That profile explicitly makes Ethernet configuration a no-op because the kernel already configured
it; the added probe nevertheless takes the interface down.

general/overlay/etc/init.d/S40network[30-32]
general/overlay/etc/init.d/rcS[18-25]
general/package/openipc-nfs-root/files/S39netprofiles[15-25]
general/package/openipc-nfs-root/files/eth0[1-5]
general/package/openipc-nfs-root/Config.in[1-11]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Ethernet probe takes down the interface carrying an NFS root filesystem, and the NFS-root network profile does not bring it back.
## Fix Focus Areas
- general/overlay/etc/init.d/S40network[30-32]
- general/package/openipc-nfs-root/files/S39netprofiles[20-23]
- general/package/openipc-nfs-root/files/eth0[1-5]
## Recommended Fix
When `/proc/cmdline` specifies `root=/dev/nfs`, bypass the up/down probe and preserve the kernel-configured interface. Keep the probe for other boots, and add a regression check for the NFS-root path.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can pick a display mode instead of tweaking every Display option by hand

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗