- Arch-releng - lists.archlinux.org

Re: [arch-releng] Wondering about the lvm/dmcrypt in the new AIF
by Dieter Plaetinck 16 Sep '09

16 Sep '09

On Mon, 14 Sep 2009 23:01:42 -0400 Peter Constantinidis <peter(a)constantinidis.ca> wrote: > Hi: > > I have a SSD.. I was wondering if the new installer contains options > to allow for partition alignment? Alignment is critical for SSDs.. > needs to be done 3 times.. > > 1st with fdisk. we use cfdisk > > 2nd for dmcrypt the option: --align-payload (with appropriate value) > > 3rd for LVM: pvcreate --dataalignment (with appropriate value) When creating filesystems, you can optionally specify additional options for the appropriate program (mkfs, pvcreate, cryptsetup, etc) > > If it doesn't, then the need to do it all manually still exists if one > has a SSD. I'm thinking a series of questions like "do you have a > ssd?" Y -> "do you know the block size?" Y-> "512k" and then it would > enter the appropriate values for all commands based on the hardware > block size of the SSD. > I don't want to hand-hold any more then we do now. Maybe we should put a note in the installation guide to use those options. > The other thing I am thinking is, if Arch is supposed to force people > to read and do everything manually, then wouldn't this installer > script begin to venture into pre-packaged territory? Don't know what you mean with "pre-packaged territory" but there are definitely some sentiments that our interactive installer is trying too hard and is not KISS. See http://mailman.archlinux.org/pipermail/arch-releng/2009-August/000721.html Note that you can also do automated installations. http://wiki.archlinux.org/index.php/Official_Arch_Linux_Install_Guide#Autom… > > All the best, > P. > > Disclaimer: I have never installed Arch but I am very interested in it. Dieter

2 1

[arch-releng] Assisting Chriss or adopting his CD as a separait project for Arch blind Users
by Keith Hinton 08 Sep '09

08 Sep '09

Hi, As one of Chris Branon's friends, and as one who has submitted valuable feedback, I'd like to see Chrisses CD get more support from the Arch team leads, etc. I also have another suggestion. Why couldn't core snapshots be automatically generated, and Chrisses CD/and the other official images could be all updated? As newer kernels came out, we could even get weekly/monthly netiso images automatically wich each core update, so that we'd never have to worry about waiting for 2 3 4 months or whatever. :) Just a suggestion, only. I don't expect that this could be automated. I'm just suggesting something, nothing more. But the fact that this CD of chirsses is unofficial isn't great. He does a wonderful job. I'd like to see him get more people who could build CDs, or whatever. That way he doesn't have to do all the work, and can focuss on maintaing Speakup/etc. Maybe an #Arch-Accessibility channel should be created with an associated mailing list. Your thoughts? I welcome anyone including Chris and anyone else who feels that Accessibility is important to comment on this. I will CC this to Arch-General as well so that the community in general can be made aware of this. Also, I wanted to ask why weekly builds couldn't be done? I'm talking about autobuilds, btw, taht use your isoscripts. I have seen other distros that offer accessibilty I.e. GRML, etc, wich have automatic CDs. Gentoo now has minimal stage3 tarballs, and automated snapshots, etc. Just curious why Arch hasn't done somethinglike this. Thanks so much all, happy arching, and have fun! :) P.s. My favorite feature of the LiveCD (I've only used Chrisses bc I can't use the others) is that you folks don't start anything we don't want. This might also be a nice way to have chrisses work ported to AMD64, not just I386. Maybe someone has an 64-bit box to test chrisses CDs on? :) Regards, --Keith

5 10

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