[arch-releng] Dep cycles in core and 2009.01

newer
[arch-releng] Final checklist for...

older
[arch-releng] Possible issue with...

Aaron Griffin

29 Jan 2009 29 Jan '09

7:24 p.m.

Hello all, Just a "heads up" - I am currently rebuilding packages due to some dependency cycles in core that caused install scriptlets to fail when installing a new system. Later today I want to push out a beta3 ISO containing the fixed packages (for the core images), and a new installer, in addition to a minor usbdelay related fix. Now... I will be leaving for the weekend on a little vacation Friday night. What I'd like, when I push this out, is for people to "signoff" on this. In order to signoff, please list: * The full name of the image used * Real hardware, or virtual machine * Bootloader used * FS types used (useful for ext4 or esoteric filesystems) * Other setup tweaks (encryption, lvm, etc) * Success / Failure * Related bug report links We will not be completely able to fix 100% of bugs, so we need a "good enough for most people" rating, right now. If all goes as planned, the same beta3 images will be used for release. If we run into too many issues, we may need to make this a 2009.02 release :( Cheers, Aaron

Show replies by date

Alexander De Sousa

29 Jan 29 Jan

9:35 p.m.

Whenever it goes out I'll try it and reply with the results (though I think it will have to be about 5 PM UTC, anyway I'll reply as soon as I can). Everything will be ok! There's no room for a 2009.02 ;) - Alexander. On Thu, Jan 29, 2009 at 8:24 PM, Aaron Griffin wrote:

...

Hello all, Just a "heads up" - I am currently rebuilding packages due to some dependency cycles in core that caused install scriptlets to fail when installing a new system.

Later today I want to push out a beta3 ISO containing the fixed packages (for the core images), and a new installer, in addition to a minor usbdelay related fix.

Now... I will be leaving for the weekend on a little vacation Friday night. What I'd like, when I push this out, is for people to "signoff" on this.

In order to signoff, please list: * The full name of the image used * Real hardware, or virtual machine * Bootloader used * FS types used (useful for ext4 or esoteric filesystems) * Other setup tweaks (encryption, lvm, etc) * Success / Failure * Related bug report links

We will not be completely able to fix 100% of bugs, so we need a "good enough for most people" rating, right now. If all goes as planned, the same beta3 images will be used for release.

If we run into too many issues, we may need to make this a 2009.02 release :(

Cheers, Aaron

Pierre Schmitz

30 Jan 30 Jan

11:05 a.m.

Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...

If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Dieter Plaetinck

11:26 a.m.

On Fri, 30 Jan 2009 12:05:55 +0100 Pierre Schmitz wrote:

...

Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Good idea. Or, assuming it's moved .. about now.. ( still beta2's @ http://dev.archlinux.org/~aaron/archiso/ :( ) we could even announce it JIT for a 2009.01 (saturday evening)

Gerhard Brauer

12:19 p.m.

Am Fri, 30 Jan 2009 12:05:55 +0100 schrieb Pierre Schmitz :

...

Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Sorry, I'm meanwhile totally against such "Counter strike" actions! A few background infos: First "release" should be on 24.12.2008, Aaron and myself thought: Hey, let's modify the installer to support ext4, bring grub to work with ext4 and build a ISO with 2.6.28. This looks first good, but than we run in time- and communications problems during different timezones, christmas/family, etc. Next "release" was close for 31.12.2008, we have done a few bugfixes we found, but the time plan was not possible cause not all needed packages went to core (Looking from current to this past it was good that these "time plans" could not be solved) Then comes the showstopper with USB keyboard in initrd and the problems with the USB images. Meanwhile all needed packages are in core, but these problems costs us time (and lead to the private/alpha/beta ISOs). But a "release" was very close on the first January's days, so we anounce the "Release group", establish this ML and the bugtracker. This step was totally OK, but we were confronted with a lot of major/minor problems and features. This "strike" us in a situation where the releng group was not really in the state of a working group to handle these things in a good way. So my opinion is: We should stop this chaos to try releasing "tomorrow" again and again! My plan is: Week 6: build and test the RCs (what Aaron named beta3). Duration of RC testing could be increased to week 7 if needed. Definitively release date is: week 7 (or latest week 8 when we must increase RC testing phase). IMHO this is more realistic than our other "plans". Gerhard

Dieter Plaetinck

2:09 p.m.

On Fri, 30 Jan 2009 13:19:26 +0100 Gerhard Brauer wrote:

...

Am Fri, 30 Jan 2009 12:05:55 +0100 schrieb Pierre Schmitz :

...
Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Sorry, I'm meanwhile totally against such "Counter strike" actions!

A few background infos: First "release" should be on 24.12.2008, Aaron and myself thought: Hey, let's modify the installer to support ext4, bring grub to work with ext4 and build a ISO with 2.6.28. This looks first good, but than we run in time- and communications problems during different timezones, christmas/family, etc.

Next "release" was close for 31.12.2008, we have done a few bugfixes we found, but the time plan was not possible cause not all needed packages went to core (Looking from current to this past it was good that these "time plans" could not be solved)

Then comes the showstopper with USB keyboard in initrd and the problems with the USB images. Meanwhile all needed packages are in core, but these problems costs us time (and lead to the private/alpha/beta ISOs). But a "release" was very close on the first January's days, so we anounce the "Release group", establish this ML and the bugtracker. This step was totally OK, but we were confronted with a lot of major/minor problems and features. This "strike" us in a situation where the releng group was not really in the state of a working group to handle these things in a good way.

So my opinion is: We should stop this chaos to try releasing "tomorrow" again and again!

My plan is: Week 6: build and test the RCs (what Aaron named beta3). Duration of RC testing could be increased to week 7 if needed. Definitively release date is: week 7 (or latest week 8 when we must increase RC testing phase).

IMHO this is more realistic than our other "plans".

Gerhard

Actually there were already a few iterations before that. we first wanted to do a 2.6.27 release (which also was delayed already for a few months. but then was also the archiso scripts rewrite). The 2.6.28 release has been postphoned a lot because of little issues popping up needing to be adressed. I think what we have decided now (build "final" iso's, ask for signoffs, and if enough: release) is good. The plan is afaik to release if the iso's seem *good enough for most users*, if there are still small problems with these beta3's (and hence the final release) we can still (try to) fix them for the next release. This idea breaks with the "try to make it absolutely perfect" idea which keeps on delaying the release. I like this. As long as there are no big showstoppers we should be able to release. After all, we plan to release every 3 months. non-showstoppers can move to the next cycle if we couldn't address them in time. PS: the beta3 iso's seem to be arriving @ http://dev.archlinux.org/~aaron/archiso/ now. Start your engines! Dieter

Aaron Griffin

3:23 p.m.

On Fri, Jan 30, 2009 at 5:05 AM, Pierre Schmitz wrote:

...

Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Well, the only thing I realized is that the core ISOs don't have the 4 packages I just moved on them. Signoffs took too long. So at the very least the core ISOs will need to be rebuilt. beta3 ISOs are uploading now (my little script I ran last night failed at the upload step, had to upload this morning). x86_64 still building, will be uploaded as they complete

Dieter Plaetinck

3:55 p.m.

On Fri, 30 Jan 2009 09:23:56 -0600 Aaron Griffin wrote:

...

On Fri, Jan 30, 2009 at 5:05 AM, Pierre Schmitz wrote:

...
Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Well, the only thing I realized is that the core ISOs don't have the 4 packages I just moved on them. Signoffs took too long. So at the very least the core ISOs will need to be rebuilt.

beta3 ISOs are uploading now (my little script I ran last night failed at the upload step, had to upload this morning). x86_64 still building, will be uploaded as they complete

Fwiw, i just finished a test.. 1) archlinux-2009.01-beta3-core-i686-isolinux.iso 2) packages from core on cd 3) virtualbox-ose 32bit 4) grub 5) autoprepare with ext4 for / and /home Install succeeded, but I had the following non-critical issues: (for some people the archiso-early one might be critical) 1) archiso-early problem: http://bugs.archlinux.org/task/13049 2) texinfo and bash packages, when being installed give "scriptlet failed to execute successfully" 3) dependcy cycle: bash/readline/ncurses will be installed before their glibc dependency. 4) nextitem bug still there. http://bugs.archlinux.org/task/12947 5) 2 lines are being echoed to stdout in grub section. http://bugs.archlinux.org/task/13050 Oh and btw: my fever is almost entirely gone now :)) Dieter

jonathan gustafsson

4:24 p.m.

My test is finished too. * archlinux-2009.01-beta3-core-i686-isolinux.iso * Real hardware. * Grub. * ext4 for / and /home reiser for /var * None * Success * No critical bugs. Nice work :)

...

Date: Fri, 30 Jan 2009 16:55:55 +0100 From: dieter@plaetinck.be To: arch-releng@archlinux.org Subject: Re: [arch-releng] Dep cycles in core and 2009.01

On Fri, 30 Jan 2009 09:23:56 -0600 Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 5:05 AM, Pierre Schmitz wrote:

...
Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Well, the only thing I realized is that the core ISOs don't have the 4 packages I just moved on them. Signoffs took too long. So at the very least the core ISOs will need to be rebuilt.

beta3 ISOs are uploading now (my little script I ran last night failed at the upload step, had to upload this morning). x86_64 still building, will be uploaded as they complete

Fwiw, i just finished a test.. 1) archlinux-2009.01-beta3-core-i686-isolinux.iso 2) packages from core on cd 3) virtualbox-ose 32bit 4) grub 5) autoprepare with ext4 for / and /home

Install succeeded, but I had the following non-critical issues: (for some people the archiso-early one might be critical)

1) archiso-early problem: http://bugs.archlinux.org/task/13049 2) texinfo and bash packages, when being installed give "scriptlet failed to execute successfully" 3) dependcy cycle: bash/readline/ncurses will be installed before their glibc dependency. 4) nextitem bug still there. http://bugs.archlinux.org/task/12947 5) 2 lines are being echoed to stdout in grub section. http://bugs.archlinux.org/task/13050

Oh and btw: my fever is almost entirely gone now :))

Dieter

_________________________________________________________________ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/

Troy Ankersen

5:11 p.m.

My testing USB of image. archlinux-2009.01-beta3-ftp-i686.img Real hardware Boot failure several "failed to mount /dev/sda(x) then system freezes just as described in FS#12896. troy

...

Date: Fri, 30 Jan 2009 16:55:55 +0100 From: dieter@plaetinck.be To: arch-releng@archlinux.org Subject: Re: [arch-releng] Dep cycles in core and 2009.01

On Fri, 30 Jan 2009 09:23:56 -0600 Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 5:05 AM, Pierre Schmitz wrote:

...
Am Donnerstag 29 Januar 2009 20:24:28 schrieb Aaron Griffin:

...
If all goes as planned, the same beta3 images will be used for release.

So, its more an RC then. :-) Maybe you could even move it straigt to the ftp dir with its final name and if nothing goes wrong we can just announce it on Monday. This way it will be already synced by the mirrors.

Well, the only thing I realized is that the core ISOs don't have the 4 packages I just moved on them. Signoffs took too long. So at the very least the core ISOs will need to be rebuilt.

beta3 ISOs are uploading now (my little script I ran last night failed at the upload step, had to upload this morning). x86_64 still building, will be uploaded as they complete

Fwiw, i just finished a test.. 1) archlinux-2009.01-beta3-core-i686-isolinux.iso 2) packages from core on cd 3) virtualbox-ose 32bit 4) grub 5) autoprepare with ext4 for / and /home

Install succeeded, but I had the following non-critical issues: (for some people the archiso-early one might be critical)

1) archiso-early problem: http://bugs.archlinux.org/task/13049 2) texinfo and bash packages, when being installed give "scriptlet failed to execute successfully" 3) dependcy cycle: bash/readline/ncurses will be installed before their glibc dependency. 4) nextitem bug still there. http://bugs.archlinux.org/task/12947 5) 2 lines are being echoed to stdout in grub section. http://bugs.archlinux.org/task/13050

Oh and btw: my fever is almost entirely gone now :))

Dieter

check out the rest of the Windows Live™. More than mail–Windows Live™ goes way beyond your inbox. More than messages

Pierre Schmitz

4:41 p.m.

Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...

x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Alexander De Sousa

4:58 p.m.

I confirm that archlinux-2009.01-beta3-ftp-i686.iso has a x86_64 kernel (or at least seems to have). The isolinux ftp image archlinux-2009.01-beta3-ftp-i686-isolinux.iso has an i686 kernel inside. I'm trying to perform a clean install from it, I reply when finished. On Fri, Jan 30, 2009 at 5:41 PM, Pierre Schmitz wrote:

...

Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

--

Pierre Schmitz

Clemens-August-Straße 76 53115 Bonn

Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Aaron Griffin

4:59 p.m.

On Fri, Jan 30, 2009 at 10:41 AM, Pierre Schmitz wrote:

...

Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Oh crap, my fault. I didn't change the ARCH when building the x86_64 images.... but they were still x86_64 images... gah. Re-uploading now

Dieter Plaetinck

5:08 p.m.

On Fri, 30 Jan 2009 10:59:11 -0600 Aaron Griffin wrote:

...

On Fri, Jan 30, 2009 at 10:41 AM, Pierre Schmitz wrote:

...
Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Oh crap, my fault. I didn't change the ARCH when building the x86_64 images.... but they were still x86_64 images... gah. Re-uploading now

automation anyone? :)

Aaron Griffin

5:13 p.m.

On Fri, Jan 30, 2009 at 11:08 AM, Dieter Plaetinck wrote:

...

On Fri, 30 Jan 2009 10:59:11 -0600 Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 10:41 AM, Pierre Schmitz wrote:

...
Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Oh crap, my fault. I didn't change the ARCH when building the x86_64 images.... but they were still x86_64 images... gah. Re-uploading now

automation anyone? :)

Yeah, switching it to use $(uname -m) for now :S

Aaron Griffin

6:56 p.m.

On Fri, Jan 30, 2009 at 11:13 AM, Aaron Griffin wrote:

...

On Fri, Jan 30, 2009 at 11:08 AM, Dieter Plaetinck wrote:

...
On Fri, 30 Jan 2009 10:59:11 -0600 Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 10:41 AM, Pierre Schmitz wrote:

...
Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Oh crap, my fault. I didn't change the ARCH when building the x86_64 images.... but they were still x86_64 images... gah. Re-uploading now

automation anyone? :)

Yeah, switching it to use $(uname -m) for now :S

Should be all corrected, except for the i686 core ISOs, so I removed those until I can get new ones uploaded (my network at work is going down for a bit here, so can't do it just yet...)

Alexander De Sousa

6:57 p.m.

Forgot to mention that the mirror I used was not ftp.archlinux.org (to take care of bandwith). It was www.mirrorservice.org at the Kent University as it is fast enough, so I may have not used the lastest texinfo and bash packages. On Fri, Jan 30, 2009 at 7:56 PM, Aaron Griffin wrote:

...

On Fri, Jan 30, 2009 at 11:13 AM, Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 11:08 AM, Dieter Plaetinck wrote:

...
On Fri, 30 Jan 2009 10:59:11 -0600 Aaron Griffin wrote:

...
On Fri, Jan 30, 2009 at 10:41 AM, Pierre Schmitz wrote:

...
Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Oh crap, my fault. I didn't change the ARCH when building the x86_64 images.... but they were still x86_64 images... gah. Re-uploading now

automation anyone? :)

Yeah, switching it to use $(uname -m) for now :S

Should be all corrected, except for the i686 core ISOs, so I removed those until I can get new ones uploaded (my network at work is going down for a bit here, so can't do it just yet...)

Gerardo Exequiel Pozzi

5:10 p.m.

Pierre Schmitz wrote:

...

Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Hi, same here, but with the archlinux-2009.01-beta3-core-i686.iso this is and x86_64. Trying to boot (virtualbox) with 64 bits enabled, boots but appears this error: :: Passing control to Arch Linux Initscripts...Please Wait /bin/run-init: opening console: No such file or directory Kernel Panic - not syncing: Attempted to kill init! And also this http://bugs.archlinux.org/task/13049 And there is and error in tryboot.lst, it have a three fallback commands in menu entries, the fallback command is invalid at theses points, is only for "general section" timeout 0 default 0 title Scanning for /boot/grub/menu.lst fallback 1 find --set-root --ignore-floppies /boot/grub/menu.lst configfile /boot/grub/menu.lst .... -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Stephan Platz

6:28 p.m.

On Freitag 30 Januar 2009 18:10:48 Gerardo Exequiel Pozzi wrote:

...

Pierre Schmitz wrote:

...
Am Freitag 30 Januar 2009 16:23:56 schrieb Aaron Griffin:

...
x86_64 still building, will be uploaded as they complete

I just downloaded archlinux-2009.01-beta3-ftp-i686.iso but vbox couldn't boot it because it contains th x86_64 kernel instead of the i686 one. I'll download the other images to check if they have the same problem.

Hi, same here, but with the archlinux-2009.01-beta3-core- i686.iso this is and x86_64.

Trying to boot (virtualbox) with 64 bits enabled, boots but appears this

error: :: Passing control to Arch Linux Initscripts...Please Wait

/bin/run-init: opening console: No such file or directory Kernel Panic - not syncing: Attempted to kill init!

And also this http://bugs.archlinux.org/task/13049

Same here on a KVM-System with the i686-ftp beta3 Greeting Stephan

Alexander De Sousa

6:49 p.m.

The install process finished correctly in VirtualBox virtual machines: · Image: archlinux-2009.01-beta3-ftp-i686-isolinux.iso 30.01.09 09:49 · VM Configuration: -> ACPI : Enabled -> IO APIC: Enabled -> VT-x: Enabled, not enabling nested paging. -> PAE: Enabled -> Primary HD connected to a SATA port. -> Network adapter: Intel Gigabit Desktop. -> USB: Enabled, EHCI too. · Partition layout: Autoprepare like, all ext4. · Installed packages: Base only. · Bootloader: Grub 2nd install: Same thing, partition layout: ext2 /boot, ext4 /home, ext4 /, reiserfs /var. 3rd install: Still same configuration, partition layout: ext3 /boot, ext4 / and /home, jfs /tmp, xfs /var. 4th install, same as above but: -> IO APIC: Disabled. -> VT-x: Disabled. -> PAE: Disabled. -> Primary HD connected via IDE master, not SATA. -> Layout: Same as 3rd install. Issues corrected: -> The next item bug (http://bugs.archlinux.org/task/12947) appears to be corrected (at least here :S). -> Mirror used during install is correctly reflected in mirrorlist, no more "core" hardcoded :). (http://bugs.archlinux.org/task/12944) Bad ones (in my opinion they're not critical, installation is correct): -> Textinfo and bash packages: "scriptlet failed to execute successfully", as always. -> Bash, readline and ncurses dependency problem, as always. -> I confirm the archiso-early problem in this image ( http://bugs.archlinux.org/task/13049) I'll now perform installs on real hardware, though I can't try RAIDs nor LVM configurations right now.

Dieter Plaetinck

7:10 p.m.

On Fri, 30 Jan 2009 19:49:27 +0100 Alexander De Sousa wrote:

...

I'll now perform installs on real hardware, though I can't try RAIDs nor LVM configurations right now.

I just did an install with a 'normal' boot, a swap and a dm_crypt volume with lvm on top of that, containing 3 lvm LV's: 2 xfs, and 1 ext4. works like a charm (other then the issues already reported) (but i cheated a bit and just used aif B-) Dieter

Gerardo Exequiel Pozzi

11:24 p.m.

Aaron Griffin wrote:

...

Hello all, Just a "heads up" - I am currently rebuilding packages due to some dependency cycles in core that caused install scriptlets to fail when installing a new system.

Later today I want to push out a beta3 ISO containing the fixed packages (for the core images), and a new installer, in addition to a minor usbdelay related fix.

Now... I will be leaving for the weekend on a little vacation Friday night. What I'd like, when I push this out, is for people to "signoff" on this.

In order to signoff, please list: * The full name of the image used * Real hardware, or virtual machine * Bootloader used * FS types used (useful for ext4 or esoteric filesystems) * Other setup tweaks (encryption, lvm, etc) * Success / Failure * Related bug report links

We will not be completely able to fix 100% of bugs, so we need a "good enough for most people" rating, right now. If all goes as planned, the same beta3 images will be used for release.

If we run into too many issues, we may need to make this a 2009.02 release :(

Cheers, Aaron

Hi, * archlinux-2009.01-beta3-core-i686.iso (sha1sum verified OK) * Virtualbox 2.1.2 (SATA HD) * GRUB * installation command: /arch/setup (base system only) * (manual partition) [sda1 / ext4] [sda5 /var ext4] [sda6 /home ext4] [sda3 swap] * { It contains old bash-3.2.048-2, glibc-2.9-2, and texinfo-4.13a-1 in /src/core/pkg :( Only the "live-root-fs" is update with these packages. Have the archiso-early problem: http://bugs.archlinux.org/task/13049 } Installed system boot OK ;) * archlinux-2009.01-beta3-core-x86_64.iso (sha1sum verified OK) * Virtualbox 2.1.2 (SATA HD) * GRUB * installation command: /arch/setup (base system only) * (manual partition) [sda1 / ext4] [sda5 /var ext4] [sda6 /home ext4] [sda3 swap] * { It contains old bash-3.2.048-2, glibc-2.9-2, and texinfo-4.13a-1 in /src/core/pkg :( Only the "live-root-fs" is update with these packages. Have the archiso-early problem: http://bugs.archlinux.org/task/13049 **** GRUB FAIL (setup reports OK) it uses grub-gfx (grub-install reference to /sbin/grub not /mnt/sbin/grub ) that fails in x86_64 **** } To solve the GRUB problem when setup is finished, i executed: mount --bind /proc /mnt/proc mount --bind /dev /mnt/dev chroot /mnt cat /proc/mounts > /etc/mtab ## df command need this, otherwise it fails and grub not installed. grub-install --recheck --no-floppy /dev/sda exit umount /mnt/dev umount /mnt/proc reboot Installed system boot OK ;) -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Gerardo Exequiel Pozzi

31 Jan 31 Jan

12:16 a.m.

Gerardo Exequiel Pozzi wrote:

...

Aaron Griffin wrote:

...
Hello all, Just a "heads up" - I am currently rebuilding packages due to some dependency cycles in core that caused install scriptlets to fail when installing a new system.

Later today I want to push out a beta3 ISO containing the fixed packages (for the core images), and a new installer, in addition to a minor usbdelay related fix.

Now... I will be leaving for the weekend on a little vacation Friday night. What I'd like, when I push this out, is for people to "signoff" on this.

In order to signoff, please list: * The full name of the image used * Real hardware, or virtual machine * Bootloader used * FS types used (useful for ext4 or esoteric filesystems) * Other setup tweaks (encryption, lvm, etc) * Success / Failure * Related bug report links

We will not be completely able to fix 100% of bugs, so we need a "good enough for most people" rating, right now. If all goes as planned, the same beta3 images will be used for release.

If we run into too many issues, we may need to make this a 2009.02 release :(

Cheers, Aaron

Hi,

* archlinux-2009.01-beta3-core-i686.iso (sha1sum verified OK) * Virtualbox 2.1.2 (SATA HD) * GRUB * installation command: /arch/setup (base system only) * (manual partition) [sda1 / ext4] [sda5 /var ext4] [sda6 /home ext4] [sda3 swap] * { It contains old bash-3.2.048-2, glibc-2.9-2, and texinfo-4.13a-1 in /src/core/pkg :( Only the "live-root-fs" is update with these packages. Have the archiso-early problem: http://bugs.archlinux.org/task/13049 }

Installed system boot OK ;)

* archlinux-2009.01-beta3-core-x86_64.iso (sha1sum verified OK) * Virtualbox 2.1.2 (SATA HD) * GRUB * installation command: /arch/setup (base system only) * (manual partition) [sda1 / ext4] [sda5 /var ext4] [sda6 /home ext4] [sda3 swap] * { It contains old bash-3.2.048-2, glibc-2.9-2, and texinfo-4.13a-1 in /src/core/pkg :( Only the "live-root-fs" is update with these packages. Have the archiso-early problem: http://bugs.archlinux.org/task/13049 **** GRUB FAIL (setup reports OK) it uses grub-gfx (grub-install reference to /sbin/grub not /mnt/sbin/grub ) that fails in x86_64 **** }

To solve the GRUB problem when setup is finished, i executed: mount --bind /proc /mnt/proc mount --bind /dev /mnt/dev chroot /mnt cat /proc/mounts > /etc/mtab ## df command need this, otherwise it fails and grub not installed. grub-install --recheck --no-floppy /dev/sda exit umount /mnt/dev umount /mnt/proc reboot

Installed system boot OK ;)

Also contructed with old readline, gcc, gcc-libs and fakeroot Ooohh! The grub-gfx installed at root-image-fs (x86_64) is the grub-gfx-0.97-7 (latest from community) and in i686 is 0.97-11. I tested compiling the grub-gfx for x86_84 sync to -11 version. copied with scp to installCD , pacman -U grub-gfx-0.97-11-x86_64.pkg.tar.gz And install grub like /arch/setup and now WORKS :) BTW: grub-gfx in ABS lack some patches, i copied all from ABS grub. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Gerardo Exequiel Pozzi

3:11 a.m.

Gerardo Exequiel Pozzi wrote:

...

Also contructed with old readline, gcc, gcc-libs and fakeroot

Oops! Ignore this (i booted old beta2 to do some test), only the: bash, glibc, readline and texinfo packages are old (in /src/core/pkg) on both iso: archlinux-2009.01-beta3-core-i686.iso archlinux-2009.01-beta3-core-x86_64.iso -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Gerhard Brauer

10:18 a.m.

Am Fri, 30 Jan 2009 22:16:57 -0200 schrieb Gerardo Exequiel Pozzi :

...

Ooohh! The grub-gfx installed at root-image-fs (x86_64) is the grub-gfx-0.97-7 (latest from community) and in i686 is 0.97-11. I tested compiling the grub-gfx for x86_84 sync to -11 version. copied with scp to installCD , pacman -U grub-gfx-0.97-11-x86_64.pkg.tar.gz

Oh, then the grub-gfx maintainer doesn't build also the x86_64 version :-( I wrote him in a bugreport FS#12616 to add ext4 support (and ext3 big-inode patch) to grub-gfx and the i686 version was rebuild fine with these changes.

...

And install grub like /arch/setup and now WORKS :)

FS#13059 is the new grub-gfx bugreport to fix for x86_64. Thanks Gerardo!

...

BTW: grub-gfx in ABS lack some patches, i copied all from ABS grub.

Yeah, i also saw this.. First i wonder about the grub-gfx problems you mentioned, cause grub-gfx and grub uses the same patches (and upstream source), only addition is the patch for splash support. And this should not prevent the bare installation of grub(-gfx). But with this version-differing the reason is clear. x86_64 ISO/images (RC1 candidates) should wait until grub-gfx's new version is available. Gerhard

Allan McRae

10:23 a.m.

Gerhard Brauer wrote:

...

Am Fri, 30 Jan 2009 22:16:57 -0200 schrieb Gerardo Exequiel Pozzi :

...
Ooohh! The grub-gfx installed at root-image-fs (x86_64) is the grub-gfx-0.97-7 (latest from community) and in i686 is 0.97-11. I tested compiling the grub-gfx for x86_84 sync to -11 version. copied with scp to installCD , pacman -U grub-gfx-0.97-11-x86_64.pkg.tar.gz

Oh, then the grub-gfx maintainer doesn't build also the x86_64 version :-( I wrote him in a bugreport FS#12616 to add ext4 support (and ext3 big-inode patch) to grub-gfx and the i686 version was rebuild fine with these changes.

...
And install grub like /arch/setup and now WORKS :)

FS#13059 is the new grub-gfx bugreport to fix for x86_64. Thanks Gerardo!

...
BTW: grub-gfx in ABS lack some patches, i copied all from ABS grub.

Yeah, i also saw this..

First i wonder about the grub-gfx problems you mentioned, cause grub-gfx and grub uses the same patches (and upstream source), only addition is the patch for splash support. And this should not prevent the bare installation of grub(-gfx). But with this version-differing the reason is clear. x86_64 ISO/images (RC1 candidates) should wait until grub-gfx's new version is available.

Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer? Allan

Gerhard Brauer

10:43 a.m.

Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...

Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

...

Allan

Gerhard

Allan McRae

3:10 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Gerhard Brauer wrote:

...

Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package. Allan

Gerardo Exequiel Pozzi

3:47 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Allan McRae wrote:

...

Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin) * Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have. May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Allan McRae

3:52 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Gerardo Exequiel Pozzi wrote:

...

Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug. Allan

Dieter Plaetinck

7:52 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

On Sun, 01 Feb 2009 01:52:52 +1000 Allan McRae wrote:

...

Gerardo Exequiel Pozzi wrote:

...
Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug.

Allan

So do I understand correctly... *problem 1*: grub-gfx vs grub: We can fix the problem that grub-gfx instead of grub is installed if we just chroot I think. Eg: chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1 But, this only affects 64bit right? or not? (because in my tests the grub didn't look very fancy..) If so, can someone with a 64bit (virtual) machine change the above line in /arch/setup and test it? If okay, someone with access to archlinux-installer can fix the line and repackage. If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package. *problem 2*: Gerardo says "grub-gfx fails", this is the same as Alexanders problem, right? ("I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly)"). IIRC Gerardo already tried the new package , tested it and confirmed that it works. So we just need to get it on the iso. See http://bugs.archlinux.org/task/13068 Dieter

Dieter Plaetinck

8:07 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

On Sat, 31 Jan 2009 20:52:34 +0100 Dieter Plaetinck wrote:

...

On Sun, 01 Feb 2009 01:52:52 +1000 Allan McRae wrote:

...
Gerardo Exequiel Pozzi wrote:

...
Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug.

Allan

So do I understand correctly...

*problem 1*: grub-gfx vs grub: We can fix the problem that grub-gfx instead of grub is installed if we just chroot I think. Eg: chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

But, this only affects 64bit right? or not? (because in my tests the grub didn't look very fancy..) If so, can someone with a 64bit (virtual) machine change the above line in /arch/setup and test it? If okay, someone with access to archlinux-installer can fix the line and repackage.

If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package.

*problem 2*: Gerardo says "grub-gfx fails", this is the same as Alexanders problem, right? ("I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly)").

IIRC Gerardo already tried the new package , tested it and confirmed that it works. So we just need to get it on the iso. See http://bugs.archlinux.org/task/13068

Dieter

Also, I went over all 2009.01 mails to see if we catched all issues. All of them are fixed or being handled right now, except one more grub related one posted by Gerardo: http://www.archlinux.org/pipermail/arch-releng/2009-January/000167.html quote: "And there is and error in tryboot.lst, it have a three fallback commands in menu entries, the fallback command is invalid at theses points, is only for "general section" timeout 0 default 0 title Scanning for /boot/grub/menu.lst fallback 1 find --set-root --ignore-floppies /boot/grub/menu.lst configfile /boot/grub/menu.lst .... " what is tryboot.lst? which fallback command? do you get any errors? or will this stuff be automagically fixed if we fix problem 1 and 2 from above? Dieter

Alexander De Sousa

8:11 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

On Sat, Jan 31, 2009 at 8:52 PM, Dieter Plaetinck wrote:

...

On Sun, 01 Feb 2009 01:52:52 +1000 Allan McRae wrote:

...
Gerardo Exequiel Pozzi wrote:

...
Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug.

Allan

So do I understand correctly...

*problem 1*: grub-gfx vs grub: We can fix the problem that grub-gfx instead of grub is installed if we just chroot I think. Eg: chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

But, this only affects 64bit right? or not? (because in my tests the grub didn't look very fancy..) If so, can someone with a 64bit (virtual) machine change the above line in /arch/setup and test it? If okay, someone with access to archlinux-installer can fix the line and repackage.

If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package.

*problem 2*: Gerardo says "grub-gfx fails", this is the same as Alexanders problem, right? ("I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly)").

IIRC Gerardo already tried the new package , tested it and confirmed that it works. So we just need to get it on the iso. See http://bugs.archlinux.org/task/13068

Dieter

Hmm... I think both problems are the same... I'm a bit confused right now. I'll try to perform an install changing that line in the script and I'll tell you in some minutes what happens. In the other tests of the 64-bit images, the problem I found was that when /boot is an extX partition, the installation of the GRUB bootloader doesn't reach the point where it updates the MBR of the chosen disk (the installation finishes without any problem, as usual, with no error reported) (though I didn't verify it was really installed, I'll do this time); and so not being able to even reach the GRUB menu loader once the machine is rebooted. I've also tried using an raiserfs based boot partition and it worked. That's problem number 2 as far as I know, one of the grub packages, grub-gfx or grub (right now I don't which one) is out of date regarding the ext4 and the big inode patches. Let's see if problem number 1 is solved just chroot'ing. -- Alexander

Gerardo Exequiel Pozzi

8:52 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Dieter Plaetinck wrote:

...

On Sat, 31 Jan 2009 20:52:34 +0100 Dieter Plaetinck wrote:

...
On Sun, 01 Feb 2009 01:52:52 +1000 Allan McRae wrote:

...
Gerardo Exequiel Pozzi wrote:

...
Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

> Would it be a good idea to move grub-gfx to [extra] if it is > being used on the installer? > > > Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug.

Allan

So do I understand correctly...

*problem 1*: grub-gfx vs grub: We can fix the problem that grub-gfx instead of grub is installed if we just chroot I think. Eg: chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

But, this only affects 64bit right? or not? (because in my tests the grub didn't look very fancy..) If so, can someone with a 64bit (virtual) machine change the above line in /arch/setup and test it? If okay, someone with access to archlinux-installer can fix the line and repackage.

If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package.

*problem 2*: Gerardo says "grub-gfx fails", this is the same as Alexanders problem, right? ("I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly)").

IIRC Gerardo already tried the new package , tested it and confirmed that it works. So we just need to get it on the iso. See http://bugs.archlinux.org/task/13068

Dieter

Also, I went over all 2009.01 mails to see if we catched all issues. All of them are fixed or being handled right now, except one more grub related one posted by Gerardo: http://www.archlinux.org/pipermail/arch-releng/2009-January/000167.html quote: "And there is and error in tryboot.lst, it have a three fallback commands in menu entries, the fallback command is invalid at theses points, is only for "general section"

timeout 0 default 0

title Scanning for /boot/grub/menu.lst fallback 1 find --set-root --ignore-floppies /boot/grub/menu.lst configfile /boot/grub/menu.lst

....

" what is tryboot.lst? which fallback command? do you get any errors? or will this stuff be automagically fixed if we fix problem 1 and 2 from above?

Dieter

Hi Dieter No, this are unrelated to the problems 1 and 2 from above, and does not matter for the 2009.01 release. tryboot.lst is a menu entry in GRUB boot menu from the install CD marked as **experimental** and is located at "More options..." Because it contains semantic error (fallback command is not valid in the "title sections") When "enter" to this option grub shows: fallback 1 Error 27: Unrecognized command I will create a bug entry in Flyspray to track this and others issues in the boot menu from ISO. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Alexander De Sousa

9:52 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

On Sat, Jan 31, 2009 at 9:16 PM, Gerardo Exequiel Pozzi < vmlinuz386@yahoo.com.ar> wrote:

...

Hi, OK Now the problem is solved, i see a grub-install parameter useful :)

--grub-shell=FILE, with this override the use of the problematic /sbin/grub.

1) No chroot is needed. 2) Now the correct grub is installed at MBR/BOOT not the grub-gfx ;)

Patch is attached

-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

--- setup.orig 2009-01-31 18:12:15.000000000 -0200 +++ setup 2009-01-31 18:12:51.000000000 -0200 @@ -1081,7 +1081,7 @@ DIALOG --msgbox "GRUB root and setup devices could not be auto-located. You will need to manually run the GRUB shell to install a bootloader." 0 0 return 1 fi - $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 + $DESTDIR/sbin/grub-install --recheck --grub-shell=$DESTDIR/sbin/grub --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 cat /tmp/grub.log >$LOG # unfreeze xfs filesystems if [ -x /usr/sbin/xfs_freeze ]; then

That's it! That way grub is installed instead of grub-gfx, so... there is no other problem regarding GRUB, right? As the grub package available in the core repository is already patched to suport ext4 and big inode size. Anyway, that chroot line didn't work :(. But there you don't have to worry about it, use the --grub-shell parameter and everything will be ok. -- Alexander

Gerardo Exequiel Pozzi

10:07 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Alexander De Sousa wrote:

...

On Sat, Jan 31, 2009 at 9:16 PM, Gerardo Exequiel Pozzi mailto:vmlinuz386@yahoo.com.ar> wrote:

Hi, OK Now the problem is solved, i see a grub-install parameter useful :)

--grub-shell=FILE, with this override the use of the problematic /sbin/grub.

1) No chroot is needed. 2) Now the correct grub is installed at MBR/BOOT not the grub-gfx ;)

Patch is attached

-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar http://www.djgera.com.ar/ KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

--- setup.orig 2009-01-31 18:12:15.000000000 -0200 +++ setup 2009-01-31 18:12:51.000000000 -0200 @@ -1081,7 +1081,7 @@ DIALOG --msgbox "GRUB root and setup devices could not be auto-located. You will need to manually run the GRUB shell to install a bootloader." 0 0 return 1 fi - $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 + $DESTDIR/sbin/grub-install --recheck --grub-shell=$DESTDIR/sbin/grub --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 cat /tmp/grub.log >$LOG # unfreeze xfs filesystems if [ -x /usr/sbin/xfs_freeze ]; then

That's it! That way grub is installed instead of grub-gfx, so... there is no other problem regarding GRUB, right? As the grub package available in the core repository is already patched to suport ext4 and big inode size.

Anyway, that chroot line didn't work :(. But there you don't have to worry about it, use the --grub-shell parameter and everything will be ok.

-- Alexander Yes!, No other relevant problem for GRUB here. But maybe, a good choice, is that the final ISO (x86_64) include a patched grub-gfx (-11 revision) for rescue and other purposes.

-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

Alexander De Sousa

10:25 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

On Sat, Jan 31, 2009 at 11:07 PM, Gerardo Exequiel Pozzi < vmlinuz386@yahoo.com.ar> wrote:

...

Yes!, No other relevant problem for GRUB here. But maybe, a good choice, is that the final ISO (x86_64) include a patched grub-gfx (-11 revision) for rescue and other purposes.

-- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

That would be fair, although that parameter is the only thing needed for it to install and boot correctly the updated grub-gfx should be in (and it is likely to be in as the images have to be rebuild). What keeps me thinking about is... until now grub-gfx was always installed instead of grub? If... grub-gfx packages were both updated at the time of building the images this bug would possibly be hidden and never found. P.S.: It seems it will be a 2009.02 in the end... :( -- Alexander

Gerardo Exequiel Pozzi

8:16 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Dieter Plaetinck wrote:

...

On Sun, 01 Feb 2009 01:52:52 +1000 Allan McRae wrote:

...
Gerardo Exequiel Pozzi wrote:

...
Allan McRae wrote:

...
Gerhard Brauer wrote:

...
Am Sat, 31 Jan 2009 20:23:34 +1000 schrieb Allan McRae :

...
Would it be a good idea to move grub-gfx to [extra] if it is being used on the installer?

Hmm, abstain... First i wonder that we use a community package on/for installation sources, but it's only the grub-gfx package. So i have no problem belong this to community at all. (I also thought about maintaining a separate grub-gfx only for archiso...). I see the problem mainly on our testing procedure: this behavior must have be detected earlier - and not from a "beta tester"(Thanks Gerardo!), WE have had to detect this.... (I detect it on i686 and initiate that this got fixed. Myself (only i686) don't look if x86_64 was rebuild also....

Can someone clarify what package the grub being installed onto the users system is? From the problems here, I am getting the impression that it is the grub-gfx package.

Allan

Hi

In resume: * The package installed at: the root-fs of ISO is grub-gfx. the root of new user system $DESTDIR is grub, but... the MBR/BOOT of the new system is grub-gfx because $DESTDIR/sbin/grub-install (script) uses /sbin/grub (bin) and not $DESTDIR/sbin/grub (bin)

* Under x86_64 grub-gfx fails in ext2/3/4 FS since don't have latest patches that the i686 version have.

May be, a chroot to $DESTDIR and install grub from here with grub-install, or use the old method from 2008.06 that uses grub binary directly. Or another solution.

Thanks for the clarification. I was concerned about grub-gfx being installed to peoples systems by default but had not realized that this was because of a bug.

Allan

So do I understand correctly...

*problem 1*: grub-gfx vs grub: We can fix the problem that grub-gfx instead of grub is installed if we just chroot I think. Eg: chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

But, this only affects 64bit right? or not? (because in my tests the grub didn't look very fancy..) If so, can someone with a 64bit (virtual) machine change the above line in /arch/setup and test it? If okay, someone with access to archlinux-installer can fix the line and repackage.

If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package.

*problem 2*: Gerardo says "grub-gfx fails", this is the same as Alexanders problem, right? ("I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly)").

IIRC Gerardo already tried the new package , tested it and confirmed that it works. So we just need to get it on the iso. See http://bugs.archlinux.org/task/13068

Dieter

Hi, OK Now the problem is solved, i see a grub-install parameter useful :) --grub-shell=FILE, with this override the use of the problematic /sbin/grub. 1) No chroot is needed. 2) Now the correct grub is installed at MBR/BOOT not the grub-gfx ;) Patch is attached -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D --- setup.orig 2009-01-31 18:12:15.000000000 -0200 +++ setup 2009-01-31 18:12:51.000000000 -0200 @@ -1081,7 +1081,7 @@ DIALOG --msgbox "GRUB root and setup devices could not be auto-located. You will need to manually run the GRUB shell to install a bootloader." 0 0 return 1 fi - $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 + $DESTDIR/sbin/grub-install --recheck --grub-shell=$DESTDIR/sbin/grub --root-directory=$DESTDIR $ROOTDEV >/tmp/grub.log 2>&1 cat /tmp/grub.log >$LOG # unfreeze xfs filesystems if [ -x /usr/sbin/xfs_freeze ]; then

Pierre Schmitz

9:32 p.m.

New subject: [arch-releng] grub-gfx - Was: Dep cycles in core and 2009.01

Am Samstag 31 Januar 2009 20:52:34 schrieb Dieter Plaetinck:

...

If I understand correctly, this problem is unrelated to the "slightly outdated grub package" problem ( see http://bugs.archlinux.org/task/13068 ), eg if it were not for problem 2, we wouldn't need to update the package.

We should really use the same grub on both arches. There is no reason to not do so and the x86_64 grub-gfx cannot boot from ext4. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de

Dieter Plaetinck

10:37 a.m.

On Sat, 31 Jan 2009 11:18:09 +0100 Gerhard Brauer wrote:

...

Am Fri, 30 Jan 2009 22:16:57 -0200 schrieb Gerardo Exequiel Pozzi :

...
Ooohh! The grub-gfx installed at root-image-fs (x86_64) is the grub-gfx-0.97-7 (latest from community) and in i686 is 0.97-11. I tested compiling the grub-gfx for x86_84 sync to -11 version. copied with scp to installCD , pacman -U grub-gfx-0.97-11-x86_64.pkg.tar.gz

Oh, then the grub-gfx maintainer doesn't build also the x86_64 version :-( I wrote him in a bugreport FS#12616 to add ext4 support (and ext3 big-inode patch) to grub-gfx and the i686 version was rebuild fine with these changes.

...
And install grub like /arch/setup and now WORKS :)

FS#13059 is the new grub-gfx bugreport to fix for x86_64. Thanks Gerardo!

...
BTW: grub-gfx in ABS lack some patches, i copied all from ABS grub.

Yeah, i also saw this..

First i wonder about the grub-gfx problems you mentioned, cause grub-gfx and grub uses the same patches (and upstream source), only addition is the patch for splash support. And this should not prevent the bare installation of grub(-gfx). But with this version-differing the reason is clear. x86_64 ISO/images (RC1 candidates) should wait until grub-gfx's new version is available.

Created http://bugs.archlinux.org/task/13068

...

Gerhard

Dieter

Gerhard Brauer

12:43 p.m.

Am Fri, 30 Jan 2009 22:16:57 -0200 schrieb Gerardo Exequiel Pozzi :

...

Ooohh! The grub-gfx installed at root-image-fs (x86_64) is the grub-gfx-0.97-7 (latest from community) and in i686 is 0.97-11. I tested compiling the grub-gfx for x86_84 sync to -11 version. copied with scp to installCD , pacman -U grub-gfx-0.97-11-x86_64.pkg.tar.gz

And install grub like /arch/setup and now WORKS :)

Hmm, i looked how we call it in the installer, and it is: $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV

...

/tmp/grub.log 2>&1 DESTDIR is alread /mnt, so you never make use of grub-gfx in this part of the installer if your base installation have grub installed.

grub-gfx is only the bootloader on the Live-CD part of the ISO. On the installation system you should always get grub from core (package installation has not the ability to install grub-gfx to /mnt). Thinking further (my first reply to your mail was written with fewer coffees <g>): If you ran into this problem all testers of x86_64 iso/images should have the same problem. But i don't see other reports (But seems that only you tested the x86_64 versions...) Could please test some other the x86_64 ISOs and confirm that we have a problem there with grub? Gerhard

Gerhard Brauer

12:48 p.m.

Am Sat, 31 Jan 2009 13:43:38 +0100 schrieb Gerhard Brauer :

...

Hmm, i looked how we call it in the installer, and it is: $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV

...
/tmp/grub.log 2>&1 DESTDIR is alread /mnt, so you never make use of grub-gfx in this part of the installer if your base installation have grub installed.

Sorry, forgot my mail... grub-install is a shell script which calls grub, and so /sbin/grub (ergo grub-gfx's grub). Gerhard

Alexander De Sousa

12:55 p.m.

I've not had Internet connectivity until now, everything went ok too in real hardware: · Images used: -> archlinux-2009.01-beta3-ftp-i686-isolinux.iso 30.01.09 09:49 -> archlinux-2009.01-beta3-ftp-i686.iso 30.01.09 13:42 -> archlinux-2009.01-beta3-core-i686.iso 30.01.09 15:37 -> archlinux-2009.01-beta3-ftp-x86_64.iso 30.01.09 12:27 -> archlinux-2009.01-beta3-core-x86_64.iso 30.01.09 12:25 · Configurations: Same as in VMs. Issues corrected: - Texinfo and bash scriplets work using the last ones (when ftp ISOs and using a mirror already synced). - No more dependency cycles as consequence. Issue detected (not important): - If /tmp is separated to another partition: When mounting partitions it gets different permissions that the ones it should have (755 instead of 1777). It's shown to the user in form of warnings during install of the package filesystem: warning: directory permissions differ on tmp filesystem: 755 package: 1777 Anyway it's corrected. /tmp appears to have the correct permissions after installation (seen when mounted after rebooting). I'll try again x86_64 images and reply about the grub problem. I could reboot and enter the new installed system, I remember it clearly because I confirmed it was a x86_64 install (running "uname -m" inside the installed system). Though the machine in which it was installed already had the MBR of that disk altered to load grub from the boot partition (I tried i686 images first). I'll tell you if it works or not in some minutes. On Sat, Jan 31, 2009 at 1:43 PM, Gerhard Brauer wrote:

...

Could please test some other the x86_64 ISOs and confirm that we have a problem there with grub?

Gerhard

Gerhard Brauer

1:11 p.m.

Am Sat, 31 Jan 2009 13:55:17 +0100 schrieb Alexander De Sousa :

...

I'll try again x86_64 images and reply about the grub problem. I could reboot and enter the new installed system, I remember it clearly because I confirmed it was a x86_64 install (running "uname -m" inside the installed system). Though the machine in which it was installed already had the MBR of that disk altered to load grub from the boot partition (I tried i686 images first). I'll tell you if it works or not in some minutes.

That would be nice. As i know from the problems on i686 with the old grub-gfx 0.97-7 version it only affects on FS with ext2/3/4, cause it comes without the patch for bigger inode size on these FS. And all new created extX-FS are created with this bigger inode size. So would be nice if you could test it with ext-FS on /boot or /. Gerhard

Dieter Plaetinck

1:40 p.m.

On Sat, 31 Jan 2009 13:48:18 +0100 Gerhard Brauer wrote:

...

Am Sat, 31 Jan 2009 13:43:38 +0100 schrieb Gerhard Brauer :

...
...
/tmp/grub.log 2>&1 DESTDIR is alread /mnt, so you never make use of grub-gfx in this

Hmm, i looked how we call it in the installer, and it is: $DESTDIR/sbin/grub-install --recheck --root-directory=$DESTDIR $ROOTDEV part of the installer if your base installation have grub installed.

Sorry, forgot my mail... grub-install is a shell script which calls grub, and so /sbin/grub (ergo grub-gfx's grub).

Gerhard

Interesting.. would something like this be better? chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1 Dieter

Gerhard Brauer

1:55 p.m.

Am Sat, 31 Jan 2009 14:40:25 +0100 schrieb Dieter Plaetinck :

...

On Sat, 31 Jan 2009 13:48:18 +0100 Gerhard Brauer wrote:

...
Sorry, forgot my mail... grub-install is a shell script which calls grub, and so /sbin/grub (ergo grub-gfx's grub).

Interesting.. would something like this be better? chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

Not without further testing ;-) It's one step to enter a chroot, but a other to step out again (AFAIK the installer script looks for SUCCESS or similar in /tmp/grub.log, and which /tmp is affected? The chroot'ed or the ISO-root? These are things we should carefully research/fix for the next ISOs (> 2009.01) - either by complete (re)check archlinux-installer or on aif. Currently i think the best way for 2009.01 would be to fix the grub-gfx package for x86_64.

...

Dieter

Gerhard

Allan McRae

1:57 p.m.

New subject: [arch-releng] Changing subject lines: Was - Dep cycles in core and 2009.01

Any chance that people could change the subject line when the conversation changes topic. This is very hard to follow... Allan

Dieter Plaetinck

2 p.m.

On Sat, 31 Jan 2009 14:55:41 +0100 Gerhard Brauer wrote:

...

Am Sat, 31 Jan 2009 14:40:25 +0100 schrieb Dieter Plaetinck :

...
On Sat, 31 Jan 2009 13:48:18 +0100 Gerhard Brauer wrote:

...
Sorry, forgot my mail... grub-install is a shell script which calls grub, and so /sbin/grub (ergo grub-gfx's grub).

Interesting.. would something like this be better? chroot $DESTDIR /sbin/grub-install --recheck $ROOTDEV >/tmp/grub.log 2>&1

Not without further testing ;-) It's one step to enter a chroot, but a other to step out again (AFAIK the installer script looks for SUCCESS or similar in /tmp/grub.log, and which /tmp is affected? The chroot'ed or the ISO-root?

If you mean the redirection stuff ( > /tmp/grub.log 2>&1), that goes to the live one. bash will execute the chroot command with it's arguments, and redirect the output of it to /tmp/grub.log.

...

These are things we should carefully research/fix for the next ISOs (> 2009.01) - either by complete (re)check archlinux-installer or on aif.

Currently i think the best way for 2009.01 would be to fix the grub-gfx package for x86_64.

...
Dieter

Gerhard

Alexander De Sousa

2:44 p.m.

I'm afraid I confirm the grub bug. In x86_64 images grub isn't installed to the MBR of the chosen disk (when the boot partition is an extX, if it is reiserfs it works perfectly). I've tried both grub images (archlinux-2009.01-beta3-ftp-x86_64.iso 30.01.09 12:27 and archlinux-2009.01-beta3-core-x86_64.iso 30.01.09 12:25). I don't know if it would work using the isolinux-based images, if needed I can try those too. By the way, I forgot to mention the hardware used in testings: A laptop: 160 GB Seagate SATA, Core 2 Duo 7300, nVidia G-Force 8600GT, all mounted in an Intel motherboard. A desktop: I don't have it where I am right now, but it was a AMD powered microprocessor, an ATI graphic card, 320 GB HD and Asus motherboard with VIA chipset inside. All the tests took place in both machines but the x86_64 ones, that took place only in the laptop. -- Alexander.

Marcel Korpel

10:40 p.m.

Using archlinux-2009.01-beta3-ftp-i686-isolinux.iso, everything went ok. Real hardware. FTP-install using a (selfmade) USB-image with Syslinux, usbdelay=2 net0: Realtek RTL8111/8168B was automatically detected, every partition uses ext4 (/, /var, /var/cache/pacman, /usr, /home), except /boot, which resides on an ext2-partition, GRUB installed painlessly and booting into system went ok. Good night, and good luck, Marcel

5563

Age (days ago)

5565

Last active (days ago)

List overview

Download

49 comments

11 participants

participants (11)

Aaron Griffin
Alexander De Sousa
Allan McRae
Dieter Plaetinck
Gerardo Exequiel Pozzi
Gerhard Brauer
jonathan gustafsson
Marcel Korpel
Pierre Schmitz
Stephan Platz
Troy Ankersen