[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Fixing udev-udeb vs. net.ifnames for Stretch Alpha 1



(tl;dr: See bottom.)

Hi,

So Michael just approached me regarding having this merged before
Stretch Alpha 1: (A)
| commit 7b5eb265bbb2b783cbf7563b57db2f5a9b5cc3cf
| Author: Martin Pitt <martin.pitt@ubuntu.com>
| Date:   Sat Jul 11 11:56:42 2015 +0200
| 
|     Fix udeb an initramfs for net.ifnames
|     
|      - debian/udev-udeb.install: Install new bits for net.ifnames.
|      - debian/extra/initramfs-tools/hooks/udev: Do the same for initramfs-tools.
|     
|     LP: #1473542

which I guess could be coupled together with: (B)
| commit b8fdd6f8f16c1bbfdf75f90e2710b2ac0dabae1b
| Author: Martin Pitt <martin.pitt@ubuntu.com>
| Date:   Mon Jul 13 09:02:27 2015 +0200
| 
|     Also put old 70-persistent-net.rules into initramfs
|     
|     The previous commit added the new net.ifnames machinery to initramfs, to get
|     consistent names in initramfs and the real system. However, we also need to
|     copy the legacy 70-persistent-net.rules to avoid getting different names in
|     both places. Thanks Adam Conrad!

Context: the following change appeared earlier and already reached
testing: (C)
|   * Switch to net.ifnames persistent network interfaces (on new
|     installations/for new hardware), and deprecate the old
|     75-persistent-net-generator.rules. See the ML discussion for details:
|         https://lists.debian.org/debian-devel/2015/05/msg00170.html
|         https://lists.debian.org/debian-devel/2015/06/msg00018.html
[ heavily truncated ]

In other words: current packages in testing would lead to a broken user
experience and it seems worth fixing.


As pointed out by Michael, I didn't announce this Alpha widely, but I
thought it was understood that changes touching the installer
(especially when they are known to be targetting new installations and
documented as such) would be brought up to the installer team, be it for
approval (IIRC we tend to approve pretty much anything since people
usually only have sane things to propose ;)), for documentation reasons
(installation guide might need updating), or for timing reasons. Anyway,
trying to improve awareness for next time: I'll probably send a reminder
to dda@.


As for the timing of this particular change I really would have liked to
have it *after* the first Alpha as this is a pretty important one,
judging by the size of the dd@ thread, or the amount of lines for the
relevant changelog entry. For the records, as for why the Alpha hadn't
been released earlier, we've been waiting on the kernel to be ready…
since the jessie release, so d-i had no chance at being tentatively
released yet.


But well, it's done, can't reasonably be undone, so let's try and find a
solution, possibly in a timely manner.

Let's talk versions:
 - 220-7: introduction of the net.ifnames change (C)
 - 221-1: version in testing, buggy
 - 222-1: version in unstable, buggy
 - 222-2: version being prepared in master, has both fixes (A+B)

Bottom line(s):
---------------
I'll be testing 221-1 to make sure I reproduce the issue with a full
install, then 221-1 + two patches to make sure it goes away. If that
works fine, it might be a good idea to tpu 221-1+deb9u1 so that we
get d-i Stretch Alpha 1 unstuck ASAP, while not having to figure out
what new joy the 222 release would bring.


Would that look like a sane way forward to both systemd and release
teams?

(I know this violates our usual requirement of having a fix in unstable;
but I assume my asking for a fix in testing that I double-checked myself
would compensate for that.)

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature


Reply to: