Re: Simultaneous EFI and Legacy bootloader installation

2016-03-29 Thread Stefan Lippers-Hollmann
Hi

On 2016-03-29, Mario Limonciello wrote:
> On 03/29/2016 07:50 PM, Limonciello, Mario wrote:
[...]
> > I'd like to propose changing this and by default install both legacy 
> > and UEFI bootloaders on architectures that support both regardless of 
> > which mode the system is running in at installation. Making this 
> > change has a few obvious implications:
> > * The installation disk would always be formatted GPT.
> > * An ESP would always be created.
> > * If the user is in legacy at installation time, it's not possible to 
> > create an EFI boot entry since EFI runtime services aren't present.  
> > The removable media fallback path (\efi\boot\boot$ARCH.efi) will need 
> > to be used to boot the system at this point and at some point create 
> > a "debian" NVRAM boot entry
> >
> > I'm not aware of any modern systems that are unable to boot a GPT 
> > partitioned disk.  If there are systems like this in the wild, it 
> > would be worthwhile to leave support to install in MBR mode when 
> > doing an expert install so that people can still use them.
[...]

At least well into 2009/ 2010 era systems (most of those are early UEFI 
based underneath, but only expose a mandatory BIOS CSM to the user), 
you can sometimes find mainboards which refuse booting from a disk 
that doesn't have a MBR partition with the bootflag set. On these 
systems it is often possible to trick them into booting by setting the 
bootflag on the protective MBR around the GPT partitions, although this
is a blatant violation of the UEFI specification (and might break more 
modern systems).

Of course, most of the affected systems won't be detected as UEFI
capable in the first place (because they will only allow booting
via the BIOS CSM), but it's still something to be aware of. 

I'd very much appreciate BIOS and UEFI variants of grub to be 
co-installable (including their maintainer script orchestration), 
also to make moving installed systems between different mainboards 
easier (I am using a custom /etc/grub.d/ hook using grub-pc and 
grub-efi-amd64-bin for semi-portable installations on USB sticks
myself, usually without any particular problems besides the one
mentioned above).

Regards
Stefan Lippers-Hollmann


pgpWPZ_Z6aH6l.pgp
Description: Digitale Signatur von OpenPGP


Re: Network installer lacks Netgear wifi support

2015-05-10 Thread Stefan Lippers-Hollmann
Hi

On 2015-05-11, Cyril Brulebois wrote:
 Hello Stefan,
 
 Thanks for the write-up, I only had a vague idea of what usb-modeswitch
 was, and it helped getting a clear view.
[...]

Just to add some further context. Device manufacturers can apply this 
modeswitching dance (supported by usb-modeswitch) to just about any USB 
device (-class), like scanners/ printers, projectors, smartphones, wlan 
cards, etc., but it's most common for 3g, wimax or LTE cards. Looking 
through usb-modeswitch-data, I can only identify about half a dozen 
USB IDs for USB wlan cards among its database (and none of them belonging 
to devices that are still on sale, well perhaps except for one (AVM 
FRITZ!WLAN Stick N v2, based on the Ralink RT5572 wireless chipset)).

 [...] It's hard to say anything about a
 potential usb-modeswitch addition (to jessie) without having the work
 done in unstable already, but the extra udeb(s) are indeed somewhat
 worrisome. [...]

usb-modeswitch-data[1] would be required as well - or at least a tiny
excerpt of its USB ID database (unfortunately one can't filter this
for a specific device class, like wlan cards, automatically). So the
potential udeb would either have to ship all USB IDs, or a handcrafted
excerpt of wlan devices[2].

From a purely technical point of view, for the strict subset of already
known wlan cards requiring modeswitching, it might also be possible to 
emulate usb-modeswitch by just using /usr/bin/eject (respectively 
busybox' corresponding eject applet) on the usb-storage device node. 
However this would be quite painful to maintain for Debian/ d-i, but the
list of devices is small, currently not expected to grow (at least not 
significantly) and all of the known specimens appear to use 
StandardEject=1. I'm strongly recommending against this[3], but it might 
be possible to accomplish with some udev rules and a (likely) tiny shell 
script - or just executed manually[4] by the affected users.

Regards
Stefan Lippers-Hollmann

[1] Or perhaps usb-modeswitch-data-packed
[2] Or parse usb-modeswitch-data's USB ID database and cross 
reference those to the kernel modules - possible, but not pretty.
[3] because of the maintenance effort required for a Debian-only 
workaround, something the upstream supported usb-modeswitch 
abstracts nicely.
[4] eject /dev/sdX on a free tty, where X stands for the usb-storage
device node provided by the wlan card in question.


pgpNyc9lAyHEi.pgp
Description: Digitale Signatur von OpenPGP


Re: Network installer lacks Netgear wifi support

2015-05-09 Thread Stefan Lippers-Hollmann
Hi

On 2015-05-09, JohnT wrote:
 I bought a newer 64-bit pc to replace this old 32-bit system and want to
 install Debian on it. I knew that 6.0.10 didn't seem to have Netgear
 wireless-through-USB support, so I tried 7.6.0 and 8.0 and found that they
 didn't recognize the Netgear hardware either. The 8.0 installer's hardware

There is no such thing as a Netgear wireless-through-USB device, there
are dozens withs vastly different internals. Therefore you'd need to 
specify your particular device much more accurate before anyone can
help you. Even giving the model name is often inconclusive, as multiple
vendors (including Netgear) tend to switch horses between different
hardware revisions of the same model, but lsusb combined with the
model name might give an approximation (even that isn't 100% sure, as
multiple vendors tend to re-use USB IDs for different hardware).

 detection reported my wireless device as a mass storage device, as I
 recall. Netgear USB wireless devices have been around for several years
 and are commonly used. I bought mine at Walmart.

Several USB wlan cards actually do contain a tiny usb-storage partition,
which often contains drivers for windows and sometimes also configuration
data. These devices need a modeswitch to turn of the usb-storage 
partition to free the USB endpoint and then turn on the wlan 
functionality. Some drivers can do this modeswitch on their own, without
userspace assisting, like e.g. ar5523, zd1211rw et al - others need a 
usb-modeswitch to accomplish this in userspace instead (e.g. some 
ar9170/ carl9170 devices).

 I found that Ubuntu works with my Netgear device, though I am having
 problems finding a mirror that still has that longterm support version

The usb-modeswitch package doesn't provide a udeb, to hook itself into
d-i (the Debian installer), therefore affected wlan cards requiring
this kind of special handholding won't be supported automatically (or
at all for the time being) - you might be lucky by trying eject on the
usb-storage device node though; make sure to have the needed firmware
available before trying this (manual) mode-switch.

 available. And Mageia 4.1 works fine with Netgear, but there are some
 things in their software selection I don't like. I would rather be using
 just a simple upgrade of 6.0.10, which I find very satisfactory in most
 respects, better than 7.x.

I'm rather confident that the installed Debian system will support
your device just fine - once you install its firmware and the 
usb-modeswitch package; debian-live based live media might as well,
provided you install usb-modeswitch and firmware before connecting
your wlan card.

What won't work right now is doing a (partial-) netinstall using such a 
wlan card.

 If you would add Netgear wireless support to 8.0, 7.x and 6.x, I'm sure
 many users would appreciate it.

I can't speak for release and d-i teams, but adding a new udeb for 
usb-modeswitch and d-i integration for already released Debian 
versions doesn't sound very likely. However you can ask the 
usb-modeswitch maintainers to support this for stretch/ Debian 9~,
by filing a bugreport against src:usb-modeswitch and suggesting them
to add a udeb to their package.

Disclaimer: While I have access to several wlan cards doing an
internal modeswitch inside the kernel module, I don't own any 
requiring external help via usb-modeswitch myself and therefore 
won't be able to test this.

Regards
Stefan Lippers-Hollmann


pgpPlsnlEo6Sd.pgp
Description: Digitale Signatur von OpenPGP


Re: 8.1 (and maybe 7.9) planning

2015-05-01 Thread Stefan Lippers-Hollmann
Hi

On 2015-05-01, Cyril Brulebois wrote:
[...]
  - I see gnutls28, linux, and wpa in pu; some testing couldn't hurt.

wpa should be safe (famous last words), as it contains only the one-line
security fix for CVE-2015-1863[1], which applies to a code path/ file not
used by the udeb (as CONFIG_P2P is disabled there); the same goes for 
wheezy (where CONFIG_P2P is disabled alltogether). I've been testing all
three versions (sid, jessie-security and wheezy-security) successfully in
a non-udeb context - d-i is different of course and needs special 
testing, please let me know if there are any issues with the uploads.

Regards
Stefan Lippers-Hollmann

[1] https://security-tracker.debian.org/tracker/DSA-3233-1
http://w1.fi/security/2015-1/


pgppzYIpiyDTt.pgp
Description: Digitale Signatur von OpenPGP


Re: adventures in UEFI PXE land

2015-03-05 Thread Stefan Lippers-Hollmann
Hi

[ grub-efi's actual package names are architecture dependent, my 
  explantions below use grub-efi-amd64 (64 bit UEFI for x86_64) for 
  examples, substitute it with grub-efi-ia32, grub-efi-arm or 
  grub-efi-arm64 where needed. ]

On 2015-03-05, Paul Wise wrote:
[...]
 I had some adventures in UEFI land. I had an Intel NUC fried during a
 lightning storm but the hard drive was fine so I wanted to get the hard
 drive to boot within a new NUC. I didn't have any USB stick so I went
 with PXE boot from my laptop. The existing system on the hard drive was
 wheezy but the installer image I was using was jessie.

Once you're on jessie's version of grub-efi, I'd suggest to configure
grub-efi-amd64's debconf settings to include (unless you're dual booting
with an OS that reclaims /boot/efi/EFI/BOOT/ for itself, e.g. windows is
supposed to do this):

grub-efi-amd64  grub2/force_efi_extra_removable boolean true

This instructs (very recent) grub-efi packages to also install itself
to the default path (originally intended) for removable media, in other
words a fallback location the UEFI mainboard firmware can find and load
without an UEFI boot entry. This allows you to simply move the HDD to
another UEFI based system (of the same UEFI architecture) and boot from
that HDD directly (by selecting it from the boot manager included in
your mainboard's UEFI firmware). Some mainboard firmwares also tend to
forget UEFI boot entries after upgrading itself (some extremely buggy
ones forget it after each reboot)...

Using this fallback procedure allows to avoid using an external rescue
medium when moving harddisks to another system (or in the other 
scenarios of broken mainboard firmwares depicted above), however it's
only a safe setting if no other operating systems claim that location
in dual-boot environments.

Even on wheezy (or jessie without grub2/force_efi_extra_removable being
set), it would have been possible to copy /boot/efi/EFI/debian/grubx64.efi
to /boot/efi/EFI/BOOT/BOOTX64.EFI and your mainboard's UEFI firmware 
should have offered /boot/efi/EFI/BOOT/BOOTX64.EFI for booting the already
installed system without having to use an external rescue system, like 
d-i (assuming the default MODULES=most in 
/etc/initramfs-tools/initramfs.conf and no too special customisations).

[...]
 Intel Visual Boot Manager had a question mark as the Debian icon instead
 of the swirl and the name of the OS was debian instead of Debian.
[...]

Debian's grub packages, which are the ones steering efibootmgr to set up
the UEFI entries behind the curtain, enforce all-lowercase for the UEFI
boot entries.

/var/lib/dpkg/info/grub-efi-amd64.postinst:
[...]
  grub-efi-ia32|grub-efi-amd64|grub-efi-ia64|grub-efi-arm|grub-efi-arm64)
bootloader_id=$(config_item GRUB_DISTRIBUTOR | tr A-Z a-z | \
 cut -d' ' -f1)
[...]

GRUB_DISTRIBUTOR is defined in /etc/default/grub and must correspond
to the path used on the EFI System Partition, which is on a FAT32 
filesystem. grub-efi requires /boot/efi/EFI/${GRUB_DISTRIBUTOR}/ to
pre-exist or it will silently skip invoking efibootmgr.

Regards
Stefan Lippers-Hollmann


pgpVvVWpRipn_.pgp
Description: Digitale Signatur von OpenPGP


Re: Problem with ACPI on reboot

2015-01-28 Thread Stefan Lippers-Hollmann
Hi

On 2015-01-27, Pierre GINDRAUD wrote:
 Hello evryone,
 
 I'm not sure that is the best mailing list to expose my problem, but I try
 anyway

While this is a hardware (UEFI firmware, well basically the BIOS) issue,
the only way to (eventually) work around this problem is from the kernel
side. Accordingly a kernel specific mailing list, probably upstream 
(lkml) or Debian specific (BTS, debian-kernel) are probably better 
venues.

 I've bought recently, an motherboard in order to make a simple server in my
 home, the model is a ASROCK Q2900 ITX (see documentation below)
 http://www.asrock.com/mb/Intel/Q2900-ITX/
 
 My problem occur when I reboot the MB.
 If I turn off (shutdown -h now) and push physically the power button it
 successfully restart
 But if I type `reboot` the MB turn off but doesn't power on, the boot
 freeze just after showing POST screen of the bios.
 
 During my test, I've try to put acpi=off option to kernel and the reboot
 problem disappear, but this time it's the shutdown process which is
 impacted. When I type shutdown the system succesfully halt but the MB
 doesn't physically poweroff

Please don't use acpi=off, it not only disables SMP but may also cause
damage to your mainboard.

 Can anyone already had a similar problem ?

You can try to use reboot=pci as kernel parameter, I'm having similar
(but intermittent) problems on an ASRock Q1900DC-ITX where this seems
to help (but it's a bit too early to be sure about it, so a bit too 
early to submit the according kernel quirk).

Regards
Stefan Lippers-Hollmann


pgp8BPhKRIoWV.pgp
Description: Digitale Signatur von OpenPGP


Re: [pkg-wpa-devel] Bug#776338: wpa: wpasupplicant-udeb missing from kfreebsd installation media

2015-01-26 Thread Stefan Lippers-Hollmann
tags -1 - patch

Hi

On 2015-01-26 19:52:54, Michael Gilbert mgilb...@debian.org wrote:
 package: src:wpa
 version: 2.3-1
 severity: important
 tags: patch
 
 Hi,
 
 The kfreebsd installation media currently lack wpa support.  Here is a
 patch that adds support for building the udeb.

I'm closing this bug, as your patch doesn't -and can't- work (anytime 
soon). Please don't inflate the bug severity, this would be a request
for a new feature, not a bug.

In order to work, wpasupplicant requires either libnl or libpcap.
libnl is linux-any (it requires the nl80211 interface of the linux 
kernel), therefore wpasupplicant uses libpcap on kfreebsd-any, 
which however doesn't provide a udeb. If I'd take your patch 
as-is, the kfreebsd-any wpasupplicant udeb would therefore gain a
dependency on the non-existing package libpcap0.8-udeb (instant RC
bug and introducing a new package at this time in the jessie 
freeze is certainly not appreciated by the release team or the d-i
maintainers). So the first step here would be to get libpcap to 
provide a udeb, at least on kfreebsd-any.

The next step is d-i, or technically netcfg, itself, which only
provides support for scanning via wext (wireless extension), a
deprecated kernel-userspace API of the linux kernel. As kfreebsd,
to the best of my knowledge, doesn't emulate this API to 
userspace, netcfg would need to gain support for the native 
kfreebsd wlan interfaces - and ideally for linux' new nl80211 API
as well. The same goes for actually managing the interface from
within netcfg. If I remember correctly, Kel Modderman did 
originally suggest an alternative way to scan via wpasupplicant
(and thereby to abstract (most of, at least for scanning) the 
wlan interface handling from netcfg), rather than making it 
depend on the deprecated wext Linux API, but netcfg chose a 
different way.

I'd be happy to provide a udeb on kfreebsd-any as well, but 
these kfreebsd specific issues need to be solved first. Feel 
free to re-open this bug (or to file a new one), once this 
has been resolved and tested - or has at least reached the 
planning state for stretch.

Regards
Stefan Lippers-Hollmann


pgp0cv__N3J7k.pgp
Description: Digitale Signatur von OpenPGP


Bug#765631: unblock/ age to 5 days: wpa/2.3-1 (CVE-2014-3686, DSA-3052-1)

2014-10-16 Thread Stefan Lippers-Hollmann
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-CC: debian-boot@lists.debian.org

Hi

Please unblock the udeb producing package wpa and reduce its 
propagation time to 5 days. wpa 2.3-1 has been successfully built and
uploaded on all release architectures.

wpa = 2.3-1 is vulnerable against a remotely exploitable security 
bug, which might allow attackers to inject an unsanitized string 
received from a remote device (potentially any device in radio 
range) to a privileged (typically root or netdev) system() call via 
wpa_cli/ hostapd_cli action scripts.

CVE-2014-3686   https://security-tracker.debian.org/tracker/CVE-2014-3686
DSA-3052-1  https://www.debian.org/security/2014/dsa-3052
#765352 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765352


For debian-boot/ the upcoming stable point release (wheezy 7.7):
wpasupplicant-udeb, as used by d-i, does not contain the exploitable
binary (wpa_cli), which is only part of the full wpasupplicant/ hostapd
packages (these are already fixed via debian-security). Accordingly 
d-i's usage of wpa_supplicant is not suspectible to this security 
issue.


This is a new upstream version of wpa containing further changes and
features of wpa's stable integration branch[1], rather than a 
targetted fix.

unblock wpa/2.3-1

Regards
Stefan Lippers-Hollmann

[1] wpa 2.x is a continuous integration branch for bugfixes and new 
features, rather than a dedicated   bugfix branch in the sense of 
PostgreSQL or the linux kernel.


signature.asc
Description: This is a digitally signed message part.


Bug#760712: WEP vs WPA2

2014-09-16 Thread Stefan Lippers-Hollmann
On Monday 15 September 2014, Ben Hutchings wrote:
 On Mon, 2014-09-15 at 23:08 +0200, Stefan Lippers-Hollmann wrote:
  On Monday 15 September 2014, Cyril Brulebois wrote:
   Stefan Lippers-Hollmann s@gmx.de (2014-09-15):
[...]
  [...] but the udeb
  should support:
  
  - no encryption
  - WEP64
  - WEP128
  - WPAPSK v1 TKIP/ CCMP
  - WPAPSK2 TKIP/ CCMP
  
  More advanced setups, like IEEE8021X (using certificates and per-user 
  encryption, e.g. eduroam and other commercial setups), smartcards and
  are not supported by the udeb (nor would netcfg know how to configure
  these).
 
 WPS would also be nice to have.

Actually plain WPS support[1] (not allowing for external registrar 
functionality or NFC config methods) should already be supported by
wheezy's wpasupplicant packages (1.0-3). However I have not tested WPS
support (it was only enabled due to dependency issues of the udeb build
config) and I'm pretty sure that netcfg doesn't know how to configure 
this. WPS using pin numbers or push-button (QSS) support is horribly
insecure and should be strongly discouraged, even though it is 
convenient for the user (unfortunately many commercial access point 
firmware don't allow to disable this option completely).
 
[...]
 The built-in world regulatory domain allows *passive* use of channels
 12-13 and other channels that are not permitted in all countries.  That
 is, the kernel will allow passively scanning on those channels and
 connecting to an AP, on the assumption that the AP is following the
 local rules.
[...]

Of course you're right, passive scanning mitigates this problem to 
quite some extent. Active scanning (which is faster and would be 
required for connecting to hidden SSIDs (which are a bad idea, but 
still common; of course netcfg would have to learn to support this 
as well) and 802.11d aren't available this way.

Regards
Stefan Lippers-Hollmann

[1] This should cover most consumer routers/ access points


signature.asc
Description: This is a digitally signed message part.


Bug#760712: WEP vs WPA2

2014-09-15 Thread Stefan Lippers-Hollmann
 packages, both look identical…
 
   linux-image-3.16-1-amd64_3.16.2-3_amd64.deb
   kernel-image-3.16-1-amd64-di_3.16.2-3_amd64.udeb
 
 so that might be something different anyway.

This is less of a configuration (as in kernel .config) problem, but 
more likely to be caused by some (newly) required kernel modules 
providing the functionality for wpa modes missing from the udebs for
d-i.

Taking a simple mac80211 based wlan card (ar5523, USB) as example, 
forced into wext mode mode, I see these wireless modules as required
for wpa2-psk/ ccmp - this is not using the Debian kernel, which might
be slightly less modular:

plugging in ar5523, unconfigured:
+ arc4
+ ar5523 (well, this is the particular module only require for ar5523)
+ mac80211
+ cfg80211
+ rfkill

after starting wpa_supplicant in (forced) wext mode:
+ ctr
+ ccm
+ af_packet

For ath9k, the required module needed on top of the ones above seam
to be (less reliably, as I can't hotplug PCIe):
+ ath9k
+ ath9k_common
+ ath9k_hw
+ ath

Depending on your particular wlan card and how its driver is divided
into sub-modules (or how well it is integrated into other kernel 
subsystems), you might need additional modules as well.


[with my wpa maintainer hat on]
Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can
you give me a rough guide when it's safe to upload in order not to 
interfere with d-i beta2[6]? There are no behavioural changes, besides
many bugfixes[7]. If you want to test it for d-i, the packaging is 
ready (besides the changelog entries) in the normal VCS location[8].

Regards
Stefan Lippers-Hollmann

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/feature-removal-schedule.txt?id=v3.6#n422
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683281#10
[4] https://dev.openwrt.org/browser/trunk/package/network/utils/iwinfo
it only needs trivial modifications to the buildsystem to work in 
Debian. A pure nl80211 example implementation would be found in iw.
[6] https://lists.debian.org/debian-cd/2014/09/msg00027.html
Subject: (Almost) Time for Jessie Beta 2?
[7] probably particularly important to eduroam setups, although this 
particular configuration isn't supported by netcfg and can only be 
used in a full installation
[8] Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/
Vcs-Svn: svn://anonscm.debian.org/pkg-wpa/wpa/trunk/
http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.dsc
http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.debian.tar.xz
http://aptosid.com/slh/wpa/wpa_2.2.orig.tar.xz


signature.asc
Description: This is a digitally signed message part.


Bug#760712: WEP vs WPA2

2014-09-15 Thread Stefan Lippers-Hollmann
Hi

On Monday 15 September 2014, Cyril Brulebois wrote:
 Stefan Lippers-Hollmann s@gmx.de (2014-09-15):
[...]

Seeing that the actual problem are missing kernel modules for 
CCMP (AES), and probably TKIP as well, I'll concentrate on your
new questions only

 Based on your answer, I'm wondering whether there might be some CONFIG_*
 differences between wpasupplicant and its udeb, which might explain?

There are significant CONFIG_* differences between the regular 
wpasupplicant and wpasupplicant-udeb, both to get it smaller and to
avoid dependencies on packages not providing udebs, but the udeb
should support:

- no encryption
- WEP64
- WEP128
- WPAPSK v1 TKIP/ CCMP
- WPAPSK2 TKIP/ CCMP

More advanced setups, like IEEE8021X (using certificates and per-user 
encryption, e.g. eduroam and other commercial setups), smartcards and
are not supported by the udeb (nor would netcfg know how to configure
these).

[ o.k., the following three paragraphs have been obsoleted by your
 other mail ]
|As a quick test I have bind-mounted the wpa_supplicant binary from 
|wpasupplicant-udeb over /sbin/wpa_supplicant of a full installation
|and successfully tested:
|
|# wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf 
|Successfully initialized wpa_supplicant
|wlan0: CTRL-EVENT-SCAN-STARTED 
|wlan0: SME: Trying to authenticate with 01:23:45:67:89:ab (SSID='test' 
freq=2472 MHz)
|wlan0: Trying to associate with 01:23:45:67:89:ab (SSID='test' freq=2472 MHz)
|wlan0: Associated with 01:23:45:67:89:ab
|wlan0: WPA: Key negotiation completed with 01:23:45:67:89:ab [PTK=CCMP 
GTK=CCMP]
|wlan0: CTRL-EVENT-CONNECTED - Connection to 01:23:45:67:89:ab completed [id=4 
id_str=test_aes]
|wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE
|wlan0: WPA: Group rekeying completed with 01:23:45:67:89:ab [GTK=CCMP]
|
|# wpa_cli status
|Selected interface 'wlan0'
|bssid=01:23:45:67:89:ab
|ssid=test
|id=4
|id_str=test_aes
|mode=station
|pairwise_cipher=CCMP
|group_cipher=CCMP
|key_mgmt=WPA2-PSK
|wpa_state=COMPLETED
|ip_address=10.20.27.0
|address=ba:98:76:54:43:21
|
|This is 802.11bgn, using WPA2PSK and CCMP (AES) encryption with an 
|Atheros AR9285 (ath9k) wlan card, so relatively comparable to the 
|original submitter (while I have rtl8192du, I currently don't have 
|access to any wlan card supported by rtl8192cu). Accordingly the udeb 
|config for wpasupplicant (at least on linux) should be fine.

This reminds me, without regulatory domain support (iw(semi-optional), 
crda, wireless-regdb) only the channels allowed for world-roaming
(slightly depending on what the individual wlan drivers and firmwares
understand under world-roaming) would be available, which means channel
1-11 (no access to 12/13) and very little, if anything, in the 5 GHz 
band.

[...]
  [with my wpa maintainer hat on]
  Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can
  you give me a rough guide when it's safe to upload in order not to 
  interfere with d-i beta2[6]? There are no behavioural changes, besides
  many bugfixes[7]. If you want to test it for d-i, the packaging is 
  ready (besides the changelog entries) in the normal VCS location[8].
 
 Well currently, as far as I can see/test, WPA support in d-i isn't
 exactly working nicely, so I don't think a wpa upload is going to hurt
 much. Quite the contrary, hopefully.

Thanks, I'll do some final testing (and add CONFIG_DEBUG_SYSLOG=y, as 
requested in your other mail) and will try to get the new version 
sponsored quickly.

Regards
Stefan Lippers-Hollmann


signature.asc
Description: This is a digitally signed message part.


Bug#679377: Segmentation fault when initramfs is booting

2012-07-08 Thread Stefan Lippers-Hollmann
Hi

On Saturday 07 July 2012, Michael Tokarev wrote:
[…]
 On 05.07.2012 15:12, Jordi Pujol wrote:
 []
  the patch shell-ash-export-HOME.patch causes a segmentation fault when
  initramfs boots,
  I believe that this fault occurs the first time that initramfs looks for
  some executable in the initramfs filesystem,
 
 Big thanks to Denys Vlasenko, the issue has been identified.
[…]
 I added a temporary workaround to this patch - making
 the default PATH variable to be non-const, ie, writable,
 this way awk will be able to write to it.  No other parts
 of the code tries to write to it, so it is a safe change.
[…]

Thanks a lot for your and Denys Vlasenko's efforts, this workaround in 
busybox 1:1.20.0-5 works fine for my use case :)

Regards
Stefan Lippers-Hollmann



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201207090235.10692.s@gmx.de



Bug#679377: Segmentation fault when initramfs is booting

2012-07-04 Thread Stefan Lippers-Hollmann
Hi

On Wednesday 04 July 2012, Michael Tokarev wrote:
[…]
 On 28.06.2012 13:14, Jordi Pujol wrote:
[…] 
  the patch shell-ash-export-HOME.patch causes a segmentation fault when 
  initramfs boots,
  I believe that this fault occurs the first time that initramfs looks for 
  some 
  executable in the initramfs filesystem,
 
 Does whole thing actually work?  Why do you think it is this patch
 which causes the SIGSEGV?  The change in this patch is quite, well,
 innocent, it does not look like it can be a cause for any such issues.

I'm having trouble with the same problem in a custom (not Debian live)
live boot environment, where busybox awk segfaults with 
shell-ash-export-HOME.patch applied. The code in question is[1]:

FINGERED=$(awk -F: '
$1 == drive name  NF  1 {
split($2, node,  )
for (n in node) {
if (!system(test -b /dev/ node[n]))
cdrom[i++] = /dev/ node[n]
}
}
END {
for (c in cdrom)
print cdrom[c]
}
' /proc/sys/dev/cdrom/info)

Leading to:

Loading, please wait...
modprobe: module unix not found in modules.dep
mdadm: No arrays found in config file or automatically
Segmentation fault
Waiting for up to 30s for devices to settle...
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
Failed to detect live media
modprobe: module i8042 not found in modules.dep
modprobe: module atkbd not found in modules.dep


BusyBox v1.20.1 (Debian 1:1.20.0-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)


Executing the very same awk command from the initramfs shell (busybox 
ash) afterwards succeeds however:

(initramfs) FINGERED=$(awk -F: '
 $1 == drive name  NF  1 {
 split($2, node,  )
 for (n in node) {
 if (!system(test -b /dev/ node[n]))
 cdrom[i++] = /dev/ node[n]
 }
 }
 END {
 for (c in cdrom)
 print cdrom[c]
 }
 ' /proc/sys/dev/cdrom/info)
(initramfs) echo $FINGERED
/dev/sr0

Likewise rewriting the /proc/sys/dev/cdrom/info parsing to use 
different busybox applets succeeds as well, while using awk in 
different functions (fll_meminfo() and fll_copy_with_perc()) segfaults 
the same way.

 Can you describe your initramfs/environment a bit?  Maybe give me
 access to your initramfs for testing?

I'll provide a link to a test environment in a (private) follow up 
mail, using this live code. While this particular initramfs hook is 
not packaged in Debian, I expect similar issues to arise with standard
Debian initramfs hooks.

  Also, the latest release of busybox, 1.20.1 is a bit different of that, and 
 
 Different of what, exactly?  The version of busybox you're
 filing bugreport against is actually 1.20.1, so there are
 two questions actually: what is different, and different
 between what and what? -- since you're comparing the same
 thing with itself.
[…]

For testing purposes, I've rebuilt busybox (1:1.20.0-4) with only
shell-ash-export-HOME.patch disabled:

--- busybox-1.20.0/debian/patches/series
+++ busybox-1.20.0/debian/patches/series
@@ -1,6 +1,6 @@
 1.20.1.patch
 
-shell-ash-export-HOME.patch
+#shell-ash-export-HOME.patch
 # we need to get rid of this one:
 #applets-fallback.patch
 version.patch

and the segfaults in busybox awk vanished.

Regards
Stefan Lippers-Hollmann

[1] 
http://svn.berlios.de/svnroot/repos/fullstory/fll-live-initramfs/trunk/scripts/fll


signature.asc
Description: This is a digitally signed message part.


Re: [pkg-wpa-devel] libnl3 soname change

2011-12-19 Thread Stefan Lippers-Hollmann
Hi

On Monday 19 December 2011, Heiko Stübner wrote:
 Am Montag, 19. Dezember 2011, 09:03:47 schrieb Gaudenz Steinlin:
  On Sun, 18 Dec 2011 20:16:08 +0100, Heiko Stübner he...@sntech.de wrote:
   Am Donnerstag 15 Dezember 2011, 22:13:43 schrieb Stefan Lippers-Hollmann:
On Thursday 15 December 2011, Joey Hess wrote:
 Heiko Stübner wrote:
  So the question would be on how to proceed to get this into
  unstable without breaking to much.
[...]
I have prepared and tested (for the non-udeb cases, see below) iw[1]
and wpasupplicant[2] in svn now, likewise hostapd[3] will switch to
libnl-3 = 3.2 (from libnl1) after it gets available in unstable (no
urgency at all).

Something seems to be missing for the udeb handling though:
Package: wpasupplicant-udeb
[...]
Depends: libc6-udeb (= 2.13), libcrypto1.0.0-udeb (= 1.0.0),
libnl-3-200-udeb (= 3.2.3), libnl-genl-3-200, busybox-udeb

[...] 
   As I did not split the udeb libnl-genl-3 resides at the moment in
   libnl-3-200- udeb. The dependencies all have a -udeb in its package
   name, but libnl- genl-3-200 has not. So my guess would be, that a
   libnl-genl-3-200-udeb is also necessary.
  
  I'll try to look into the udeb issues but not before Thursday this week.
  If anyone has time to do this before I'm more than happy. If you have
  any specific questions I can answer mails even before.
 does the following look remotely sane? (I.e. it creates a
 libnl-genl-3-200-udeb with the correct library)
 
 From c826b7a811a7931dd151b9c28aad93eda7af321f Mon Sep 17 00:00:00 2001
 From: Heiko Stuebner heiko.stueb...@nexst4.de
 Date: Mon, 19 Dec 2011 10:30:51 +0100
 Subject: [PATCH 1/2] create a libnl-genl-udeb

Yes, that results in correct dependencies for the udeb, thanks a lot:

Package: wpasupplicant-udeb
[...]
Depends: libc6-udeb (= 2.13), libcrypto1.0.0-udeb (= 1.0.0), libnl-3-200-udeb 
(= 3.2.3), libnl-genl-3-200-udeb (= 3.2.3), busybox-udeb

Regards
Stefan Lippers-Hollmann


signature.asc
Description: This is a digitally signed message part.


Re: [pkg-wpa-devel] libnl3 soname change

2011-12-19 Thread Stefan Lippers-Hollmann
Hi

On Monday 19 December 2011, Heiko Stübner wrote:
 Am Donnerstag 15 Dezember 2011, 22:13:43 schrieb Stefan Lippers-Hollmann:
  On Thursday 15 December 2011, Joey Hess wrote:
   Heiko Stübner wrote:
[...]
  For iw (which is needed by crda's udev rules), it would be nice to
  have libnl.so.3 and libnl-genl.so.3 in /lib/ (#622247: iw binary should
  be installed in /sbin). The wpasupplicant package would also profit
  from that (#537790), although it is haunted by openssl and zlib as
  dependencies well.
 
 As libnl seems to be used by a lot of system-level programs, should only 
 these 
 two libs move to /lib or all?

Looking at the reverse dependencies, these packages appear to profit 
from libnl3 being available from /lib/.

libnl3:
iw - tool for configuring Linux wireless devices
executed from a udev rule (shipped by crda) to set regulatory 
domain 
hints for mac80211 based wlan drivers

wpasupplicant - client support for WPA and WPA2 (IEEE 802.11i)
e.g. nfs mounting /usr/ over wpa/ wpa2 encrypted wlan

libnl2:
apparently none critical

libnl1:
crda - wireless Central Regulatory Domain Agent
udev rule to set regulatory domain hints for mac80211 based 
wlan 
drivers, can be switched to libnl-3 trivially (I'm going submit 
an 
according patch upstream and to Debian)

ipcfg - Network configuration system
ifupdown replacement (experimental only), currently located in 
/usr/bin/ would need porting to libnl3

The other reverse dependencies of the various libnl variants appear not
to be required during early boot, before /usr/ gets mounted, at a first
glance.

iw, wpasupplicant (hostapd) and crda only need libnl-3.so.200 and 
libnl-genl-3.so.200.

Regards
Stefan Lippers-Hollman


signature.asc
Description: This is a digitally signed message part.


Re: [pkg-wpa-devel] libnl3 soname change

2011-12-15 Thread Stefan Lippers-Hollmann
Hi

On Thursday 15 December 2011, Joey Hess wrote:
 Heiko Stübner wrote:
  So the question would be on how to proceed to get this into unstable 
  without 
  breaking to much.
[...]

I have prepared and tested (for the non-udeb cases, see below) iw[1] and
wpasupplicant[2] in svn now, likewise hostapd[3] will switch to 
libnl-3 = 3.2 (from libnl1) after it gets available in unstable (no 
urgency at all). 

Something seems to be missing for the udeb handling though:
Package: wpasupplicant-udeb
[...]
Depends: libc6-udeb (= 2.13), libcrypto1.0.0-udeb (= 1.0.0), libnl-3-200-udeb 
(= 3.2.3), libnl-genl-3-200, busybox-udeb


I'm not overly familiar with udeb specifics, but I think this is 
missing something equivalent to
DEB_DH_MAKESHLIBS_ARGS_libnl-3-200 := -Vlibnl-3-200 (= 
$(DEB_UPSTREAM_VERSION)) --add-udeb=$(udeb)
in libnl3's debian/rules.

We can look for upload sponsoring as needed, at least once the udeb 
issue with wpasupplicant is settled.

  Another question for the installer folks: should the udeb stay as it is, or 
  should it be split too.
 
 d-i only needs it for wpasupplicant, so if that does not need all the
 libraries, some could be dropped from the udeb. Otherwise, I see no
 point of splitting the udeb.
 
 joey@gnu:~ldd =wpa_supplicant|grep libnl
   libnl.so.3 = /usr/lib/libnl.so.3 (0xb7707000)
   libnl-genl.so.3 = /usr/lib/libnl-genl.so.3 (0xb7702000)
 
 Perhaps it only needs those 2, but I have not checked closely.

All afforementioned packages only need those two. Additionally I've 
taken a look at crda (disclaimer, I've been involved in the initial 
packaging, but am currently not its maintainer) which would only need
those as well (it's currently still using libnl1); crda is required by 
mac80211 based kernel modules to switch regulatory domains (access 
channel 12-14 or basically any 5 GHz channel) both interactively 
(iw reg set country code, like US, DE, /etc/default/crda) or 
non-interactively through EEPROM/ OTP regdom hints).


For iw (which is needed by crda's udev rules), it would be nice to 
have libnl.so.3 and libnl-genl.so.3 in /lib/ (#622247: iw binary should
be installed in /sbin). The wpasupplicant package would also profit 
from that (#537790), although it is haunted by openssl and zlib as 
dependencies well.

Regards
Stefan Lippers-Hollmann

[1] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/iw/trunk/
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/iw/trunk/
[2] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/wpasupplicant/trunk/
Vcs-Browser: 
http://anonscm.debian.org/viewvc/pkg-wpa/wpasupplicant/trunk/
[3] Vcs-Svn: svn://anonscm.debian.org/svn/pkg-wpa/hostapd/trunk/
Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/hostapd/trunk/


signature.asc
Description: This is a digitally signed message part.


Bug#646284: dropping applets-fallback breaks initramfs images

2011-10-22 Thread Stefan Lippers-Hollmann
Package: busybox
Version: 1:1.19.2-1
Severity: grave
Justification: Breaks system booting using initramfs-tools in non-trivial ways.
Tags: patch
X-Debbugs-CC: Debian kernel team debian-ker...@lists.debian.org

Hi

Initramfs images generated by initramfs-tools 0.99 after busybox got 
upgraded to 1:1.19.2-1 fail to boot with the following error messages:

Loading, please wait...
/init: line 11: mount: not found
/init: line 12: mount: not found
/init: line 25: mount: not found
W: devtmpfs not available, falling back to tmpfs for /devtmpfs
/init: line 25: mount: not found
/init: line 27: mount: not found
/init: line 28: mount: not found
cat: can't open '/proc/cmdline': No such file or directory
cat: can't open '/proc/cmdline': No such file or directory
/scripts/init-top/udev: line 14: can't create /sys/kernel/uevent_helper: 
nonexistent directory
Begin: Loading essential drivers ... done
Begin: Running /scripts/init-premount ... done
Begin: Mounting root file system .. Begin: Running /scripts/local-top .. [
0.742185] device-mapper: uevent: version 1.0.3
[0.746854] device-mapper: ioctl 4.21.0-ioctl (2011-07-06) initialised: 
dm-de...@redhat.com
done.
Begin: Running /scripts/local-premount ... [ 0.765009] Btrfs loaded
done.
/init: line 5: mount: not found
Begin: Running /scripts/local-bottom ... done
done.
Begin: Running /scripts/init-bottom ... done
/init: line 239: mv: not found
/init: line 239: umount: not found
/init: line 242: mount: not found
/init: line 243: mount: not found
Target filesystem doesn't have requested /sbin/init.
/init: line 291: chvt: not found
No init found. Try passing init= bootarg.


BusyBox v1.19.2 (Debian 1:1.19.2-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs)


needed initramfs-tools hooks on this system:

$ dpkg -S /usr/share/initramfs-tools/hooks/*
initramfs-tools: /usr/share/initramfs-tools/hooks/busybox
dmsetup: /usr/share/initramfs-tools/hooks/dmsetup
initramfs-tools: /usr/share/initramfs-tools/hooks/keymap
initramfs-tools: /usr/share/initramfs-tools/hooks/klibc
lvm2: /usr/share/initramfs-tools/hooks/lvm2
initramfs-tools: /usr/share/initramfs-tools/hooks/thermal
udev: /usr/share/initramfs-tools/hooks/udev

Re-instating applets-fallback.patch in busybox 1:1.19.2-1 however fixes
this reproducable boot failure, quick'n'dirty rediff (tested on 
amd64  i386, using systems with mdadm, lvm2 or nothing special at 
all) attached.

Regards
Stefan Lippers-Hollmann

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1-rc10-aptosid-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages busybox depends on:
ii  libc6  2.13-21

busybox recommends no packages.

busybox suggests no packages.

-- no debconf information
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -7394,23 +7394,8 @@ static int builtinloc = -1; /* index
 
 
 static void
-tryexec(IF_FEATURE_SH_STANDALONE(int applet_no,) char *cmd, char **argv, char **envp)
+tryexec(char *cmd, char **argv, char **envp)
 {
-#if ENABLE_FEATURE_SH_STANDALONE
-	if (applet_no = 0) {
-		if (APPLET_IS_NOEXEC(applet_no)) {
-			clearenv();
-			while (*envp)
-putenv(*envp++);
-			run_applet_no_and_exit(applet_no, argv);
-		}
-		/* re-exec ourselves with the new arguments */
-		execve(bb_busybox_exec_path, argv, envp);
-		/* If they called chroot or otherwise made the binary no longer
-		 * executable, fall through */
-	}
-#endif
-
  repeat:
 #ifdef SYSV
 	do {
@@ -7465,24 +7450,21 @@ shellexec(char **argv, const char *path,
 	int e;
 	char **envp;
 	int exerrno;
-#if ENABLE_FEATURE_SH_STANDALONE
-	int applet_no = -1;
-#endif
 
 	clearredir(/*drop:*/ 1);
 	envp = listvars(VEXPORT, VUNSET, /*end:*/ NULL);
-	if (strchr(argv[0], '/') != NULL
-#if ENABLE_FEATURE_SH_STANDALONE
-	 || (applet_no = find_applet_by_name(argv[0])) = 0
-#endif
-	) {
-		tryexec(IF_FEATURE_SH_STANDALONE(applet_no,) argv[0], argv, envp);
+	if (strchr(argv[0], '/') != NULL) {
+		tryexec(argv[0], argv, envp);
 		e = errno;
 	} else {
+#if ENABLE_FEATURE_SH_STANDALONE
+		bb_execv_applet(argv[0], argv, envp);
+#endif
+
 		e = ENOENT;
 		while ((cmdname = path_advance(path, argv[0])) != NULL) {
 			if (--idx  0  pathopt == NULL) {
-tryexec(IF_FEATURE_SH_STANDALONE(-1,) cmdname, argv, envp);
+tryexec(cmdname, argv, envp);
 if (errno != ENOENT  errno != ENOTDIR)
 	e = errno;
 			}
--- a/libbb/execable.c
+++ b/libbb/execable.c
@@ -9,6 +9,9 @@
 
 #include libbb.h
 
+#include alloca.h
+#include stdarg.h
+
 /* check if path points to an executable file;
  * return 1 if found;
  * return 0 otherwise;
@@ -68,13 +71,60 @@ int FAST_FUNC exists_execable(const char
 }
 
 #if ENABLE_FEATURE_PREFER_APPLETS
+int FAST_FUNC bb_execv_applet(const char *name, char *const argv[], char *const envp

Bug#636353: kernel-wedge: nic-wireless-modules missing carl9170

2011-08-02 Thread Stefan Lippers-Hollmann
Package: kernel-wedge
Version: 2.78
Severity: normal
Tags: d-i

Hi

/lib/modules/$(uname -r)/kernel/drivers/net/wireless/ath/carl9170/carl9170.ko
is omitted in kernel-wedge, which is needed to support Atheros AR9170 
802.11n USB wlan devices:

[ 4818.243562] usb 3-1.3: new high speed USB device number 10 using ehci_hcd
[ 4818.380140] usb 3-1.3: New USB device found, idVendor=0cf3, idProduct=9170
[ 4818.380145] usb 3-1.3: New USB device strings: Mfr=16, Product=32, 
SerialNumber=48
[ 4818.380148] usb 3-1.3: Product: USB2.0 WLAN
[ 4818.380150] usb 3-1.3: Manufacturer: ATHER
[ 4818.380152] usb 3-1.3: SerialNumber: 12345
[ 4818.453938] usb 3-1.3: reset high speed USB device number 10 using ehci_hcd
[ 4819.086308] usb 3-1.3: driver   API: 1.9.2 2011-01-22 [1-1]
[ 4819.086314] usb 3-1.3: firmware API: 1.9.4 2011-06-30
[ 4819.086318] usb 3-1.3: Unprotected firmware image.
[ 4819.086322] usb 3-1.3: driver does not support all firmware features.
[ 4819.439453] ath: EEPROM regdomain: 0x65
[ 4819.439456] ath: EEPROM indicates we should expect a direct regpair map
[ 4819.439459] ath: Country alpha2 being used: 00
[ 4819.439461] ath: Regpair used: 0x65
[ 4819.439549] ieee80211 phy3: Selected rate control algorithm 'minstrel_ht'
[ 4819.441584] Registered led device: carl9170-phy3::tx
[ 4819.441605] Registered led device: carl9170-phy3::assoc
[ 4819.441608] usb 3-1.3: Atheros AR9170 is registered as 'phy3'

A patch aganst kernel-wedge/ nic-wireless-modules follows, once I know 
the bug number.

Regards
Stefan Lippers-Hollmann


signature.asc
Description: This is a digitally signed message part.


Bug#636353: kernel-wedge: nic-wireless-modules missing carl9170

2011-08-02 Thread Stefan Lippers-Hollmann
tags 636353 + patch
thanks

Hi

Attached is the promised patch against kernel-wedge/ 
nic-wireless-modules.

Regards
Stefan Lippers-Hollmann

From bb3ed72e0f3a761e7fed7fb1c389f145ec182b5b Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann s@gmx.de
Date: Tue, 2 Aug 2011 16:33:24 +0200
Subject: [PATCH] add carl9170 to nic-wireless-modules

It's needed to support Atheros 9170 USB wlan cards. Closes: #636353.

Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
This applies after 0002-add-ath9k_htc-to-nic-wireless-modules-in-oder-to-sup
submitted in #636321.

 debian/changelog |4 +++-
 modules/nic-wireless-modules |1 +
 2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 67d27fc..16d683d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,8 +9,10 @@ kernel-wedge (2.79) UNRELEASED; urgency=low
 nic-wireless-modules, needed for e.g. ipw2x00 wlan modules. Closes: #636259.
   * add ath9k_htc to nic-wireless-modules, in oder to support Atheros AR9271
 USB wlan cards. Closes: #636321.
+  * add carl9170 to nic-wireless-modules, in oder to support Atheros 9170
+USB wlan cards. Closes: #636351.
 
- -- Stefan Lippers-Hollmann s@gmx.de  Tue, 02 Aug 2011 16:29:19 +0200
+ -- Stefan Lippers-Hollmann s@gmx.de  Tue, 02 Aug 2011 16:31:16 +0200
 
 kernel-wedge (2.78) unstable; urgency=low
 
diff --git a/modules/nic-wireless-modules b/modules/nic-wireless-modules
index 37173ec..d1beca1 100644
--- a/modules/nic-wireless-modules
+++ b/modules/nic-wireless-modules
@@ -16,6 +16,7 @@ usb8xxx ?
 ath5k ?
 ath9k ?
 ath9k_htc ?
+carl9170 ?
 iwlagn ?
 iwl3945 ?
 b43 ?
-- 
1.7.5.4



signature.asc
Description: This is a digitally signed message part.


Bug#636321: [pkg-wpa-devel] Bug#636321: wpasupplicant-udeb: TP-LINK WN722N (AR9271) not detected as usable wlan interface

2011-08-02 Thread Stefan Lippers-Hollmann
clone 636321 -1
retitle -1 kernel-wedge: nic-wireless-modules missing rt2800{pci,usb}
tags -1 - patch
tags -1 + d-i
thanks

On Tuesday 02 August 2011, mathieu.mil...@gmail.com wrote:
 Hi,
 All my tests were done with the extracted archive of firmwares available at 
 this address: 
 http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/unstable/current/
 
 I've also tested a rt2800 usb key, same symptons as the atheros usb key.
 I understand wpasupplicant-udeb is a new package and need testing, and all i 
 can do is testing (i don't know much in linux dev).

Same story as with ath9k_htc, kernel-wedge omits installing the 
required kernel modules.

 Stefan Lippers-Hollmann s@gmx.de a écrit :
[...]
  I don't know if this bug report is to be associated with
  wpasupplicant(-udeb)
  (or netcfg ?). Feel free to correct me.
 
 After a second look, no it's not - it's again a bug in kernel-wedge. 
 The kernel module needed by your AR9271 device, namely ath9k_htc, is
 not copied to the nic-wireless-modules udeb.
 
 wpasupplicant has only two modes of operation (well, tree - if you also
 count encrypted wired ethernet, but this is not present in the udeb and
 pretty rare), wext (legacy and strongly discourages, like your ipw2200)
 and nl80211 (all mac80211 based drivers, like your rt2500usb, ath5k, 
 ath9k_htc) - if it works for one of each group, it usually works for
 all. Hardware dependent bugs are then usually courtesy of kernel bugs,
 missing firmwares or - as in this case - kernel-wedge forgetting 
 important kernel modules, because wpasupplicant only knows 2 kinds of
 'hardware' (abstractions) wext or nl80211. wpasupplicant only 'gets a 
 chance' to mess up again, if it has to deal with different encryption
 methods (WEP vs. WPA1/ TKIP vs. WPA2/ CCMP vs. IEEE80211X, vs. even 
 more complex sceanarios), but keep in mind that in order to keep the
 wpasupplicant udeb small, more exotic flavours of encryption have been
 omitted from the udeb.
 
 Therefore please check if the required kernel modules and firmware 
 blobs are present to d-i/ netcfg, before filing further bugs against
 the wpasupplicant package.
 
  I've burned the i386 unstable netinstall as of 2011-08-01 and tried to
  connect
  to my WPA-PSK network.
  Plugged in my AR9271 usb key, and got this from the logs (end of the
  attached log):
[...]
  Aug 2 07:55:11 kernel: [ 209.204880] usb 1-6: New USB device found,
  idVendor=0cf3, idProduct=9271
[...]
  No new interface detected in d-i, can't use this wifi key with d-i.
 
 No wonder, if there is no kernel module to drive it, see attached patch
 against kernel-wedge (untested).

A patch against kernel-wedge will follow, once I know the newly
assigned bug number.

Regards
Stefan Lippers-Hollmann


signature.asc
Description: This is a digitally signed message part.


Bug#636385: [PATCH] kernel-wedge: add rt2800{pci,usb} to nic-wireless-modules

2011-08-02 Thread Stefan Lippers-Hollmann
tags 636385 + patch
thanks

Hi

Attached is the required patch to pull rt2800{pci,usb} into 
nic-wireless-modules.

Regards
Stefan Lippers-Hollmann
From d0d2781695dae9a00794141c08c62874fdfae63e Mon Sep 17 00:00:00 2001
From: Stefan Lippers-Hollmann s@gmx.de
Date: Tue, 2 Aug 2011 22:03:02 +0200
Subject: [PATCH] add rt2800{pci,usb} to nic-wireless-modules

In oder to support RaLink 802.11n wlan cards.
Closes: #636385

Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
This applies after 0003-add-carl9170-to-nic-wireless-modules-in-oder-to-supp
submitted in #636353.

 debian/changelog |2 ++
 modules/nic-wireless-modules |4 +++-
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 16d683d..5645935 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -11,6 +11,8 @@ kernel-wedge (2.79) UNRELEASED; urgency=low
 USB wlan cards. Closes: #636321.
   * add carl9170 to nic-wireless-modules, in oder to support Atheros 9170
 USB wlan cards. Closes: #636351.
+  * add rt2800{pci,usb} to nic-wireless-modules, in oder to support RaLink
+802.11n wlan cards. Closes: #636385.
 
  -- Stefan Lippers-Hollmann s@gmx.de  Tue, 02 Aug 2011 16:31:16 +0200
 
diff --git a/modules/nic-wireless-modules b/modules/nic-wireless-modules
index d1beca1..2a1ae11 100644
--- a/modules/nic-wireless-modules
+++ b/modules/nic-wireless-modules
@@ -23,9 +23,11 @@ b43 ?
 brcmsmac ?
 
 # rt2x00 drivers
+rt2400pci ?
 rt2500pci ?
 rt2500usb ?
-rt2400pci ?
+rt2800pci ?
+rt2800usb ?
 rt61pci ?
 rt73usb ?
 
-- 
1.7.5.4



signature.asc
Description: This is a digitally signed message part.


Bug#623981: 90linux-distro: 132: Syntax error: end of file unexpected (expecting fi)

2011-04-24 Thread Stefan Lippers-Hollmann
Package: os-prober
Version: 1.45
Severity: important
Tags: patch

Hi

90linux-distro: fix sh syntax for Linux from scratch detection.

Upgrading os-prober to 1.45 results in the following error message upon
invoking update-grub (and prevents later scripts from getting 
executed).

# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-[...]
Found initrd image: /boot/initrd.img-[...]
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
/usr/lib/os-probes/mounted/90linux-distro: 132: Syntax error: end of file 
unexpected (expecting fi)
[...]

Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
 os-probes/mounted/common/90linux-distro |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -Nru a/os-probes/mounted/common/90linux-distro 
b/os-probes/mounted/common/90linux-distro
--- a/os-probes/mounted/common/90linux-distro
+++ b/os-probes/mounted/common/90linux-distro
@@ -115,7 +115,7 @@
elif [ -e $dir/etc/kdemar-release ]; then
short=K-DEMar
long=$(printf K-DEMar GNU/Linux (%s)\n $(cat 
$dir/etc/kdemar-release))
-   if [ -e $dir/etc/lfs-release ]; then
+   elif [ -e $dir/etc/lfs-release ]; then
short=LFS
long=$(printf Linux From Scratch (%s)\n $(cat 
$dir/etc/lfs-release))
else
-- 

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.38-4.slh.2-aptosid-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages os-prober depends on:
ii  libc6 2.11.2-13  Embedded GNU C Library: Shared lib

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104250301.31845.s@gmx.de



Bug#614315: requires no longer created MD5Sum checksums in Release file

2011-02-20 Thread Stefan Lippers-Hollmann
Package: debootstrap
Version: 1.0.27
Severity: important

Hi

Since today[1], ftp-master doesn't generate md5 checksums for Release/ 
InRelease anymore, thereby breaking debootstrap for all suites which 
got rebuilt since the change (wheezy/ sid, squeeze hasn't been 
regenerated yet).

# debootstrap --arch=amd64 --variant=minbase --verbose sid /mnt/ 
http://ftp.de.debian.org/debian
I: Retrieving Release
E: Invalid Release file, no entry for main/binary-amd64/Packages

Using different target architectures has no effect, while switching to 
as-of-yet-unsynched mirrors (like ftp.at.debian.org) succeeds.

Regards
Stefan Lippers-Hollmann

[1] http://lists.debian.org/debian-devel-announce/2011/02/msg8.html

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-1.slh.1-aptosid-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages debootstrap depends on:
ii  wget  1.12-2.1   retrieves files from the web

Versions of packages debootstrap recommends:
ii  gnupg 1.4.11-3   GNU privacy guard - a free PGP rep

debootstrap suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201102210015.42076.s@gmx.de



util-linux: missing dependency on initscripts breaks installing in cdebootstrap/ debootstrap

2010-05-12 Thread Stefan Lippers-Hollmann
-1_amd64.deb) ...
P: Unpacking package e2fsprogs
D: Updating e2fsprogs to status 2
[...]
O: Setting up util-linux (2.17.2-1) ...
P: Configuring package util-linux
D: Updating util-linux to status 3
O: update-alternatives: using /bin/more to provide /usr/bin/pager (pager) in 
auto mode.
O: insserv: Service checkroot has to be enabled to start service hwclock
O: insserv: exiting now!
O: update-rc.d: error: insserv rejected the script header
O: Setting up mount (2.17.2-1) ...
P: Configuring package mount
D: Updating mount to status 3
O: dpkg: error processing util-linux (--configure):
O:  subprocess installed post-installation script returned error exit status 1
O: Setting up initscripts (2.87dsf-10) ...
P: Configuring package initscripts
D: Updating initscripts to status 3
O: dpkg: dependency problems prevent configuration of e2fsprogs:
O:  e2fsprogs depends on util-linux (= 2.15~rc1-1); however:
O:   Package util-linux is not configured yet.
O: dpkg: error processing e2fsprogs (--configure):
O:  dependency problems - leaving unconfigured
O: Setting up sysvinit (2.87dsf-10) ...
P: Configuring package sysvinit
D: Updating sysvinit to status 3
O: sysvinit: creating /dev/initctl
O: init: 
O: timeout opening/writing control channel /dev/initctl
O: Errors were encountered while processing:
O:  util-linux
O:  e2fsprogs
D: Status: 256
E: Internal error: install

This basically re-opens the same issues that were reported in #546834 
(archived by now).

Regards
Stefan Lippers-Hollmann


util-linux: Re-add accidentally dropped dependency on initscripts

This fixes the return of #546834.

Signed-off-by: Stefan Lippers-Hollmann s@gmx.de

--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Architecture: any
 Section: utils
 Priority: required
 Essential: yes
-Depends: lsb-base (= 3.0-6), tzdata (=2006c-2), install-info, ${misc:Depends}
+Depends: lsb-base (= 3.0-6), tzdata (=2006c-2), initscripts, install-info, 
${misc:Depends}
 Pre-Depends: ${shlibs:Depends}
 Suggests: util-linux-locales, kbd | console-tools, dosfstools
 Replaces: schedutils, miscutils, setterm, fdisk, linux32, sparc-utils, 
e2fsprogs, ${util-linux:Conflicts}



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-rc7-sidux-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages util-linux depends on:
ii  install-info4.13a.dfsg.1-5   Manage installed documentation in 
ii  libblkid1   2.17.2-1 block device id library
ii  libc6   2.10.2-8 Embedded GNU C Library: Shared lib
ii  libncurses5 5.7+20100313-2   shared libraries for terminal hand
ii  libselinux1 2.0.94-1 SELinux runtime shared libraries
ii  libslang2   2.2.2-4  The S-Lang programming library - r
ii  libuuid12.17.2-1 Universally Unique ID library
ii  lsb-base3.2-23.1 Linux Standard Base 3.2 init scrip
ii  tzdata  2010j-1  time zone and daylight-saving time
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

util-linux recommends no packages.

Versions of packages util-linux suggests:
ii  dosfstools3.0.9-1utilities for making and checking 
ii  kbd   1.15.1-3   Linux console font and keytable ut
pn  util-linux-localesnone (no description available)

-- no debconf information


signature.asc
Description: This is a digitally signed message part.


Bug#472389: busybox: no longer falles back to busybox applets if no executable if found

2008-03-23 Thread Stefan Lippers-Hollmann
Package: busybox
Version: 1:1.9.1-3
Severity: important

CC'ing initramfs-tools maintainer, as it directly affects hooks into 
initramfs-tools.

BusyBox 1.1.3 implemented a fallback to its own applets in case no 
executable could be found:

BusyBox v1.1.3 (Debian 1:1.1.3-5) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ printf foo\n
foo
~ $ PATH=
~ $ export PATH
~ $ printf foo\n
foo

while BusyBox 1.9.1 just throws an error

BusyBox v1.9.1 (2008-03-22 22:06:19 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ printf foo\n
foo
~ $ PATH=
~ $ export PATH
~ $ printf foo\n
ash: printf: not found

Even though this behaviour is understandable, it does break hooks into 
current initramfs-tools making use of functionality neither provided by 
klibc nor busybox built-ins (but only as applets for busybox), because 
initramfs-tools doesn't create {hard,sym}links to busybox (#338405).

Potentially affected packages (not checked in depths):
- bootcd-mkinitramfs (it seems to use grep)
- cryptsetup (it does use basename #466240 and seems to use grep)
- evms (it seems to use grep)
- initramfs-tools (it does use printf and seems to use awk as well)
- live-initramfs (it seems to use awk, basename, grep and printf)
- loop-aes-utils (it seems to use grep)
- ltsp-client-core (it seems to use grep
- mdadm (it seems to use grep)
- nbd-client (it seems to use grep)
- splashy (it seems to use grep)
- uswsusp (it seems to use grep)

A workaround seems to be enabling 
CONFIG_FEATURE_PREFER_APPLETS=y
CONFIG_FEATURE_SH_STANDALONE=y
FEATURE_SH_STANDALONE was enabled in busybox 1.1.3, even though it prefers
busybox applets in favour of shipped executables (unless called with full 
path names), it might be needed until a better long term solution can be found.

Regards
Stefan Lippers-Hollmann

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-2.6.24.3.slh.11-sidux-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages busybox depends on:
ii  libc6 2.7-9  GNU C Library: Shared libraries

busybox recommends no packages.

-- no debconf information


signature.asc
Description: This is a digitally signed message part.


grub: does not support 256 byte inodes on ext3.

2008-01-30 Thread Stefan Lippers-Hollmann
Package: grub
Version: 0.97-29
Severity: normal

*** Please type your report below this line ***
Hi

ext3 filesystems with an inode size of 256 byte cannot be read by the 
read-only file system code of grub 0.97-29 (e2fs_stage1_5 can't be loaded).

Following up #463123 e2fsprogs: grub 0.97 cannot boot ext3 filesystems 
with an inode size of 256 byte, I have reviewed the grub patches by Jesse 
Keating [EMAIL PROTECTED] and Eric Sandeen [EMAIL PROTECTED] 
staging up for Fedora 9:
http://cvs.fedora.redhat.com/viewcvs/devel/grub/grub-support-256byte-inode.patch?view=markup
which depends upon
http://cvs.fedora.redhat.com/viewcvs/devel/grub/grub-fedora-9.patch?view=markup
and came up with the attached patch, which allows grub(-legacy) 0.97 to 
boot from ext3 partitions with 256 byte inodes.

Even though I understand that grub(-legacy) is in feature freeze (grub2 
does already support booting from ext3 partitions with 256 byte inodes), I 
personally would prefer an update to grub 0.97, given that this issue 
leaves the (newly installed/ moved) system unbootable without any chance 
for manual interaction (grub neither installs and dies without any message)
and that the patch seems to be of reasonable size, while grub2 doesn't seem
to be ready for mass deployment.

The attached patch has been tested on several amd64 and i386 systems of 
varying (ext3) filesystem age and seems to work well with 128 byte and 256 
byte inode sizes.

Regards
Stefan Lippers-Hollmann

CC'ing debian-boot on request of Robert Millan

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-slh64-smp-1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

-- no debconf information
diff -Nrup a/stage2/fsys_ext2fs.c b/stage2/fsys_ext2fs.c
--- a/stage2/fsys_ext2fs.c	2004-08-08 20:19:18.0 +0200
+++ b/stage2/fsys_ext2fs.c	2008-01-30 14:27:20.0 +0100
@@ -79,7 +79,52 @@ struct ext2_super_block
 __u32 s_rev_level;		/* Revision level */
 __u16 s_def_resuid;		/* Default uid for reserved blocks */
 __u16 s_def_resgid;		/* Default gid for reserved blocks */
-__u32 s_reserved[235];	/* Padding to the end of the block */
+/*
+ * These fields are for EXT2_DYNAMIC_REV superblocks only.
+ *
+ * Note: the difference between the compatible feature set and
+ * the incompatible feature set is that if there is a bit set
+ * in the incompatible feature set that the kernel doesn't
+ * know about, it should refuse to mount the filesystem.
+ *
+ * e2fsck's requirements are more strict; if it doesn't know
+ * about a feature in either the compatible or incompatible
+ * feature set, it must abort and not try to meddle with
+ * things it doesn't understand...
+ */
+__u32 s_first_ino;		/* First non-reserved inode */
+__u16 s_inode_size;		/* size of inode structure */
+__u16 s_block_group_nr;	/* block group # of this superblock */
+__u32 s_feature_compat;	/* compatible feature set */
+__u32 s_feature_incompat;	/* incompatible feature set */
+__u32 s_feature_ro_compat;	/* readonly-compatible feature set */
+__u8  s_uuid[16];		/* 128-bit uuid for volume */
+char  s_volume_name[16];	/* volume name */
+char  s_last_mounted[64];	/* directory where last mounted */
+__u32 s_algorithm_usage_bitmap; /* For compression */
+/*
+ * Performance hints.  Directory preallocation should only
+ * happen if the EXT2_FEATURE_COMPAT_DIR_PREALLOC flag is on.
+ */
+__u8  s_prealloc_blocks;	/* Nr of blocks to try to preallocate*/
+__u8  s_prealloc_dir_blocks;	/* Nr to preallocate for dirs */
+__u16 s_reserved_gdt_blocks;/* Per group table for online growth */
+/*
+ * Journaling support valid if EXT2_FEATURE_COMPAT_HAS_JOURNAL set.
+ */
+__u8 s_journal_uuid[16];	/* uuid of journal superblock */
+__u32 s_journal_inum;	/* inode number of journal file */
+__u32 s_journal_dev;	/* device number of journal file */
+__u32 s_last_orphan;	/* start of list of inodes to delete */
+__u32 s_hash_seed[4];	/* HTREE hash seed */
+__u8  s_def_hash_version;	/* Default hash version to use */
+__u8  s_jnl_backup_type; 	/* Default type of journal backup */
+__u16 s_reserved_word_pad;
+__u32 s_default_mount_opts;
+__u32 s_first_meta_bg;	/* First metablock group */
+__u32 s_mkfs_time;		/* When the filesystem was created */
+__u32 s_jnl_blocks[17]; 	/* Backup of the journal inode */
+__u32 s_reserved[172];	/* Padding to the end of the block */
   };
 
 struct ext2_group_desc
@@ -218,6 +263,9 @@ struct ext2_dir_entry
 #define EXT2_ADDR_PER_BLOCK(s)  (EXT2_BLOCK_SIZE(s) / sizeof (__u32))
 #define EXT2_ADDR_PER_BLOCK_BITS(s)		(log2(EXT2_ADDR_PER_BLOCK(s)))
 
+#define EXT2_INODE_SIZE(s)		(SUPERBLOCK-s_inode_size)
+#define