Karanbir Singh wrote:

Aleksandar Milivojevic wrote:

...

As subject says. I just noticed that Anaconda allows x86_64 CD/DVD to be used to install i386 system (using network installation, of course).

errr... you mean its installing i386 packages from the x86_64 media ? I find that very hard to believe......

...

This is basically broken. For example, yum will believe that it is installed on x86_64, not on i386. So when you do for example yum update, it will try to install x86_64 packages on i386 system. Which

errr.. no it wont. take a look at how yum decides arch...

...

isn't going to fly, since installed kernel is 32-bit (so you get broken executables). It can also play havoc with postinstall scripts that will detect they are being run under 64-bit kernel during installation, but resulting system is really 32-bit.

Can you provide some details on howto reproduce this ? a copy of the 3 files in /root from postinstall would be nice. maybe post them somewhere online and a url here.

Sorry, I should have been a bit more detailed.

Let say the tree on my install server looks like this:

/centos/os/i386 /centos/os/x86_64

If I use x86_64 media to boot, but by mistake in ks.cfg file I had something like:

url http://installsrv/centos/os/i386

Anaconda will happily install from i386 tree. All the packages on the system will be i386. However, $basearch in yum will expand to x86_64. First time you do "yum update" your system will be basically broken (yum will install 64-bit binaries on something that is basically 32-bit installation).

Quoting Johnny Hughes mailing-lists@hughesjr.com:

Well ... trying to prevent that would be way to difficult as i386 things are valid to install on x86_64. In fact, fixing it would be breaking it :)

Shouldn't it be the same as not allowing 4.2 media to be used to install from 4.3 tree? If it is able to check the version, it should be able to check arch too.

Some people want to install things outside the x86_64 tree ... specifically to get things like i386 Firefox, for example. They include items from the i386 tree on purpose ...

No problem with that. They are basically installing from something that is x86_64 tree, and have either some additional i386 stuff in it, or adding additional stuff from some other tree. They are not installing from something that is basically (copy of) i386 media.

But there is still slight problem with what I just desribed, when you are actually installing i386 system, but you started installation using x86_64 media. This is basically broken, and Anaconda should complain. Or at least it should detect that and conclude you are installing i386, not x86_64 (which might be complicated to implement). On the first update, yum will install (not update) anything it thinks needs to be updated. For example, one of the first things you'll notice is that "vi" is not working anymore (there's no update for vim, but x86_64 has "higher" version of vim-mininal than i386 does). So you end up with two vim-minimal packages installed in parallel, with later (x86_64) overwriting the former's (i386) files. Since kernel is from i686, obviously things ain't gonna fly.

An alternative way of fixing this is if yum would actually check what kernel is running, and set $basearch based on that. That would basically prevent installation of 64-bit binaries under 32-bit kernel (which can't run them). Either that, or hacking yum to include internal dependency that all 64-bit packages require 64-bit kernel.

The only reason you have an error is that not all those items are in the x86_64 tree on centos. If you had your own modified repos to include all i386 stuff and not just what the upstream provider (and so we) include, it would work fine.

Actaully, it wouldn't. If installing from i386 tree, you'd get i586 or i686 kernel. When yum runs, it will prefer to install x86_64 (even if previous version of package was i386, like in vim-minimal example above). So it won't work. It will basically break the system.

Quoting Karanbir Singh mail-lists@karan.org:

Aleksandar Milivojevic wrote:

...

Let say the tree on my install server looks like this:

/centos/os/i386 /centos/os/x86_64

If I use x86_64 media to boot, but by mistake in ks.cfg file I had something like:

url http://installsrv/centos/os/i386

Anaconda will happily install from i386 tree.

no it wont. try it, really.

Actully, it works. Try it. Really. I just did it. And did it once again just to make sure it really works. It works. Anaconda is not complaining. It should. But it doesn't.

at buildtime a timestamp and a session stamp are inserted into both ends of the side for a network install. unless they match - you cant install anything. you cant even use a boot.iso from a different build cycle against a different tree, even in the same arch...

You mean the first line of .discinfo? Seems to be ignored. At least with 4.3 media. I built my DVD from CD images using mkdvdiso.sh script.

so, umm.. how did you achieve this :)

As I said. I had "url --url http://installsrv/centos/os/i386/" in my ks.cfg. I forgot to replace i386 with x86_64. I booted off x86_64 DVD intending to install x86_64. And it "worked". It shouldn't have worked. But it did. Try it. It installed from i386 tree. As if I booted from i386 DVD.

After installation it all booted fine, as if I did i386 install. But somehow yum believes this is x86_64 installation ($basearch expands to x86_64 in yum config files). Bad things happen when installing/updating via yum (can't run 64-bit binaries under 32-bit kernel). Plus, yum is *installing* (as in "rpm -i") x86_64 packages when I do "yum update". Creating a total mess in the system.

On Thu, 2006-05-04 at 09:03 -0500, Aleksandar Milivojevic wrote:

Quoting Karanbir Singh mail-lists@karan.org:

...

Aleksandar Milivojevic wrote:

...

Let say the tree on my install server looks like this:

/centos/os/i386 /centos/os/x86_64

If I use x86_64 media to boot, but by mistake in ks.cfg file I had something like:

url http://installsrv/centos/os/i386

Anaconda will happily install from i386 tree.

no it wont. try it, really.

Actully, it works. Try it. Really. I just did it. And did it once again just to make sure it really works. It works. Anaconda is not complaining. It should. But it doesn't.

...

at buildtime a timestamp and a session stamp are inserted into both ends of the side for a network install. unless they match - you cant install anything. you cant even use a boot.iso from a different build cycle against a different tree, even in the same arch...

You mean the first line of .discinfo? Seems to be ignored. At least with 4.3 media. I built my DVD from CD images using mkdvdiso.sh script.

...

so, umm.. how did you achieve this :)

As I said. I had "url --url http://installsrv/centos/os/i386/" in my ks.cfg. I forgot to replace i386 with x86_64. I booted off x86_64 DVD intending to install x86_64. And it "worked". It shouldn't have worked. But it did. Try it. It installed from i386 tree. As if I booted from i386 DVD.

After installation it all booted fine, as if I did i386 install. But somehow yum believes this is x86_64 installation ($basearch expands to x86_64 in yum config files). Bad things happen when installing/updating via yum (can't run 64-bit binaries under 32-bit kernel). Plus, yum is *installing* (as in "rpm -i") x86_64 packages when I do "yum update". Creating a total mess in the system.

As I said before ... you CAN install i386 packages to an x86_64 system ... so what you did is valid.

It is still an x86_64 machine and it still thinks you want it to be an x86_64 install.

If you use real media to boot (and not boot.iso) it will allow you to install from a newer tree, that is by design. You can also install i386 packages from x86_64, that is also by design.

You shouldn't do an install in this manner, because it is broken ... however, you could choose to do it. Anaconda is flexible to allow you to do this ... it would not install ia-64 packages (for example) in this way, nor will it install x86_64 packages on an i386 install in this way.

What you are asking it to do is valid ... you can install i386 packages to x86_64 ... so the system assumes you know what you are doing.

On Thu, 2006-05-04 at 11:23 -0500, Aleksandar Milivojevic wrote:

Quoting Johnny Hughes mailing-lists@hughesjr.com:

...

You shouldn't do an install in this manner, because it is broken ... however, you could choose to do it. Anaconda is flexible to allow you to do this ... it would not install ia-64 packages (for example) in this way, nor will it install x86_64 packages on an i386 install in this way.

What you are asking it to do is valid ... you can install i386 packages to x86_64 ... so the system assumes you know what you are doing.

I'm not really sure if this logic is good. If installation is done from "specially designed" x86_64 tree. Sure, fine, whatever. The user obviously knows what he is doing. However, if installation is attempted from pure i386 tree, I beleive it is better to complain (since in all probability, this is not what was intended). Especailly since it is trivial to check what tree is used (second and third line of .discinfo).

I agree that this is probably true. If there are only i386 packages, it is most likely an error on the part of the person doing the install.

Or alternatively, the installer should conclude intention was to install i386 distro (even if booted from x86_64 media) and configure things accordingly. If intention was to install mixed i386/x86_64 system (which I totally agree is perfectly legal), person installing it sure isn't going to point Anaconda to something that screams "I'm i386-only tree". She's going to point to something that says "I'm x86_64 tree", and than customize it by replacing/adding i386 components.

I do not disagree with you ... but anaconda doesn't normally validate the repo, it just installs stuff. If it can meet all it's dependencies, it is perfectly happy.

That might not be a good thing.

In all likelyhood, this type of installation will be encoutered only in this two cases:

• typo in ks.cfg (points to wrong tree)
• sysadmin really wants i386 installation, but doesn't have i386 boot CD

Also, the yum should really be fixed. If I have i386 package installed, and it detects x86_64 version of package is newer (but there is no corresponding newer i386 package available), it shouldn't install x86_64 package (since I know what I'm doing, right?). At least not if my kernel can't run x86_64 (it doesn't help that my hardware is x86_64).

For example, this happens with vim-minimal package. If you look into base repository, there's vim-minimal-6.3.046-0.40E.7.i386 and vim-minimal-6.3.046-0.40E.7.centos4.x86_64. Yum will decide the later is "newer" (because of centos4 string), pull it, and install it (overwriting, not replacing the i386 package).

You are correct ... that should not be an update for the i386 package and I can verify that is indeed doing that.

You are also correct that it installs an unusable system. If you try to install any x86_64 packages they fail ... as they need a basic set of x86_64 items already installed.

This is an issue that would have to be addressed upstream.