Date: Thu, 13 Jan 2011 17:05:13 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: alpine-devel@lists.alpinelinux.org
Subject: [alpine-devel] the setup-alpine and setup-disk scripts
Message-ID: <20110113170513.3c34bd8b@ncopa-desktop.nor.wtbts.net>
Precedence: list
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I have been working a bit on the setup-disk script. There is more work
to do.

A minor backround info so you know where I have my influences from.

The redhat installer impressed me when i was new to linux. (around
redhat 5.0?) The thing that i really like was that i could switch
console during the install, do modprobe, and fix other things behind
the back of the installer, and suddenly I could have support for things
that was not officially supported in the installer.

I have also been impressed over the openbsd installer for the
simplicity, it can run from serial console, and with sane defaults you
can press enter, enter etc and you have your box up and running within
a minute.

So influenced by this setup-alpine was made.

The main goal with setup-alpine is to help user quickly get a useable
system up and running. The fewer questions asked, the better. No need
to wait for xorg to load from horribly slow cdrom. etc.

So, I'm thinking, append setup-apkrepos to setup-alpine so user gets a
http repo. User should only need to press enter to get a sane default.
We maybe dont even need to ask user but can just set it. I was thinking
maybe having the mirror list in a package? Or we download frrom net?
With a package we dont need have the network running when we configure
the http repo.

Then we maybe ask for setting up a ssh server? I think you almost
always wants an ssh server.

Then I think we should ask *how* Alpine should be run. There are 3
modes or "ways" to run Alpine Linux:

* tmpfs + lbu
* disk native (traditional disk install)
* disk hybrid (root is tmpfs, config on lbu but disk is used as
  spool/cache/logs. basicly, /var is mounted on disk)

If user pick tmpfs, then the next question will be what lbu media
should be, defaulting to something sane. (usbdisk if boot from cdrom or
the CF if booted from CF). If booting from cdrom we could offer user to
install it on usb, CF or harddisk. (on fat, but run from tmpfs + apkovl)

If "disk native" is chosed, then we run current setup-disk script and
offer to create standard partitions. I'm thinking of /boot (ext3) +
root on lvm and ext4. Maybe offer to set up the disk as software raid
with a single disk? (current setup-disk -r) that way use could just add
a disk later for soft raid. Or user could get the option for
raid1/raid5 if 2 or more disks are found.

The setup-disk script has an optional parameter of mountdir. If user
creates partitions with filesystems and mounts them, then you can do:
setup-disk /mnt and setup-disk will install the sysmtem there and will
figure out the disk layout and create a proper fstab and extlinux.conf.

The current alpine-conf git setup-disk script should be able to detect
raid devices and a separate /boot partition and I'm working on getting
lvm properly detected as well. I think it works but needs testing.

(Currently there are some "xen support" in there, which enables grub
instead of extlinux. I'd like to rip that out, or re-implement that as
a grub support instead of a xen support.)

If "disk hybrid" is chosen (or we call it "tmpfs+datadisk?) then we run
a setup-lbu script for setting up the lbu media and offer create a disk
for /var. or something... Running /var on disk a bit tricky because you
have the apk database on /var/lib/apk and we want the state from
packages during boot and not the one on disk. So im thinking that we
need hack /etc/init.d/localmount to move /var/lib/apk away to a temp
location if root is tmpfs, and mount an /var/lib/apk as tmpfs and move
the db back afterwards. That way its just to replace the boot media and
reboot to do upgrades.

Would also be nice if the setup scripts could be fed with a preseeed
config file where the questions already was answered, so you could to
unattended installs.

Other option is that we could only present 2 options for user: run
tmpfs or run native disk. If tmpfs is choosen then we could offer to
use of an optional datadisk for /var (or /vservers
or /var/lib/postgrersql or whatever....)

Thoughts?

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---