~alpine/devel

1

[alpine-devel] alpine 3.1.0 RC3 released

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

I have tagged 3.1.0 RC3 release.

I have done some scary changes. I hate to do it this late, but some of
them are needed to be able ship a RPI edition.

Xen now has support for running the domUs in tmux in addition to gnu
screen. The default is to run it without console.

The kernel, initramfs and modloop names has changed on the boot media:

  kernel:	$flavor -> vmlinuz-$flavor
		(eg. grsec -> vmlinuz-grsec)

  initramfs: 	$flavor.gz -> initramfs-$flavor
		(eg. grsec.gz -> initramfs-grsec)

  modloop:	modloop.$flavor.squashfs -> modloop-$flavor
		(eg. modloop.grsec.squashfs -> modloop-grsec)

This is more in harmony with the disk install.

Unfortunally, this will likely break things when you upgrade tmpfs
install boxes with setup-bootable -u. We can think if we want fix that
somehow or if we simply document it and let users manually either
recreate or manually edit their syslinux.cfg

Meanwhile, it would be nice if I could get some help with testing the
boot images.

I am interested in testing:

## cdrom boot (can be tested from virtual machine)
 - boot cdrom
 - run setup-alpine and select tmpfs
 - create apkovl on usb
 - reboot and check config is read on bootup

## USB boot
 - boot cdrom/iso image
 - run setup-bootable to create boot usb
 - boot usb
 - run setup-alpine and select tmpfs
 - create apkovl on usb
 - reboot and check config is read on bootup


## disk install
 - boot cdrom
 - run setup-alpine and select sys disk install
 - reboot and check that it boots up
 - do the same but with booting from usb


Would be nice test that with both standard iso and Xen iso. This is
because xen iso image has differently generate
syslinux.cfg/isolinux.cfg.

or.. wait with it til rc4 is out. We will likely need change more
things for RPI.

 -nc



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---
Details
Message ID
<54793799.3010107@it-offshore.co.uk>
In-Reply-To
<20141126170654.60a046a2@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1417230233
DKIM signature
missing
Download raw message
I've been testing the 3.1 disk installs in Virtualbox. There seems to be
a problem with Xorg in 3.1 / possibly GTK (which affects the display
managers & desktops).

In 3.0 I have xfce / fluxbox running without any problems without a
Display Manager / with LXDM & with SLIM.

I've tried upgrading 3.0 to 3.1 & a clean install of 3.1 & with both I'm
unable to start a desktop with or without a Display Manager.

I noticed removing LXDM from 3.1 caused gtk2-xfce-engine to be upgraded.

Xorg logs showed:

Assertion failed: key-> initialized
(../include/privates.h:dixGetPrivateAddr: 1ddr: 122
lxdm-greeter-gtk Fatal IO error 0 (No error information) on X server :0.
** Message: xserver stop, restart. return status 6

SLIM just flashes when trying to login - it's logs show "slim: waiting
for X server to begin accepting connections"
------------------------------------------------------------------------

I also tested installing onto encrypted LVM:

3.0.6 - can open LUKS partitions but segfaults using luksFormat in
cryptsetup.
3.1 - can open & format LUKS partitions with cryptsetup.

*mkinitfs -c $MNT/etc/mkinitfs/mkinitfs.conf -b $MNT*

3.0.6 - mkinitfs creates $MNT/boot/grsec.gz (& not initramfs-grsec) -
renaming it manually works
3.1 - mkinitfs creates $MNT/boot/initramfs-grsec

Extlinux - on both 3.0.6 & 3.1:

*extlinux --install $MNT/boot --update*

It correctly identifies the boot partition but does not update
$MNT/boot/extlinux.conf

modifying APPEND in extlinux.conf to

*APPEND root=/dev/mapper/vg0-root modules=sd-mod,usb-storage,,ext4 quiet
cryptroot=/dev/sda2 cryptdm=lvmcrypt*

Gave me a bootable encrypted system.

I also noticed running 3.0.6 & 3.1 with more than 1 CPU sometimes gave
"kernel panic - not syncing: Fatal exception in interrupt" (with it
seeming to happen more often in 3.1 compared to 3.0.6) - resetting the
VM a few times eventually gives a usable system.

2.7 did not seem to be affected by this. 3.0.6 / 3.1 with one CPU ran
without any panics.

I now have 2 VM's with an Alpine 3.0 xfce / fluxbox desktop on encrypted
LVM & an Alpine 3.1 on encrypted LVM without a working desktop.

Stuart.
Reply to thread Export thread (mbox)