Bug#758084: kfreebsd-image-amd64 lacks support for i210 ethernet

2014-08-14 Thread James Buren 
Package: kfreebsd-image-amd64
Version: 9+1
Severity: wishlist

Could support for i210 be added to the kfreebsd i386 / amd64 images?
This is a critical piece of hardware support that makes kfreebsd-amd64
on wheezy unusable on my server. The 'if_igb' kernel module must be
updated to support this newer ethernet hardware.

Upstream added support for this hardware starting in the FreeBSD 9.1
kernel and newer.

It seems unfair that the i386 and amd64 stable branches using the
Linux 3.2 kernel had support for the i210 added to the stock kernel as
part of the stable updates, but the kfreebsd port has no such kernel
update.

It would be appreciated if a newer FreeBSD 9 kernel could be imported to
stable as either a regular update or as part of a backport. Thank you.

-- System Information:
Debian Release: 7.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140814050931.3198.27169.reportbug@debian

Bug#758084: kfreebsd-image-amd64 lacks support for i210 ethernet

2014-08-14 Thread Steven Chamberlain 
Hi,

On 14/08/14 06:09, James Buren wrote:
 It would be appreciated if a newer FreeBSD 9 kernel could be imported to
 stable as either a regular update or as part of a backport. Thank you.

You could possibly try to install a 9.2 kernel on your wheezy system,
although some of the userland tools might not be compatible:
https://packages.debian.org/jessie/kfreebsd-image-9.2-1-amd64

It is possible to have both 9.0 and 9.2 kernels installed together and
choose one from GRUB at boot time, so you can change back in case there
are any problems.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53ec963a.4060...@pyro.eu.org

Re: Bug#757711: Bug#757988: kfreebsd: troubles with dhcp (configuration going away)

2014-08-14 Thread Cyril Brulebois 
Hi,

Steven Chamberlain ste...@pyro.eu.org (2014-08-13):
 On 13/08/14 18:05, Cyril Brulebois wrote:
  What I'd like to get figured out is what changed between images that
  weren't hitting this problem, and the newly published ones.
 
 What changed is dhclient from isc-dhcp-client-udeb gained a signal
 handler that responds to SIGKILL by releasing the DHCP lease and
 deconfiguring the interfaces.  I've just tested that the version in
 wheezy d-i didn't trap the signal;  Linux udhcpc doesn't either.

thanks. Knowing where/when/why a regression happens is quite important
to me.

 This is a 'feature' introduced in ISC DHCP 4.3.0, which first reached
 testing on 2014-07-16;  I've tested that d-i Alpha 1 wasn't affected by
 this bug (dhclient is killed but the interface stays configured) :
 
  @@ -681,6 +692,10 @@ main(int argc, char **argv) {
  dmalloc_outstanding = 0;
   #endif
   
  +/* install signal handlers */
  +   signal(SIGINT, dhcp_signal_handler);   /* control-c */
  +   signal(SIGTERM, dhcp_signal_handler);  /* kill */
  +
 (from
 http://anonscm.debian.org/gitweb/?p=pkg-dhcp/isc-dhcp.git;a=commitdiff;h=b2a56ecb808768dbc5bd4be60fcf9c9f93d8e802#patch16
 )
 
 Either way, netcfg killing the DHCP client seems wrong to me, because
 I'd expect the kind of issues Philipp Kern described;  if you're going
 to use DHCP, you ought to renew your lease and not let it expire?

Now, I think there are several questions to answer:
 1. What were the reasons for having arch-dependent dhcp clients?
 2. Are those reasons still valid?

= Maybe think about moving to a single client if possible, at least for
   consistency's sake (and probably maintenance costs).

The answer to the first question is likely answered by looking at some
git history, and possible links to bug reports. As for the second, we'll
likely need porter input.

 3. Is the current netcfg behaviour correct?

= The answer is probably “no”, based on Steven's and Phil's opinion;
   and while I haven't looked into it yet, I'm pretty convinced by
   Phil's points.

Of course we could probably apply Steven's patch, but it seems
appropriate to me to (also) take some time and investigate questions 1+2
above while we're on that topic.

Mraw,
KiBi.


signature.asc
Description: Digital signature