Ticket #1239 (committed defect)
stage1 installer shouldn't assume eth0
| Reported by: | jdreed | Owned by: | |
|---|---|---|---|
| Priority: | high | Milestone: | Current Semester |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
Change History
comment:1 Changed 12 years ago by jdreed
- Priority changed from blocker to normal
- Status changed from new to committed
comment:2 Changed 11 years ago by jdreed
Yeah, this was only half of the fix. raring PXE installs fail without a BOOTIF= parameter, so we need to either pass one, or work around by grabbing the MAC addr in stage1, and passing it to stage 2 via netcfg/choose_interface. Or just turn off biosdevname for now, because the hardware we use PXE on will not be affected by the bugs that led to biosdevname in the first place, and wait until iPXE solves all our problems for us.
comment:3 Changed 10 years ago by jdreed
- Priority changed from normal to high
OK, well, this code path got tested today when I did a fresh install of trusty on a Dell 7010. It happily ended up using the interface "em0" (seriously, _why_?) for installation. So, um, yay?
That having been said, we should do something a little better than the r25742 fix, because it may not DTRT on machines with multiple interfaces. In particular, we still pass "auto" to stage2.
So, because this is stage1, this will only become an issue when we bump the stage 1 to Quantal (which at this point isn't happening anytime soon. I'll bump it to Precise later in the fall, probably).
That having been said, we now no longer hardcode eth0.
That also having been said, I cannot convince the Quantal alpha-3 installer to give me a device name other than "eth0", so *shrug*.
Committed in r25742