On Mon, 5 Apr 2010 21:14:14 +0200 Dieter Plaetinck wrote:

On Mon, 05 Apr 2010 19:12:02 +0200 Sven-Hendrik Haase wrote:

...

Wait, weren't these going to be dual-arch images?

i will do dual-arch images yes. haven't had time yet. This shouldn't hold anyone back from testing the normal images though.

Dieter

okay guys, I ran Gerardo's archiso2dual script and wow. it seems to work nicely. Note that I have not tested the resulting dual arch images at all [yet]. I count on the community. @ Aaron: total size of all images is 1.8GB, nicely (way) below the 2.5GB treshold we had set for "serve them all or not". You can find the added dual images and updated Changelog @ http://build.archlinux.org/isos/ I used the "full" profile, so these things are stripped: ${work_dir}/tmp/${_arch}/root-image/boot ${work_dir}/tmp/${_arch}/root-image/usr/include ${work_dir}/tmp/${_arch}/root-image/usr/src ${work_dir}/tmp/${_arch}/root-image/usr/share ${work_dir}/tmp/${_arch}/root-image/lib/modules not sure if this is a good thing, if space permits I want to keep the docs, and the /usr/include and /usr/src seems also useful for those cases where you need to compile something. Dieter.

On 04/05/2010 10:14 PM, Dieter Plaetinck wrote:

On Mon, 05 Apr 2010 19:12:02 +0200 Sven-Hendrik Haase wrote:

...

Wait, weren't these going to be dual-arch images?

i will do dual-arch images yes. haven't had time yet. This shouldn't hold anyone back from testing the normal images though.

Dieter

here are the issues i found: * when testing the dual-arch, using Boot Arch Linux (x86_64/i686 ) the Mouting the root read-only is failing and another error at mounting local filesystems: /sbin/mount.aufs:plink.c:223: AUFS_CTL_PLINK_MAINT: Invalid argument. * boot normally and boot existing OS doesn't work -- Ionut

Am 06.04.2010 22:31, schrieb Dieter Plaetinck:

thanks, but need more info. which image is this ? netinstall or core? when does this happen? which step exactly in the init process? screenshot? what happens if you pick the normal x86, or the normal x86_64?

i just tried netinstall-dual, picked x86 and it works fine. I only have 32bit systems so i cannot try the other options. (well i can select them, but they refuse to boot, obviously :)

also, please use http://bugs.archlinux.org/index/proj6

That problem is known (I saw Gerardo posting about it either here or on the bugtracker). The 64 bit kernel/aufs lacks the 32 bit compatibility system call, so remounting aufs on 32 bit userland with a 64 bit kernel fails. We can't do anything about it, and it is read-write anyway.

On 04/06/2010 05:49 PM, Dieter Plaetinck wrote:

On Tue, 06 Apr 2010 22:38:24 +0200 Thomas Bächler wrote:

...

Am 06.04.2010 22:31, schrieb Dieter Plaetinck:

...

thanks, but need more info. which image is this ? netinstall or core? when does this happen? which step exactly in the init process? screenshot? what happens if you pick the normal x86, or the normal x86_64?

i just tried netinstall-dual, picked x86 and it works fine. I only have 32bit systems so i cannot try the other options. (well i can select them, but they refuse to boot, obviously :)

also, please use http://bugs.archlinux.org/index/proj6

That problem is known (I saw Gerardo posting about it either here or on the bugtracker). The 64 bit kernel/aufs lacks the 32 bit compatibility system call, so remounting aufs on 32 bit userland with a 64 bit kernel fails. We can't do anything about it, and it is read-write anyway.

hm you're right http://mailman.archlinux.org/pipermail/arch-releng/2010-February/000883.html

is this a system call which is not enabled in the arch kernels? or just does not exist? what exactly do you mean with "it is read-write anyway"? what is? and how is that relevant? If i understood ionut's mail correctly, this is something that breaks the boot process/environment. or not? maybe we should just disable the "64bit kernel with 32bit userspace" option.

Dieter

Not all 32 bit ioctls are implemented as wrapper to ioctls in 64 bits. This will work if -i parameter is add to mount in rc.sysinit. The mount -i does not call in this case to mount.aufs, just use mount. Maybe we can keep a overlay copy of rc.sysinit or ...(*) Anyway: I said that remouting / as ro (aufs) is not necessary. This is only necessary when you boot a normal filesystem with rw (normally will be mounted as ro), so in the next step can run fsck. * Maybe can be implemented without any issues in rc.sysinit at initscripts. -/bin/mount -n -o remount,ro / +/bin/mount -i -n -o remount,ro / -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

On Tue, 06 Apr 2010 14:01:00 -0500 Chris Brannon wrote:

Dieter Plaetinck wrote:

...

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 ;-)

Hello Dieter, I grabbed the latest netinstall image for i686, and I tried to do an install with dm_crypt. It failed. AIF tossed the following error message when it tried to make a filesystem on /dev/mapper/cryptoroot: Error: process_filesystem needs a partition as $1.

Here is what I specified during the "manually configure block devices" stage: * /dev/sda1 mounts on /boot, and has an fs type of ext4. * /dev/sda2 is swap. * /dev/sda3 is of type dm_crypt, and the label is cryptoroot. * /dev/mapper/cryptoroot contains an ext4 filesystem, and it mounts on /. I also indicated that all filesystems should be re-created.

PS. This is my first attempt to use dm_crypt, so it's possible that I may have made a mistake.

-- Chris

it looks like you did everything right (except i'm not sure if grub will work with /boot on ext4). if it died with that error, it looks as if /dev/mapper/cryptoroot did not exist. can you tell me which files are there in /dev/mapper ? is there a /var/log/aif/aif.logfile you can send/pastebin me? Dieter

On Tue, 06 Apr 2010 17:24:42 -0500 Chris Brannon wrote:

Dieter Plaetinck wrote:

...

can you tell me which files are there in /dev/mapper ?

/dev/mapper/control, and /dev/mapper/cryptoroot. These exist in both the failure case and the success case (see below).

...

is there a /var/log/aif/aif.logfile you can send/pastebin me?

Unfortunately, I can't make it fail consistently. When I invoke aif -p interactive -l -d it works beautifully.

I'm stumped. I can try the whole process again, if you like.

-- Chris

odd indeed. usually problems like this happen if you have been doing block device configuration (manually or through aif) before configuring them [again] in AIF. something stays "open" or something like that. (it should work if you use the rollback feature in aif though) if you had the problem when doing the installation thing directly after a fresh cd-rom boot, it would definitely be useful to have that logfile. if `aif -p interactive -l -p` does not fail and /arch/setup does, this might have something to do with the recent changes in the logging/debugging code (although it seems unlikely from the error you gave). some users have reporting /arch/setup not generating a logfile btw. Dieter

On Sat, 10 Apr 2010 09:30:19 -0500 Chris Brannon wrote:

Dieter Plaetinck wrote:

...

if you had the problem when doing the installation thing directly after a fresh cd-rom boot, it would definitely be useful to have that logfile.

I start the install directly after boot. The only thing I don't do is partition the drive, since it's already partitioned.

that should not be a problem

...

if `aif -p interactive -l -p` does not fail and /arch/setup does, this might have something to do with the recent changes in the logging/debugging code (although it seems unlikely from the error you gave). some users have reporting /arch/setup not generating a logfile btw.

Right. /arch/setup doesn't give me a logfile. IIRC, neither does aif -p interactive. And as I said, aif -p interactive -l -d works fine.

If it's at all important, I'm doing all of this in qemu. Not sure how that could matter, though.

-- Chris

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' ?) 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. Dieter

On 12/04/10 18:26, Sergey Samokhin wrote:

...

The more feedback I get from the community, the faster a new official release will happen.

I successfully installed netinstall-dual (x64) on VirtualBox using /arch/setup. The only thing that looks strange is the following error message while installing grub:

---Installation Complete--- ... installing grep... installing sed... installing grub... error: command failed to execute correctly installing gzip... installing libusb... ...

That is not an error to worry about. The grub post_install file needs a small fix. Allan

On 12/04/10 19:35, Thomas Bächler wrote:

Am 12.04.2010 11:10, schrieb Allan McRae:

...

...

---Installation Complete--- ... installing grep... installing sed... installing grub... error: command failed to execute correctly installing gzip... installing libusb... ...

That is not an error to worry about. The grub post_install file needs a small fix.

Allan

As far as I remember, many post_install scripts may fail during the initial installation, but none of them in a harmful way. We took care of most of it I think.

I posted a list to arch-dev-public a while ago. There is still 19 packages left to fix. Most of them are hidden (due to packages largely being installed in alphabetical order after dependency resolution). Allan