Subject: [alpine-devel] i486 vserver kernel?

From: Jon Clausen <[email-masked]>
Date: Mon, 4 Oct 2010 13:02:35 +0200

Hi

I have these old, underpowered, resource starved singleboard machines.
(VIA Samuel 2 CPU, 512 MB RAM)

I'd like to extend their life a little longer, and one way of doing that
would be using them for 'pet projects'. 'vserver' seems a likely way of
getting the most out of the hardware, except that the CPU doesn't support
instructions that the i686 kernel needs (CMOV)

I managed to get a proof of concept system running by recompiling a vserver
kernel configured for i486, but...

1: An 'official' i486 build would be much nicer (and easier for me ;)

2: If for some reason 1: isn't feasible, what are the steps to set up a
(semi-)automated buildsystem?
I guess it would entail something on the order of
* getting notified when there's a new kernel version
* syncronizing the sources
* generating a new 'i486 .config'
* compile/package

Hints much appreciated :)
/jon
-- 
YMMV

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Natanael Copa <[email-masked]>
Date: Mon, 04 Oct 2010 15:10:43 +0200

> 1: An 'official' i486 build would be much nicer (and easier for me ;)

hum. I think there was a reason switch to i586, but i dont remember what
it was. I wonder if it was related to better virtualization guest
support or something.

I think it would be nice to support this kind of old hardware so I'm
switching to i486 for linux-vserver til someone comes with some good
reasons to switch back to i586.

Please try the linux-vserver kernel in edge.

> Hints much appreciated :)

This should not be too hard for you to set up either.

>From the top of my head, something like:

Do a git clone

cd main/linux-vserver

abuild unpack prepare installdeps
cd src/build && make menuconfig
# select i486 processor.
# save and exit kernel config

copy .config to ../../kernelconfig.x86

cd ../../
abuild checksum

now you have your modified kernel config. You can now git commit this
change.

To keep it up-to-date, simply do git pull --rebase and rebuild when the
upstram changes.

I dont really have good ideas when it comes to notifications. I suppose
you could do the git pull --rebase from a cronjob and check if the
linux-vserver/APKBUILD has changed or similar.

You can also copy the the linux-vserver to a separate package,
linux-vserver-i486 or similar. I have a script that bump package
versions so update to new version is just a question of 'abump
package-<newversion>'

-nc

---

---

From: Jon Clausen <[email-masked]>
Date: Wed, 6 Oct 2010 17:01:36 +0200

> reasons to switch back to i586.

Actually I was thinking more in terms of kernel 'flavours' or
'architechtures'. People with newer HW might be better off (as in get better
performance) with i586 or i686 kernels.

Is it feasible to introduce multiple builds? Sort of:

linux-vserver-i486-2.6.32.24-r0.apk
linux-vserver-i586-2.6.32.24-r0.apk

> Please try the linux-vserver kernel in edge.

Well, "it boots" is about all I can say ATM - had to shuffle some stuff
around, so I haven't gotten to actually running any guests yet.

But thanks so far ;)

> From the top of my head, something like:

<snip>

For the time being, I'll just 'coast along' with the i486 kernel from
'edge'... but thanks for 'outline'.

regards,
jon
-- 
YMMV

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 07 Oct 2010 10:25:53 +0200

> > On Mon, 2010-10-04 at 13:02 +0200, Jon Clausen wrote: 
...
> performance) with i586 or i686 kernels.

we use the term "flavor" for the patchsets. linux-grsec, linux-vserver.

> linux-vserver-i586-2.6.32.24-r0.apk

This would be the best, yes. Unfortunally it would require some extra
maintenence work. How about 3rd party modules? dahdli-linux-vserver for
instance. I also does a quick test to verify that the kernel actually
boot in a virtual machine before I push the change. Should I test both
i486 and i586? The biggest issue is that those things are not a one-time
job and currently I'm pretty much at the limit of what I can maintain.

I am also planning to do alpine x86_64 soonish and I think most high-end
vserver hosts will be using that, so I'm not that keen on start with
linux-vserver-i486, linux-vserver-i586, linux-vserver-i686 for the time
beeing.

-nc

---

---

From: Jon Clausen <[email-masked]>
Date: Thu, 7 Oct 2010 11:02:58 +0200

> we use the term "flavor" for the patchsets. linux-grsec, linux-vserver.

ok

> job and currently I'm pretty much at the limit of what I can maintain.

Yeah, I kinda figured it'd be something like that, so until someone comes
along with reasons to switch back to i586/i686 I'm happy :)

If/when someone does, then I'm just going to have to look into setting up a
build system.

> vserver hosts will be using that,

This is good news. I'm sure you're right about high-end, but I think even
comparatively low-end as well.

> so I'm not that keen on start with

Understandable.

regards,
jon
-- 
YMMV

---

---

From: Timo Teräs <[email-masked]>
Date: Thu, 07 Oct 2010 12:48:50 +0300

> If/when someone does, then I'm just going to have to look into setting up a

i486 optimization would be good for uniprocessor systems. Basically UP
kernel for i486, and SMP kernel for i586+.

But yes, it's more work. I wonder if we could automate the "does the
kernel boot test". I think it should be doable with qemu + a script to
monitor console output (e.g to check that we get getty prompt).

- Timo

---

---

From: Natanael Copa <[email-masked]>
Date: Thu, 07 Oct 2010 16:54:16 +0200

On Thu, 2010-10-07 at 12:48 +0300, Timo Teräs wrote:
> But yes, it's more work. 

And delays kernel fixes as build time is numarch * time to compile
single kernel.

> I wonder if we could automate the "does the

It is infact half automated already. I run a script that builds iso with
specified kernel (vserver or grsec), installs qemu and boots it up with
ncurses interface. Then i just log in and do 'poweroff'.

If the boot iso had serial boot, then I could use something like
'expect' ur lua-pty to wait for login: and send 'root<enter>' and
'poweroff' and if success, then push the commit...

hum...

Does anyone have any objections to enable serial login by default? The
only reason I havent it enabled by default is that you never know what
devices are connected to computers serial interface (UPS? sms gateway?)
and once its enabled, it cannot be turned off from default iso.

I suppose i can make serial boot optional in alpine-iso makefile...

-nc

---

---

From: Jon Clausen <[email-masked]>
Date: Sun, 10 Oct 2010 10:33:17 +0200

> ncurses interface. Then i just log in and do 'poweroff'.

Is it possible to add networking/sshd to this test-setup?

If it is, then key-based auth might provide a way to automate the post build
test process without 'expect' (?)

> Does anyone have any objections to enable serial login by default?

Personally, no - but this;

> The

may be a pretty good reason not to enable serial by default.

regards,
jon
-- 
YMMV

---