Am Dienstag, 23. Oktober 2007 17:12:46 schrieb Damir Perisa:

if we intend to change the repo-layout again (extra->{mantle,crust}), then this should happen before an ISO release.

Not really. Even the ftp install uses only the [core] repo. -- archlinux.de

Tuesday 23 October 2007, Aaron Griffin wrote: | On 10/23/07, Pierre Schmitz wrote: | > Am Dienstag, 23. Oktober 2007 17:12:46 schrieb Damir Perisa: | > > if we intend to change the repo-layout again | > > (extra->{mantle,crust}), then this should happen before an ISO | > > release. | > | > Not really. Even the ftp install uses only the [core] repo. | | But it does affect pacman.conf, but that's not a big issue. | | I agree with Pierre's sentiment though, there's no sense in | delaying ISOs to do this. ah ok - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><

Am Dienstag, 23. Oktober 2007 schrieb Dan McGee:

On 10/23/07, Tobias Powalowski wrote:

...

Hi i just placed the new "Core Dump" TEST ISO to the mirrors: ftp://ftp.archlinux.org/other/rc-iso/2007.11/

1 week testing should be enough, I tested them in kvm-qemu and didn't find an issue.

All sorts of problems in QEMU on windows. If I boot normal (not legacy) with only a CDROM drive, i get a bunch of errors like this (have to type them by hand): ata2.00: exception Emax 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/00:00:00:00:... tag 0 cdb 0x12 date 36 in res 40/0000:... Emaxk 0x4 (timeout) ata2: soft resetting port ata2.00: configured for MWDMA1 ata2: EH complete

All sorts of weird stuff. ide-legacy just hung at the udev stage.

Any ideas?

And on another note, testing in one emulator only is not a very extensive procedure. Simo and I noticed differences even between qemu and qemu-kvm behavior (so we should at the least be testing both of these), not to mention booting on real hardware.

I'll try to burn this sometime and boot it up on a real machine, we definitely need testing like that.

-Dan

As i stated last time iso testing is easy: 1. use your favorite emulator (qemu,virtualbox,vmware etc.) 2. extract kernel and initramdisk from iso file fire up those 2 files from grub and install to external media like usb disk by mounting the iso manually to install environment 3. use real cds greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org

Dan McGee schrieb:

Looks like I can chalk this one up to using the -kernel-kqemu flag. Probably not something we need to worry about, not using it makes everything work just fine.

In my past experience, -kernel-kqemu breaks even more than "normal" kqemu or qemu without kqemu, but it seems to depend on the CPU: I had breakage in Windows 2000, while a friend of mine (using the same kernel, kqemu and qemu build) had no problems at all.

Am Dienstag, 23. Oktober 2007 schrieb Thomas Bächler:

Dan McGee schrieb:

...

All sorts of problems in QEMU on windows. If I boot normal (not legacy) with only a CDROM drive, i get a bunch of errors like this (have to type them by hand): ata2.00: exception Emax 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd a0/00:00:00:00:... tag 0 cdb 0x12 date 36 in res 40/0000:... Emaxk 0x4 (timeout) ata2: soft resetting port ata2.00: configured for MWDMA1 ata2: EH complete

All sorts of weird stuff. ide-legacy just hung at the udev stage.

Any ideas?

And on another note, testing in one emulator only is not a very extensive procedure. Simo and I noticed differences even between qemu and qemu-kvm behavior (so we should at the least be testing both of these),

qemu or qemu+kqemu don't work well, they never did for me. Never tested kvm, but it is reported to be better. I could try vbox later, which always goes well.

i would also recommend to use the qemu-kvm binary on non kvm systems, it runs just better as normal qemu and can be combined with kqemu too. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org