Hi,
On Tue, Dec 06, 2016 at 10:38:34AM +0200, Vagrant Cascadian wrote:
> On 2016-12-04, Vagrant Cascadian wrote:
> > Unfortunately, it appears the fix to #840612 breaks LTSP's use of NBD:
> >
> > #840612 initrd forces NBD section name to start with the slash
> >
> >
> > A presumably unintended side-effect of that fix breaks LTSP's
> > long-standing "default" configuration for NBD on amd64
> ....
> > nbdroot=/opt/ltsp/amd64 or nbdroot=1.2.3.4:/opt/ltsp/amd64 are both
> > options used for configuring NBD root in LTSP, or if not specified,
> > falling back to the root-path specified similarly.
>
> so, I'm trying to wrap my head around the code in
> initramfs-tools/scripts/local-top/nbd, but what's kind of a blocker is I
> don't know what values for nbdroot are considered valid. in
> debian/nbd-client.initrd I see roughly four case statements...
>
>
> case "$nbdroot" in
> *,*,*)
> nbdsrv="${nbdroot%%,*}"
> nbdpath="${nbdroot%,*}"
> nbdpath="${nbdpath##*,}"
> # root= parameter overrides three-option nbdroot= parameter
> if [ -z "$nbdrootdev" ]
> then
> nbdbasedev="${nbdroot##*,}"
> nbdrootdev=/dev/$nbdbasedev
> fi
> ;;
> *,*)
> nbdsrv="${nbdroot%,*}"
> nbdport="${nbdroot#*,}"
> ;;
> \[*\]*)
> # [ipv6]:port/path
> ....
> *)
> # ipv4:port/path
>
>
> I think, if I'm reading this right, that gives us:
>
> nbdroot=
>
> serverip,path,device
> serverip,port
> serveripv6:port/path
> serverip:port/path
>
> It's not clear to me how a port definition is intended to look on the
> last two.
192.0.2.1:5000/exportname
or
[2001:DB8:a:b::1]:5000/exportname
> LTSP typically uses one of:
>
> nbdroot=serverip:path (e.g. 192.168.67.1:/opt/ltsp/amd64)
Well, even though the variables refer to it as a "path", nbd does not (and will
not ever) *require* the use of something that looks like a path.
> nbdroot=path (e.g. /opt/ltsp/amd64)
>
> These last two cases are failing due to the "*" case stripping the
> leading "/" in the line:
>
> nbdpath=${nbdportpath#$nbdport/}
Right.
Unfortunately, the code as it existed previously *required* the
existence of a / in the export name. Since that's not how NBD works, I
think the request in #840612 was reasonable, and removed the stripping
of that bit of it.
I can see a few possible solutions to the problem:
- We change the definition of the ip:port/exportname syntax so that the
/ is only stripped if an IP address and/or a port was specified, too;
i.e., if you don't specify anything before a /, then it is assumed
that the / is part of the export name, rather than it being a
separator. Not sure whether that fixes the issue for LTSP (in fact,
not even sure whether it's valid currently to specify only the
exportname, but ignoring that), but if so, that would be the cleanest
solution.
- I could be convinced of a transitional fix that would be supported
during Stretch (possibly Buster too, but certainly not later) wherein
if a leading / isn't found in an exportname and the export couldn't be
found either, we try adding a / and try connecting again. This would
be a somewhat more ugly solution, but it would work.
[...]
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
