August 2009 - Arch-releng - lists.archlinux.org

[arch-releng] [PATCH] Fix grub lines for various encryption setups
by Thomas Bächler 06 Mar '10

06 Mar '10

The first one used a deprecated syntax and failed whenever / was not called /dev/mapper/root The second one got a cosmetical cleanup to be more consistent with what was set during the installer The third one also failed whenever / was not called /dev/mapper/root --- src/core/libs/lib-ui-interactive.sh | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/src/core/libs/lib-ui-interactive.sh b/src/core/libs/lib-ui-interactive.sh index 586abc9..d9f8795 100644 --- a/src/core/libs/lib-ui-interactive.sh +++ b/src/core/libs/lib-ui-interactive.sh @@ -1089,20 +1089,21 @@ generate_grub_menulst() { then debug 'FS' 'Grub kernel line? Found / on dm_crypt on raw' raw_device=`echo "$ANSWER_DEVICES" | sed -n '2p' | cut -d ' ' -f1` - kernel="kernel $subdir/vmlinuz26 root=$raw_device ro" + crypt_device=`echo "$ANSWER_DEVICES" | sed -n '1p' | cut -d ' ' -f1` + kernel="kernel $subdir/vmlinuz26 root=$crypt_device cryptdevice=$raw_device:`basename $crypt_device` ro" elif echo "$ANSWER_DEVICES" | sed -n '1p' | grep -q 'lvm-lv$' && echo "$ANSWER_DEVICES" | sed -n '4p' | grep -q 'dm_crypt$' && echo "$ANSWER_DEVICES" | sed -n '5p' | grep -q 'raw$' then debug 'FS' 'Grub kernel line? Found / on lvm on dm_crypt on raw' lv_device=`echo "$ANSWER_DEVICES" | sed -n '1p' | cut -d ' ' -f1` - vg_device=`echo "$ANSWER_DEVICES" | sed -n '2p' | cut -d ' ' -f1` + crypt_device=`echo "$ANSWER_DEVICES" | sed -n '4p' | cut -d ' ' -f1` raw_device=`echo "$ANSWER_DEVICES" | sed -n '5p' | cut -d ' ' -f1` - kernel="kernel $subdir/vmlinuz26 root=$lv_device cryptdevice=$raw_device:`basename $vg_device` ro" + kernel="kernel $subdir/vmlinuz26 root=$lv_device cryptdevice=$raw_device:`basename $crypt_device` ro" elif echo "$ANSWER_DEVICES" | sed -n '1p' | grep -q 'dm_crypt$' && echo "$ANSWER_DEVICES" | sed -n '2p' | grep -q 'lvm-lv$' && echo "$ANSWER_DEVICES" | sed -n '5p' | grep -q 'raw$' then debug 'FS' 'Grub kernel line? Found / on dm_crypt on lvm on raw' crypt_device=`echo "$ANSWER_DEVICES" | sed -n '1p' | cut -d ' ' -f1` lv_device=`echo "$ANSWER_DEVICES" | sed -n '2p' | cut -d ' ' -f1` - kernel=" kernel $subdir/vmlinuz26 root=$crypt_device cryptdevice=$lv_device:root ro" + kernel=" kernel $subdir/vmlinuz26 root=$crypt_device cryptdevice=$lv_device:`basename $crypt_device` ro" elif echo "$ANSWER_DEVICES" | sed -n '1p' | grep -q 'raw$' then debug 'FS' 'Grub kernel line? Found / on raw' -- 1.6.4.1

2 1

Re: [arch-releng] kernel26-lts
by Dieter Plaetinck 01 Sep '09

01 Sep '09

On Mon, 31 Aug 2009 22:39:49 +0200 Andreas Radke <a.radke(a)arcor.de> wrote: > Morning guys. > > There's a discussion on the public dev list about my kernel26-lts. I'd > like to see it on the next iso snapshot release. > > We still have to decide to what repo it should go. It's right now in > testing and moving to core and extra is both an option. > > Now to you guys: please make a statement how you can imagine a kernel > choice for the iso (include it to the disc, download it from extra....) > and if the choice of repo would affect the iso creation and what your > opinion is. > > Please post to the list. It's up again and running. > > Thx. > > -Andy Sure. As long as it is maintained well and causes no problems/confusion with all the modules we ship and stuff (see discussion arch-dev-public), I'ld love to see this in core. I think it would just "belong" there. Any estimate on the size? i see that normal kernel packages are +- 33 MB. I heard that if we want to do multi-arch iso's (we do) we're pretty close to the limit of our current approach. But then again, we should be able to play with compression algo's and parameters for the squashfs. If the package is not in core, the user will always need to download it if he wants it which seems a drawback to me. On media that come with packages, we only put core. (because hey, core is the only thing you need to get a system up and running) The way i see this is not treating it specially: the user has a list of base packages which he can customize. if he wants the lts kernel he has to disable the normal one and enable the lts one. maybe, just maybe we make an extra dialog "which kernel do you want", but these are just UI details. Dieter

3 2

[arch-releng] Multi-arch ISOs [was: kernel26-lts]
by Aaron Griffin 31 Aug '09

31 Aug '09

On Mon, Aug 31, 2009 at 3:59 PM, Dieter Plaetinck<dieter(a)plaetinck.be> wrote: > Any estimate on the size? i see that normal kernel packages are +- 33 MB. > I heard that if we want to do multi-arch iso's (we do) we're pretty close to the > limit of our current approach. With the new --arch param to pacman (in git, I think), we can install EITHER system from an i686 ISO. I think this almost makes the way of putting BOTH systems on a multi-arch ISO moot. I mean, we probably don't even need to ship an x86_64 ISO as one ISO could install both systems. It'd make a lot of things easier to simply ship the lowest common denominator, not to mention size

2 1

[arch-releng] [PATCH] Remove a leading whitespace in the generated menu.lst
by Thomas Bächler 29 Aug '09

29 Aug '09

--- src/core/libs/lib-ui-interactive.sh | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/core/libs/lib-ui-interactive.sh b/src/core/libs/lib-ui-interactive.sh index d9f8795..9c8dc3e 100644 --- a/src/core/libs/lib-ui-interactive.sh +++ b/src/core/libs/lib-ui-interactive.sh @@ -1103,7 +1103,7 @@ generate_grub_menulst() { debug 'FS' 'Grub kernel line? Found / on dm_crypt on lvm on raw' crypt_device=`echo "$ANSWER_DEVICES" | sed -n '1p' | cut -d ' ' -f1` lv_device=`echo "$ANSWER_DEVICES" | sed -n '2p' | cut -d ' ' -f1` - kernel=" kernel $subdir/vmlinuz26 root=$crypt_device cryptdevice=$lv_device:`basename $crypt_device` ro" + kernel="kernel $subdir/vmlinuz26 root=$crypt_device cryptdevice=$lv_device:`basename $crypt_device` ro" elif echo "$ANSWER_DEVICES" | sed -n '1p' | grep -q 'raw$' then debug 'FS' 'Grub kernel line? Found / on raw' -- 1.6.4.1

1 0

[arch-releng] [PATCH] Create directory in overlay when building ISO.
by Christopher Brannon 25 Aug '09

25 Aug '09

Git doesn't track empty directories, so there is no configs/install-iso/overlay/pacman.d/ directory when one clones the archiso project. This causes "make <IMAGENAME>" to fail when wget tries to fetch the mirrorlist. The fix is to make the directory just before calling wget. --- configs/install-iso/Makefile | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/configs/install-iso/Makefile b/configs/install-iso/Makefile index cdfd8a1..7e4ffe3 100644 --- a/configs/install-iso/Makefile +++ b/configs/install-iso/Makefile @@ -32,6 +32,9 @@ net-iso: overlay $(BOOTLOADER) overlay: base-iso cp -r overlay $(WORKDIR)/ + if [ ! -d $(WORKDIR)/overlay/etc/pacman.d ]; then \ + mkdir -m755 $(WORKDIR)/overlay/etc/pacman.d; \ + fi wget -O $(WORKDIR)/overlay/etc/pacman.d/mirrorlist http://www.archlinux.org/mirrorlist/$(ARCH)/all/ sed -i "s/#Server/Server/g" "$(WORKDIR)/overlay/etc/pacman.d/mirrorlist" -- 1.6.4.1

3 2

[arch-releng] [archiso] My archiso repo at github
by Gerhard Brauer 25 Aug '09

25 Aug '09

Hi, i setup a archiso repo at github http://github.com/gerbra/archiso/tree where i will push my patches. I hope i get better familiar with git ;-) As Aaron and Dieter told me it's easier to pull commits from a repo into the main git than with git-format-patch email attachments. [Patch] Added vfat support to mount /dev/archiso http://github.com/gerbra/archiso/commit/fd93e7c9bd614a026f1d661f359012a4c1e… With this I was able to use our ISOs and unetbootin tool to bring the image onto a already vfat formatted USB stick and boot from this. This is way many user use to not have to blow their stick with our recommend dd method. Using unetbootin method the user also have to change archisolabel in unetbootin-bootmanager to the label of their USB stick. Restriction: The USB stick label should not have whitespaces in the name. I tried it with: archisolabel=My\x20\Stick but with no success. Instead a stick labeled with arch200908 works fine. We should add these hints either in documentation or on a similar wiki page for users which try to use the images other than the recommend way. Some draft notes: Recommend: ISO -> burn on a high quality medium and with a slower speed (max 8x) cause we use highly compressed data on the ISOs USB/IMG -> only full supported method is using the: dd if=arch.img of=/dev/sdX bs=1M method, which erases ALL data on the stick (cause the partition table is overwritten). UNetbootin -> your usb stick must have a label without white-spaces in the label-name. This label you must supply as the archisolabel parameter in bootloader. Gerhard

3 2

[arch-releng] [PATCH] Allow using a USB device as read-write branch instead of tmpfs
by Thomas Bächler 24 Aug '09

24 Aug '09

--- archiso/hooks/archiso | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/archiso/hooks/archiso b/archiso/hooks/archiso index ab55be6..5cbfb44 100644 --- a/archiso/hooks/archiso +++ b/archiso/hooks/archiso @@ -84,7 +84,13 @@ run_hook () /bin/modprobe -q aufs >/dev/null 2>&1 msg ":: Mounting root (aufs) filesystem" - /bin/mount -t aufs -o dirs=/tmpfs=rw none /real_root + if [ "${livesystem}" = "rw" ]; then + /bin/mount -o remount,rw /bootmnt + mkdir -p /bootmnt/livesystem + /bin/mount -t aufs -o dirs=/bootmnt/livesystem=rw none /real_root + else + /bin/mount -t aufs -o dirs=/tmpfs=rw none /real_root + fi export LOOP_NUM="0" msg ":: Mounting images" -- 1.6.4.1

2 3

[arch-releng] text-file automated install
by David Campbell 23 Aug '09

23 Aug '09

Hi everyone, with the new addition of AIF I decided to start listening to this mailing list and am finding some of the discussion very interesting even if some of the technical bits are a little over my head. The text file installation idea sounds particularly interesting and I also like the idea of having bash helper scripts or even some kind of ncurses interface to help generate the text files. This would make installation much more smooth for a lot of users and make making custom installs very easy(being able to hit enter and come back when the job is done is awesome). If things were done well, hundreds of linux distros might even dry up overnight as people realized rather than making a million distros more or less from scratch or hacking away at other distros, everyone can work on a common framework for easily creating specilized installs with specific application profiles. I think It may be a good idea to throw up some of the AIF documentation on the arch wiki and provide details useful to those less experienced with coding. If people come to realize how silly much of the distro ecology is right now, efforts may be shifted away from spending lots of effort to create slight variations on others' work and toward things such as upstream development and improvement of framworks like AIF. Instead of a web site existing which someone goes to to find out what the right distro is for him ( e.g.http://www.zegeniestudios.net/ldc/ ), he would run a script (or web interface thing) or ncurses app on an install disk and it would create the right distro for him. -David Campbell

2 1

[arch-releng] Draft - Beyond AIF, long live AIF...
by Gerhard Brauer 19 Aug '09

19 Aug '09

Hi, First excuse, I'm not a native and good English writer and speaker, and writing such long texts is something i normally do not day-by-day. Could we discuss about a suggestion: What if we drop the interactive procedure on installation process and offers only the automatic way, controlled by a plain text file? Huh? What he is talking about? =============================== AIF could use a control file in plain text to do the installation; also complex installations (ex: LVM and dmcrypt). For examples take a look at [1] and [2]. The install process then is running automatically without need of user invention. Installer paradigms ==================== Today installers (either if graphically or text based) are mostly interactive tools. They ask the user for information and the user is giving data to the installer. Also the user must make decisions in some steps, say Yes or No. Also in current AIF in interactive mode. Usual a installation is a top-down and sequent work-flow. But this don't prevent that user do "silly" things. So installers (also AIF) must do many things "behind the view" to intercept mistakes. Or need user invention/decision based on information from a procedure before current step... As a example the way grub install is handled by old arch-installer (AIF does this a little other): We have to ask about root/boot devices to generate a matching menu.lst file. This file is presented to the user again to have a look or change something. From the point that the user may have changed something some/most informations must be asked again (or be parsed from the changed menu.lst file). Main problem IMHO is: a today installer doesn't know at the beginning with what information it will conclude at the end. So each needed information for a step has to be asked/determined before this step. K.I.S.S me... ================= A today installer is hand-holding the user. It must be. From the user side the installer is the first tool he normally see from a distribution. How good he/she "feels" during this process, this often make a pro or contra later. The user - as a !Master! - means: I could work well with this installer, it does all what i want. First mistake! It's always the user that makes what the installer wants. That's the nature of this special piece oft software: It has a very restricted environment and its only goal is: install a working system. From a installer view the user is the obstructive part - only needed to give some information. To get those the installer feeds the user: give him nice varicoloured output, some play music or nice balls are wandering from the left to the right in progress bars... Meanwhile the installer must take care that the user make only one step left or one step right - but not two steps... In the "older days" installers - from users side - tend to be complex software; these days the trend is to keep the user off from the technical base behind the process of setup a base system. "5 clicks to get xyz ready to run..", "Full featured linux in 15 minutes - only 3 questions"... and so on. The result - we know this - are the full-bloated systems where in fact the distributions determine most of the users system. ... we are frogs! ================= During last images build and bugfixing i thought a lot about this. I know that our "old Devs" always prefer quickinst from old arch-installer package. Now coming familar with AIF, myself look most times and primary on the interactive part; but doing some work with automatic install scripts IMHO there is more potential than with quickinst. So my question: Am i totally wrong with my thoughts and - if not - have we the pluck to confront the user with... an text editor? Take a breath before hit Reply key... ;-) First: The above mentioned aif scripts are not the answer - syntax, presentation and documentation are more the "proof-concept" to look for answers. Pros & Contras ================== 1. Making the settings for installation in a control file gives not that pressure to the user what a User-Interface(UI) based installer has. Working with this file ("editing") does not any bad things. Look for ex. on the grub part currently in interactive AIF: The user is confronted in this step with questions in a very isolated manner. This step is very interdependent from the previous blockdevice setup - but these information's were entered before 10 minutes and out-of-users-sight in this step. In a editor all information is easy browseable and corrections could make at any point. IMHO a pro. 2. Install information could be saved at any time to external place by the user - or come complete from external medium. Currently our install procedure has to be restarted every time if the user got "stucked" in one step, or canceled the process, or when the installer has a bug. Most (and so in fact all) informations have to be re-entered... Think further about the capabilities: We (and the community) could offer templates for nearly each installation setup - without the need to bring this in a UI... If one has the idea to write a web-based interface to generate such installation control file - why not? IMHO a pro. 3. On the road to 2009.08 (and AIF) many of reported problems were UI related problems. Such things like "Cursor not automatically placed in Menu xyz". But also during the grub refactoring we have seen: to get feature or procedure X to work we must have here a new dialog, and there we have to change a other dialog... and so on. I guess on most interactive programs the UI-based part is the biggest part. And often the part with the most possible bugs. Current interactive AIF hast 2 UIs: the ncurses dialog based and a pure read/print based one. Ok, we will never ever have a graphical installer, but we hear often: why do you use such a "antique" UI? And in fact: Most today machines/environments could handle a graphically installer and also modern frameworks give even better widgets to interact with the user... But: Another UI gives potential more bugs and needs more manpower which could be better used to make the "base" more stable. If we use the control file based install we get rid off from such discussions of the "neatest" installer... And IMHO the step away from "how the others do it" could make us very modern... IMHO a pro. 4. Yes, i have a contra... Control files/variables tend to be not very self-explanation. For example take the current syntax for blockdevice setup: -------------- GRUB_DEVICE=/dev/sda PARTITIONS='/dev/sda 100:ext2:+ 512:swap *:ext4' BLOCKDATA='/dev/sda1 raw no_label ext2;yes;/boot;target;no_opts;no_label;no_params /dev/sda2 raw no_label swap;yes;no_mountpoint;target;no_opts;no_label;no_params /dev/sda3 raw no_label ext4;yes;/;target;no_opts;no_label;no_params' ------------- Here we have to invest a lot of work to bring such a syntax to the user in a better way. But on such complex steps i could imagine on "helper applications". Maybe a similar dialog-based we currently use in interactive AIF. But instead to "feed" a installer with this informations this helper produces for ex. the BLOCKDATA string for above control file. The user then import this generated piece into the editor. Similar helper could be one for timezone strings; all information a user normally not know by rote and so must be "picked" from a list. IMHO: if we make this good, the contra could went to a pro - cause at the end the user has still a (correctly) control file to start installation. Read until here....? ======================= Wow. Yes, I'm really thinking (and like to discuss) about a work-flow: a) User boots the image, login. b) Select/start a text editor with a base control file or select one of the other pre-defined control files. c) Edit his settings in this control file d) Uses the other tty's for getting infos, start helpers. Helper output he could load into the current control file editor. e) After "editing the setup" he could save it extern and come back later or f) start the installation. No interaction is needed after this (Ok, before fdisk'ing and formatting we should make a "break and review"). g) Base system is installed - user is happy... Cookies and taccos... What do you think? Of course, this is nothing for the next images... It's a massive U-turn against the main stream, but at the end IMHO the benefits could be great - KISS like... These are only my personal thoughts as a releng member, no position of "official politic". And now: Fire at will! ;-) Regards Gerhard [1] http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1… [2] http://github.com/Dieterbe/aif/blob/2ef92eaa5f1106d8f1b379a8a94a477a0877bb1…

2 3

[arch-releng] releases, snapshots and semantics
by Dieter Plaetinck 18 Aug '09

18 Aug '09

Problem: - Some users (newbies) think Arch Linux has separate releases. they think the images are more important for upgrading/installing then they actually are (they often think they need them, while they can just pacman -Syu instead) - the notice @ http://www.archlinux.org/download/ helps a bit (I think)... - ... but the biggest problem are news sites who are not really into Arch, see our news and call it a "new Arch Linux release with new features foo and bar" and "Arch Linux 2009.08" It has been proposed to call the images "snapshots", but the 2009.08 announcement has shown this is of no use (http://www.archlinux.org/news/459/): All news sites speak about the new "arch linux release" even though we called them snapshots. Not to mention I think the word snapshot is not accurate in this case anyway (we discussed this before - iirc around 2009.02 - but here is my opinion again): - Arch Linux (the distribution) may be "rolling" and does not have releases, but rather snapshots. - The *images* that arch-releng produces are imho definitely releases. The images have milestones, they are iteratively developed, tested etc. All images are especially crafted. They are not just snapshots. The only thing that is a snapshot, is the /src/core/pkg directory on core images. I think our images are "projects" just like Xorg or pacman, so they have releases. The actual distribution, which is made from a "mass of packages", and which is installed by using the "images project" has no releases. So there is a subtle duplicitly going on here. I've been thinking of simple, but clear ways to phrase this and I think it's best to make the images a separate project with a special name. for example we could call this project "ALIMG" or something (Arch Linux images) and then talk (news items) about new ALIMG releases. ALIMG 2009.08 etc. I think that this would be best to separate Arch Linux from the images which you can use to install it, as it would be a better "model of the reality" various places such as news messages on our site, on external news sites, in our installation guides etc can then be more clear. Dieter

8 13