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

Bug#394868: installation-report: PPPoE still broken, highpoint/grub conflict detection would be nice



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

clone 394868 -1
reassign -1 ppp-udeb
retitle -1 Several errors in ppp-udeb postinst script
# please report furter issues regarding PPPoE in the cloned bug report
retitle 394868 highpoint/grub conflict detection would be nice
thanks

Paul TBBle Hampson wrote:
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot worked:    [O]
> Configure network HW:   [O]
> Config network:         [E]
> Detect CD:              [O]
> Load installer modules: [O]
> Detect hard drives:     [O]
> Partition hard drives:  [O]
> Create file systems:    [O]
> Mount partitions:       [O]
> Install base system:    [O]
> Install boot loader:    [O]
> Reboot:                 [E]
> 
> Comments/Problems:
> 
> I hit the following problems:
> 
> As well as #392858, the ppp-udeb.postinst script has a number of
> other bugs. (ppp-udeb 2.4.4rel-2)
> 
> On line 34, the $P needs to be somewhere other than directly between
> the -I and the $1, as when $P has the value -U, pppoe-discovery
> tries to use the ethernet device -U, which fails.

Indeed, i will fix those soon.

> Also on line 34, the file stderr is redirected to is /tmp/ppp-errors
> but for the rest of the file this is referred to as /tmp/ppp-error,
> causing detection of the timeouts to fail.

Correct, thanks for spotting that.

> I suspect the rm -f /tmp/probe-finished on line 31 probably should be
> a rm -f /tmp/probe-finished /tmp/ppp-error and moved to before line 34
> so the script doesn't detect timeouts from a previous loop iteration.

I am not sure if that ever happened, but is a good point.

> There's a typo on line 39 "Timout".

Harmless, but I'll fix that, too. :-)

> Line 51 (log probe-finished) prolly should be outside the while [ ! -f /tmp/probe-finished ]

err, at 51 there is a "log pppoe probe output size" and is there to be
able to debug if there is any output from pppoe-discovery which should
end the probe.

> It'd be nice if pppoe-discovery returned immediately on detection of
> any PPPoE Access Concentrator, rather than continuing to listen for
> further reponses, as it is being used only to determine if any access
> concentrators are out there.

This should be the default behaviour. Do you have any reasons to belive
otherwise?

> This'd reduce false timeout logs.
> 
> Anyway, with these fixes, it seems to work OK, although the resolv.conf test on
> line 196 also seemed to fail for me after the pppoe detection had succeeded but
> ppp failed to dial up, so I suspect that -e is the wrong test. (I'm guessing
> it's returning false for a dangling symlink) or the ln -s should be ln -sf.

I have rewritten that part as an effort to make the pppoe detection play
more nicely with the netcfg default configuration.

> Even though the script returned failure, the link came up and things worked.

Please answer on PPPoE related issues to the cloned bug report.

Thanks for the tests and reported issues.

- --
Regards,
EddyP
=============================================
"Imagination is more important than knowledge" A.Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFP21MY8Chqv3NRNoRAvvIAJ0QDQoKy7RDLUB8Uw/N5UEbaT2+OQCfWqWh
dc2wqLVMbChAdMFTA5gqfn4=
=q/JC
-----END PGP SIGNATURE-----



Reply to: