~alpine/devel

4 3

[alpine-devel] alpine 3.3.0 rc1 released

Natanael Copa
Details
Message ID
<20151126171801.32e233ba@ncopa-desktop.alpinelinux.org>
Sender timestamp
1448554681
DKIM signature
missing
Download raw message
Hi,

I am happy to announce that Alpine 3.3.0 first release candidate is released.

A few notes for v3.3.0:

- The previous "alpine-mini" image as been renamed to "alpine" and is
  the default iso.

- The previous "alpine" image has been renamed to "alpine-extended" and
  has more packages for troubleshooting. Many application packages have
  been removed. For example asterisk, freeswitch, kamamilio and
  postgresql. Focus is now more on tools which can be handy for rescue,
  network and disk tools. For example btrfs-progs and nfs-utils was
  added.

- The initramfs has been refactored. We no longer depend on specifying
  alpine_dev as boot option. Instead, the boot repositories and apkovl
  should be automatically found using the new nlplug-findfs tool.

- We now only ship boot/syslinux/syslinux.cfg which work for any boot
  media (cdrom, usb...). The boot/syslinux/isolinux.cfg has been
  removed.

- We should now specify modloop path as boot option. This is strictly
  not needed, as the refactored modloop init.d script will try hard to
  find any modloop image. This is for backwards compat.

- The iso images are now isohybrids, so you can create bootable usb
  images with dd. Those can not be used for tmpfs-installs as you
  cannot store any apkvol here. You can still use this with
  setup-bootable, like you do when booting from cdrom.


I would appreciate help with testing:

- boot from usb, using setup-bootable and real hardware. Test that you
  can store apkovl with 'lbu commit'. Do this with:
  - alpine image
  - vanilla image
  - extended image
  - xen image

- test that alpine xen can boot domUs

- test upgrading from v3.2 to v3.3.

- test various different disk install combinations, eg lvm on raid, lvm
  without raid, raid without lvm.


Any other testing is also appreciated. Specially on different kind of
hardware.

Thanks!

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20151128030846.GA2529@newbook>
In-Reply-To
<20151126171801.32e233ba@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1448680127
DKIM signature
missing
Download raw message
On Thu, Nov 26, 2015 at 05:18:01PM +0100, Natanael Copa wrote:
> Hi,
> 
> I am happy to announce that Alpine 3.3.0 first release candidate is released.

Glad to hear it!

[snip]
> Any other testing is also appreciated. Specially on different kind of
> hardware.

Well, I'd like to mention an issue I discovered on an Alpine Linux edge
system I'm using as a wireless router.
dmesg contains a lot of messages like these:
[   10.453071] cfg80211: Calling CRDA to update world regulatory domain
[   13.593462] cfg80211: Calling CRDA to update world regulatory domain
[   16.736817] cfg80211: Calling CRDA to update world regulatory domain
[   19.880084] cfg80211: Calling CRDA to update world regulatory domain
[   23.023427] cfg80211: Calling CRDA to update world regulatory domain
[   26.166723] cfg80211: Calling CRDA to update world regulatory domain
[   29.310142] cfg80211: Calling CRDA to update world regulatory domain
[   32.453458] cfg80211: Calling CRDA to update world regulatory domain
[   35.596777] cfg80211: Calling CRDA to update world regulatory domain
[   38.740183] cfg80211: Calling CRDA to update world regulatory domain
[   41.883462] cfg80211: Calling CRDA to update world regulatory domain
[   45.026808] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA

Poking at it, I've found out the following:
* the 'regulatory domain' specifies the max power and channels for wireless.
* by default, it's the 'world regulatory domain': you are limited to the
channels and power usage which are allowed everywhere in the world.
* US regulatory domain (what I'd use) allows a bit more power.
* to properly set this, there are two ways:
 - install wireless-regdb and crda (neither packaged!), then set things up
 so that /sbin/crda is automatically run from your hotplug helper with
 COUNTRY=.. in your environment when cfg80211 triggers the proper uevent.
 Contrary to the lack of documentation, you can just run it from mdev
 whenever $COUNTRY is set, $ACTION=change, and $MODALIAS=platform:regulatory.
I used this line in mdev.conf (above $MODALIAS=...), but it may be overly
generic:

$COUNTRY=.. root:root 0660 */sbin/crda

 - fetch db.txt from wireless-regdb, drop it in net/wireless/db.txt in
 the linux source tree, and build the kernel with
CONFIG_CFG80211_INTERNAL_REGDB=y
 then add the proper module options to cfg80211.

Note that crda has a lot of confusion in the build system;
refer to Gentoo's ebuild for fixes.

Thanks,


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Timo Teras
Details
Message ID
<20151127202452.246e46b3@vostro>
In-Reply-To
<20151126171801.32e233ba@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1448648692
DKIM signature
missing
Download raw message
On Thu, 26 Nov 2015 17:18:01 +0100
Natanael Copa <ncopa@alpinelinux.org> wrote:

> I am happy to announce that Alpine 3.3.0 first release candidate is
> released.

Awesome!

>[snip]
> - The initramfs has been refactored. We no longer depend on specifying
>   alpine_dev as boot option. Instead, the boot repositories and apkovl
>   should be automatically found using the new nlplug-findfs tool.

Semi related to this... see below
 
> I would appreciate help with testing:
> 
> - boot from usb, using setup-bootable and real hardware. Test that you
>   can store apkovl with 'lbu commit'. Do this with:
>   - alpine image
>   - vanilla image
>   - extended image
>   - xen image
> 
> - test upgrading from v3.2 to v3.3.
> 
> - test various different disk install combinations, eg lvm on raid,
> lvm without raid, raid without lvm.
> 
> Any other testing is also appreciated. Specially on different kind of
> hardware.

Boots and works on pcengines apu.

But the NIC died after setup-udev. setup-udev seems to disable
hwdrivers from startup. Adding it back made things tick.

The same is true on Raspberry Pi. udev will not load all required
modules, but having hwdrivers there will do it.

I suppose we can't delete hwdrivers.

/Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Natanael Copa
Details
Message ID
<20151128115755.79154339@ncopa-laptop>
In-Reply-To
<20151127202452.246e46b3@vostro> (view parent)
Sender timestamp
1448708275
DKIM signature
missing
Download raw message
On Fri, 27 Nov 2015 20:24:52 +0200
Timo Teras <timo.teras@iki.fi> wrote:

> On Thu, 26 Nov 2015 17:18:01 +0100
> Natanael Copa <ncopa@alpinelinux.org> wrote:
> 
> > I am happy to announce that Alpine 3.3.0 first release candidate is
> > released.  
> 
> Awesome!
> 
> >[snip]
> > - The initramfs has been refactored. We no longer depend on specifying
> >   alpine_dev as boot option. Instead, the boot repositories and apkovl
> >   should be automatically found using the new nlplug-findfs tool.  
> 
> Semi related to this... see below
>  
> > I would appreciate help with testing:
> > 
> > - boot from usb, using setup-bootable and real hardware. Test that you
> >   can store apkovl with 'lbu commit'. Do this with:
> >   - alpine image
> >   - vanilla image
> >   - extended image
> >   - xen image
> > 
> > - test upgrading from v3.2 to v3.3.
> > 
> > - test various different disk install combinations, eg lvm on raid,
> > lvm without raid, raid without lvm.
> > 
> > Any other testing is also appreciated. Specially on different kind of
> > hardware.  
> 
> Boots and works on pcengines apu.
> 
> But the NIC died after setup-udev. setup-udev seems to disable
> hwdrivers from startup. Adding it back made things tick.
> 
> The same is true on Raspberry Pi. udev will not load all required
> modules, but having hwdrivers there will do it.
> 
> I suppose we can't delete hwdrivers.

udev-trigger is supposed to replace hwdrivers, can you please verify
that it starts?

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Isaac Dunham
Details
Message ID
<20151129021821.GA2754@newbook>
In-Reply-To
<20151128030846.GA2529@newbook> (view parent)
Sender timestamp
1448763502
DKIM signature
missing
Download raw message
On Fri, Nov 27, 2015 at 07:08:46PM -0800, Isaac Dunham wrote:
> Well, I'd like to mention an issue I discovered on an Alpine Linux edge
> system I'm using as a wireless router.
> dmesg contains a lot of messages like these:
> [   10.453071] cfg80211: Calling CRDA to update world regulatory domain
> [   13.593462] cfg80211: Calling CRDA to update world regulatory domain
> [   16.736817] cfg80211: Calling CRDA to update world regulatory domain
> [   19.880084] cfg80211: Calling CRDA to update world regulatory domain
> [   23.023427] cfg80211: Calling CRDA to update world regulatory domain
> [   26.166723] cfg80211: Calling CRDA to update world regulatory domain
> [   29.310142] cfg80211: Calling CRDA to update world regulatory domain
> [   32.453458] cfg80211: Calling CRDA to update world regulatory domain
> [   35.596777] cfg80211: Calling CRDA to update world regulatory domain
> [   38.740183] cfg80211: Calling CRDA to update world regulatory domain
> [   41.883462] cfg80211: Calling CRDA to update world regulatory domain
> [   45.026808] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
> 
> Poking at it, I've found out the following:
> * the 'regulatory domain' specifies the max power and channels for wireless.
> * by default, it's the 'world regulatory domain': you are limited to the
> channels and power usage which are allowed everywhere in the world.
> * US regulatory domain (what I'd use) allows a bit more power.
> * to properly set this, there are two ways:
>  - install wireless-regdb and crda (neither packaged!), then set things up
>  so that /sbin/crda is automatically run from your hotplug helper with
>  COUNTRY=.. in your environment when cfg80211 triggers the proper uevent.
>  Contrary to the lack of documentation, you can just run it from mdev
>  whenever $COUNTRY is set, $ACTION=change, and $MODALIAS=platform:regulatory.
> I used this line in mdev.conf (above $MODALIAS=...), but it may be overly
> generic:
> 
> $COUNTRY=.. root:root 0660 */sbin/crda
> 
>  - fetch db.txt from wireless-regdb, drop it in net/wireless/db.txt in
>  the linux source tree, and build the kernel with
> CONFIG_CFG80211_INTERNAL_REGDB=y
>  then add the proper module options to cfg80211.
> 
> Note that crda has a lot of confusion in the build system;
> refer to Gentoo's ebuild for fixes.

This is the same as
http://bugs.alpinelinux.org/issues/3910

Looking through there, I see:
- py-m2crypto is already packaged; that APKBUILD can be ignored.
- wireless-regdb needs to makedepend on openssl (for signing), and
  on python (for building regulatory.bin); otherwise, it looks good.
- the crda package has several shortcomings:
  while integration for udev is provided, it's quite possible to use it
  with mdev (as noted above);
  a bunch of libraries are hard-coded;
  py-m2crypto is build-time only;
  depends=iw is pointless (iw is one of three tools-iw, wpa_supplicant,
  and hostapd-that can set the regulatory domain);
  building with USE_OPENSSL=1 is preferable, because you can add keys
  without recompiling (also, apk already depends on openssl...)
The copyleft-next license used for crda is explicitly compatible with
any FSF- or OSI-approved licenses, so OpenSSL is ok.

The problems aren't surprising, given that crda seems to have numerous
bits of breakage in the build scripts.

What worked for me (roughly), when building it for my own use, was:
- grab most of the crda-3.18-*.patch files from
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-wireless/crda/files/
- apply them
- install wireless-regdb
- build with USE_OPENSSL=1 PUBKEY_DIR=/usr/lib/crda/pubkeys/

HTH,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---