Red Hat Bugzilla – Bug 31192
Bootstrapping issues with RC2 anaconda
Last modified: 2015-01-07 18:44:29 EST
The following was actually reported by H.J. Lu on the beta-team mailing
list. Erik Troan believes this is a must-fix (show-stopper) for the
========= Begin except from H.J. ==========
Does RedHat do bootstrap with distribution build? From the zlib
problem, I can tell at least anaconda is not built against the new
distribution. Anaconda built on RC2 doesn't work. It cannot insmod
any kernel modules during the first stage. The same anaconda built
on RC1 works fine. My guess is some packages used to build anaconda
are broken in RC2. Unfortunately, I only have one machine to work
with. I have to use it for build as well as test. It will take me a
while to figure out which packages are broken.
Follow-up from the beta-team mailing list:
=========== email@example.com writes: =============
The cration of the installer image extracts the files from the
packages in the current tree, so "yes".
More follow-up from beta-team mailing-list
========== H.J. replies: ===========
I was talking about the anaconda rpm IN your current tree. I don't
think it is built against your current tree. It is a chicken and
egg problem. That is why I said "bootstrap".
BTW, I relinked loader, compiled on RC1, on RC2. It seems to work. It
indicates the .a files are ok. Since glibc is unchanged from RC1 to
RC2, I suspect gcc and/or kernel header files are broken in RC2. I
will track it down tomorrow.
------ Alan's response ------
Sorry. The syscall macros in the kernel are not for userspace. Any app
depending on kernel macros is wrong. I think you can expect the Linus tree
to do something similar at some point
That is not a bad thing by itself. But those user space programs should
be fixed first. At least you should protect them with #ifdef __KERNEL__.
BTW, I have been telling everyone to use syscall () in glibc. But ...
I even submitted a patch to glibc to remove the support for _syscall
2000-09-29 H.J. Lu <firstname.lastname@example.org>
* sysdeps/unix/sysv/linux/ia64/sysdep.S (__ia64_syscall):
But it is still there.
Here is a patch I proposed. I will send patches for anaconda and modutils
--- 1 Fri Mar 9 09:11:42 2001
+++ /usr/include/asm/unistd.h Thu Mar 1 16:21:40 2001
@@ -228,8 +228,6 @@
#define __NR_getdents64 220
#define __NR_fcntl64 221
/* user-visible error numbers are in the range -1 - -124: see
#define __syscall_return(type, res) \
@@ -317,8 +315,6 @@ __asm__ volatile ("push %%ebp ; movl %%e
"0" ((long)(arg6))); \
-#endif /* __KERNEL__ */
It turned out it was quite hard to get rid of all the usage of _syscall in
the user programs. You can try my patch to asm/unistd.h and rebuild all the
rpms. You will see many failures.
This defect considered MUST-FIX (show-stopper) for Florence Gold
this is a glibc issue, AFAIK.
anaconda itself is fixed now (at least, it should be...)
2.4.2-0.1.28 (when we build it...) should have this fixed, I think.