On May 6, 2016 8:17:50 PM GMT+02:00, Stuart Henderson <[email protected]> wrote: >On 2016/05/06 19:35, Martin Natano wrote: >> On Thu, May 05, 2016 at 09:30:43PM +0100, Stuart Henderson wrote: >> > On 2016/05/02 09:34, Martin Natano wrote: >> > > Diff below simplifies the device open path and removes an >explanation >> > > about bpf device nodes from the manpage. >> > >> > There's a problem with this. If someone is doing an "untar sets" >> > upgrade (which is not _supported_ but is pretty much necessary in >> > some situations) and relies on dhclient for network to get back >> > in to the system, they lose. >> > >> > Since they won't have a new MAKEDEV at the right time, I think >> > our options are either "change dhclient back to using /dev/bpf0" >> > or "tell them to run mknod manually before updating". >> >> Adding this information to current.html seems like the way to go to >me. >> I see you and tb@ have already done so (with instructions to run >MAKEDEV >> after unpacking the sets), thanks! > >What we added to current.html is good enough for things like >pflogd etc., but it doesn't go far enough for the dhclient case. >In many cases (especially when people move from 5.9 to 6.0) >you won't be able to run MAKEDEV until *after* you've rebooted >due to pledge/syscall changes.
Heh, indeed. I was severely bitten by that in an upgrade when I, as part of my normal online upgrade procedure, ran MAKEDEV before reboot, which succeeded in removing the old devices but failed to create the new ones... My upgrade script got upgraded after that. :-) /Alexander > >Personally, my preferred course of action would be to switch to >looking for /dev/bpf0 for now (bpf0 only: *not* revert to the old >loop, that's not necessary), and then switch to /dev/bpf >immediately after 6.0 is released. The recent few version >upgrades have been relatively painful, with good reason, but >this is something where we can easily reduce the pain with >minimal downside.
