Subject: [alpine-devel] alpine 3.3.0 rc1 released

From: Natanael Copa <[email-masked]>
Date: Thu, 26 Nov 2015 17:18:01 +0100

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:  [email-masked]
Help:         [email-masked]
---

---

From: Timo Teras <[email-masked]>
Date: Fri, 27 Nov 2015 20:24:52 +0200

On Thu, 26 Nov 2015 17:18:01 +0100

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

Awesome!

>[snip]

Semi related to this... see below
 
> - test various different disk install combinations, eg lvm on raid,
> lvm without raid, raid without lvm.
> 

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

---

---

From: Natanael Copa <[email-masked]>
Date: Sat, 28 Nov 2015 11:57:55 +0100

On Fri, 27 Nov 2015 20:24:52 +0200

> I suppose we can't delete hwdrivers.

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

-nc

---

---

From: Isaac Dunham <[email-masked]>
Date: Fri, 27 Nov 2015 19:08:47 -0800

> 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

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,

---

---

From: Isaac Dunham <[email-masked]>
Date: Sat, 28 Nov 2015 18:18:22 -0800

> 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

---