- Arch-releng - lists.archlinux.org

Re: [arch-releng] 2010.04.05 snapshots ready for testing
by Dieter Plaetinck 12 Apr '10

12 Apr '10

On Sat, 10 Apr 2010 15:13:18 -0500 Chris Brannon <cmbrannon79(a)gmail.com> wrote: > > if you can reproduce it consistently, file a bug report. however i > > cannot make guarantees as to when it will be fixed, due to time > > constraints. I can assist you if you want to debug this issue > > yourself, though. > > I added some debugging statements to the AIF code on the CD image, and > what I found is even more baffling. When > process_filesystem /dev/mapper/cryptoroot ext4 > is called, the test [ ! -b $1 ] returns 0 at the top of the function. okay. so you are sure now that process_filesystem is called with args '/dev/mapper/cryptoroot' and 'ext4'. can you maybe do an ls -alh, stat, and file on $1 as the first thing in process_filesystem? > However, the test > [ -b /dev/mapper/$fs_label ] > returns 0 right after cryptsetup format and cryptsetup open have been > called. that's really odd. so basically you are saying when the dm_crypt is created -b on it returns true, but a bit later -b on the same thing does not. please doublecheck that $fs_label is cryptoroot here. do a ls -alh, stat and file here also. so we can compare. > The bizarre part is that everything works when I use the -d option for > debugging output. > I'm beginning to wonder if qemu isn't the source of the trouble, but > I don't have a spare machine for testing. I think it probably has something to do with open fd's such as stdin/stderr etc. notice that we do some magic in process_filesystem like cryptsetup $fs_params $opts luksFormat -q $part >$LOG 2>&1 < /dev/tty ; ret=$? #hack to give cryptsetup the approriate stdin. keep in mind we're in a loop (see process_filesystems where something else is on stdin) infofy "Please enter your passphrase to unlock the device" cryptsetup luksOpen $part $fs_label >$LOG 2>&1 < /dev/tty; ret=$? || ( show_warning 'cryptsetup' "Error luksOpening $part on /dev/mapper/$fs_label" ) ;; maybe the debugging somehow affects this. Dieter

3 13

[arch-releng] 2010.04.05 snapshots ready for testing
by Dieter Plaetinck 12 Apr '10

12 Apr '10

Hello all, please find new testing images @ http://build.archlinux.org/isos/ This time, there are no big known issues! [1] I just did an installation myself and it worked, but of course images require a lot more testing, especially for the exotic things (lvm, encryption, automatic installs, all new features such as pxe booting, etc). So please give these images a spin. They can't be much worse then the last official release ;-) If you tested the image and it worked fine, be sure to let us know and briefly describe which special thingies (if any) worked fine for you. http://build.archlinux.org/isos/Changelog http://build.archlinux.org/isos/README The more feedback I get from the community, the faster a new official release will happen. Dieter [1] (I did not figure out the issue i had earlier - http://mailman.archlinux.org/pipermail/arch-releng/2010-April/000941.html, but I re-setup the build chroots and now it's magically fixed.

8 19

Re: [arch-releng] 2010.04.05 snapshots ready for testing
by Dieter Plaetinck 10 Apr '10

10 Apr '10

On Sat, 10 Apr 2010 13:27:17 -0500 Chris Brannon <cmbrannon79(a)gmail.com> wrote: > > well, crap. if the problem occurs only when not doing logging, then > > this is going to be a bitch to investigate. (did you try just just > > '-l' or just '-d' instead of '-l -d' ?) > > It also fails with -l (no -d), though the log file isn't too helpful. > It always succeeds with -d, regardless of whether -l is present. you could run aif -p interactive -l and change relevant debug calls (eg those in process_filesystem) to log calls. > I wonder whether die_error is actually dying when debugging is > enabled? it definitely should. why do you doubt this? (you see that aif exists, after spawning the error, right?). you see. try -l then > > AFAIK, here is the line in the AIF code that is failing: > [ "$2" != lvm-lv ] && [ -z "$1" -o ! -b "$1" ] && die_error > "process_filesystem needs a partition as \$1" # Don't do this for > lv's. It's a hack to workaround non-existence of VG device files. > It's line 692 of src/core/libs/lib-blockdevices-filesystems.sh in my > (up-to-date) clone. > > The -b $1 caught my attention. Is it possible that this is failing? > My /dev/mapper/cryptoroot is a symlink to another device > (/dev/dm-0, IIRC), and that is a block device. the fact that it's a symlink, is by itself not a problem: example: $ ls -alh /dev/mapper/cryptpool-home lrwxrwxrwx 1 root root 7 Apr 10 08:28 /dev/mapper/cryptpool-home -> ../dm-3 $ [ -b /dev/mapper/cryptpool-home ] $ echo $? 0 we first of all must be sure that $1 is what we expect. so put a log call as the very fist thing in process_filesystem that logs "$@" > I wonder if that block device somehow didn't become available > soon enough for process_filesystems /dev/mapper/cryptoroot ext4 to use > it? I'm running this in a VM after all. it should. process_filesystems is designed to do them in correct order (this is why it's very useful to change the debug calls to log calls, then you can follow which devices it does) each process_filesystem call is definitely synchronous btw. ie. the function runs as long as the mkfs/cryptsetup/.. is running. once cryptsetup > > PS. I'm mainly testing this because you said that you'd like for > folks to test the exotic features. thank you. this is definitely needed.

1 0

[arch-releng] 2010.04.04, i686 images have x86_64 kernel
by Dieter Plaetinck 05 Apr '10

05 Apr '10

So, i built new images. http://build.archlinux.org/isos/ they "should" work. built from the latest archiso, using the latest configs however when i try to boot the i686 image, just after the isolinux menu, i get this: "this kernel requires an x86_64 cpu, but only detected an i686 cpu. Unable to boot - please use a kernel appropriate for your cpu." any of the archiso hackers know how this can happen? the makefile does just a `uname -m` and obviously i was in the i686 chroot (and it named the isos i686.iso, so the detection should work) and: cat root-image/etc/mkinitcpio.d/kernel26.kver # DO NOT EDIT THIS FILE ALL_kver='2.6.32-ARCH' Dieter

4 4

Re: [arch-releng] [arch-general] Arch Linux Release Question
by Dieter Plaetinck 04 Apr '10

04 Apr '10

"release team" currently that means me. yes, i'm working on new images. see: http://build.archlinux.org/isos/ http://mailman.archlinux.org/pipermail/arch-releng/2010-March/thread.html progress is rather slow, but there is not so much work anymore, so they'll come.. Dieter

2 1

[arch-releng] Arch Linux Release Question
by Keith Hinton 03 Apr '10

03 Apr '10

Hi, First of all, if anyone is curious as to why I have posted to the Arch-General mailing list, I'm mainly doing this, in case any of the Arch Release team is actually hanging out on this list. I was curious, seeing as the last Arch Linux release was in August of last year, if there will be one for the lovely new year of 2010? If someone could get back to me on that question I would for sure appreciate it. I hope that all is going well for Arch Linux development! Talk to you folks later. I haven't been as active on this list due to personal commitments but do watch for any interesting activity from time-to-time. Thanks. Sincere Regards, --Keith

1 0

[arch-releng] Make archiso PXE & NBD friendly (server and client mode)
by Gerardo Exequiel Pozzi 23 Mar '10

23 Mar '10

Hello I recently done some changes for archiso, to make it booteable via PXE (Preboot eXecution Environment) and using NBD (Network Block Device). Also a minimal server script can be launched to act as server ;) If booted from network, there is a [nbd] hook, (based on [net]), that configures an IP address, then setup a /dev/nbd0 (via nbd-client). (and /dev/archiso will point to this device), all the rest is done by current archiso hook :) (copytoram option can be used) If booted normally, [nbd] hook does nothing. Inside the /root, there is a simple script that launches dnsmasq enabling tftp and dhcp server, finally start the nbd-server that serve the iso file via network. Tested on real machine, kvm and Virtualbox, works very nice. Relevant commit (adding nbd hook to pxe_nbd branch ) [#1] and sample usage (diff based on my avr-toolchain branch) [#2] All step to make iso are here [#3] NOTE: nbd [#4] package from AUR is needed, so additional steps should be done than normal process. :( Just for fun, all comments welcomed. Good luck! [#1] http://github.com/djgera/archiso/commit/6023d6f78e3e68c2ad9ae595879a53b6771… [#2] http://github.com/djgera/archiso/commit/ed15360b828671fb6732f8f52ff00de09b2… [#3] http://github.com/djgera/archiso/blob/037d265360c76275be0745d77e2f008137550… [#4] http://aur.archlinux.org/packages.php?ID=9691 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

3 6

Re: [arch-releng] isohybrid -offset 1, can't mount partitions inside live env
by Gerardo Exequiel Pozzi 23 Mar '10

23 Mar '10

On 03/15/2010 10:25 PM, Sven-Hendrik Haase wrote: > On 15.03.2010 16:41, Gerardo Exequiel Pozzi wrote: > >> Hello, >> >> There is another issue with offset 1. This does not happen with offset 0. >> >> My scenario: >> * 2G USB key >> * isohybrid -offset 1 >> * another primary partition created (also is the same issue happens with a logical part instead) >> >> >> # mount /dev/sdc2 /home/hola >> mount: /dev/sdc2 already mounted or /home/hola busy >> >> ** strace shows: >> mount("/dev/sdc2", "/home/hola/", "ext2", MS_MGC_VAL, NULL) = -1 EBUSY (Device or resource busy) >> >> >> # mkfs.ext2 /dev/sdc2 >> mke2fs 1.41.10 (10-Feb-2009) >> /dev/sdc2 is apparently in use by the system; will not make a filesystem here! >> >> ** strace shows: >> open("/dev/sdc2", O_RDONLY|O_EXCL) = -1 EBUSY (Device or resource busy) >> >> >> My conclusion is, isohybrid mode is a great hack!. But of course, carries some inevitable issues. >> >> The big dichotomy: >> * offset 1: >> + allows some partitions programs works without issues. (at least I know about parted issue) >> - Can not use extra partitions created in the medium. >> - Can not use /dev/disk/by-label/ skip archiso_early. >> >> * offset 0: >> - Cause issues with some partitions programs. >> + Can use extra partitions. >> + Can use "by-label" (under condition that all partitions must have a LABEL) >> >> >> Good luck! >> >> >> > Ok, so let's use the upstream recommended offset 0 for now as well. By > the way, I was actually able to use extra partitions and boot from them > with offset 1 but my results do not appear to be consistent. > Okey. Note that archboot use the default mode. > They are currently deciding on a more proper way for isohybrid on the > syslinux mailing list to work while being integrated in the iso > generation process itself so as not to be a hack anymore. Until then, > we'll have to think about something ourselves. > Good. > So use offset 0 instead of 1 for now? > Yes. I agree. I will push the patch that removes archiso_early on my git branch to be merged in master ;) Thanks for the feedback. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

3 8

[arch-releng] [PATCH 14/15] [syslinux-iso] Set iso and kernel version dynamically.
by Gerardo Exequiel Pozzi 17 Mar '10

17 Mar '10

Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386(a)yahoo.com.ar> --- configs/syslinux-iso/Makefile | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/configs/syslinux-iso/Makefile b/configs/syslinux-iso/Makefile index 9368d1e..04c2de1 100644 --- a/configs/syslinux-iso/Makefile +++ b/configs/syslinux-iso/Makefile @@ -1,5 +1,4 @@ -ver=2010.03 -kver=2.6.32-ARCH +ver=$(shell date +%Y.%m.%d) WORKDIR=work @@ -11,6 +10,8 @@ COREname=$(PWD)/archlinux-$(ver)-core-$(ARCH).iso PACKAGES="$(shell cat packages.$(ARCH))" +kver_FILE=$(WORKDIR)/root-image/etc/mkinitcpio.d/kernel26.kver + all: net-iso core-iso # Rules for each type of image @@ -48,7 +49,7 @@ bootfiles: root-image initcpio: $(WORKDIR)/iso/boot/archiso.img $(WORKDIR)/iso/boot/archiso.img: mkinitcpio.conf $(WORKDIR)/root-image/.arch-chroot mkdir -p $(WORKDIR)/iso/boot - mkinitcpio -c ./mkinitcpio.conf -b $(WORKDIR)/root-image -k $(kver) -g $@ + mkinitcpio -c ./mkinitcpio.conf -b $(WORKDIR)/root-image -k $(shell grep ^ALL_kver $(kver_FILE) | cut -d= -f2) -g $@ # overlay filesystem -- 1.7.0.2

1 2

Re: [arch-releng] [PATCH 07/13] version update in Makefile
by Gerardo Exequiel Pozzi 17 Mar '10

17 Mar '10

On 03/16/2010 11:22 AM, Gerardo Exequiel Pozzi wrote: > On 03/16/2010 06:11 AM, Dieter Plaetinck wrote: >> On Tue, 16 Mar 2010 03:29:17 -0300 >> Gerardo Exequiel Pozzi<vmlinuz386(a)yahoo.com.ar> wrote: >> >>> Signed-off-by: Gerardo Exequiel Pozzi<vmlinuz386(a)yahoo.com.ar> >>> --- >>> configs/syslinux-iso/Makefile | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/configs/syslinux-iso/Makefile >>> b/configs/syslinux-iso/Makefile index 8118a8d..9368d1e 100644 >>> --- a/configs/syslinux-iso/Makefile >>> +++ b/configs/syslinux-iso/Makefile >>> @@ -1,4 +1,4 @@ >>> -ver=2010.02 >>> +ver=2010.03 >>> kver=2.6.32-ARCH >>> >>> WORKDIR=work >> wouldn't it be better to set ver=$((date +'%Y-%m-%d')) or however you >> should write that in Makefile syntax. >> >> now that the plan is to build automatically and frequently... >> >> Dieter >> > Yes, I done a similar change on my custom config. I can change here. > Internal label must keep with short-date ARCH_YYYYMM (11 chars). > > Also, will be good something but for kver= I thinking in parsing > $(WORKDIR)/root-image/etc/mkinitcpio.d/kernel26.kver > > What do you think? agree? > brb, missing sending this to ML. Sending the patch now... -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

1 0