On Wed, Oct 15, 2014 at 01:51:28AM +0800, Роберт Киммель wrote: > > On 15/10/14 0:54, Bruce Dubbs wrote: > > No. There is no arch/x86_64 directory, even on a 64-bit system in the > > standard LFS build. Also, if it were the problem, you wouldn't have > > gotten far enough to to get it to search for /sbin/init (unless it is > > a 32-bit kernel). I'm not sure about CLFS though. > > > > The CLFS instructions refer to an arch/x86_64 directory, and it looks > like I must have created one, judging by the scripts I used. >
[ Coming late to this thread ] arch/x86_64/boot in the kernel tree is a symlink to keep the old debian installer working. It was added just after the unification of the x86/x86_64 architectures. > Within the 32-bit system, I just compiled a kernel, and (as you said), > there is no arch/x86_64 directory, just arch/x86. My build scripts copy > the .config file (renamed) to the /boot directory, and I just had a look > at the .config file from my attempt at a 64-bit build, and, there it is, > about line 5 of the .config file, the 64-bit option is not set. > > So it looks like it is possible to build a 32-bit kernel from within a > 64-bit system, and it also looks like that's what I did :( > That happens if you build multilib, it can also happen with a 64-bit kernel and 32-bit userspace. > I tried to recompile with the 64-bit option set, from within my 32-bit > system, and that produced an error. So it looks to me like 64-bits can > build 32-bits, but 32-bits can't build 64-bits. (I did check multiple > times during the build of my partial CLFS that I really was building a > 64-bit system, and "uname" told me I was. Just as a double-check, the > executables from my 64-bit build don't work when I try to execute them > from within my 32-bit system.) > > So I guess I have to figure out how to cross-compile the kernel only, or > rebuild my partial 64-bit CLFS, so I can then build a 64-bit kernel. > For the kernel (only) cross-compilation is comparatively easy (see below). > > No. You have to start with the architecture you are running with. You > > probably want to divide up the partition so you have extra space, but > > you didn't list your partitioning so we can't give a good recommendation. > > > > I have one quite large ext4 partition, which has my 32-bit LFS. There > is also a much smaller ext4 partition, which is big enough to hold a > working LFS, but may not be big enough to compile one (about 60% full > with a bare-bones LFS in it). This smaller partition currently has my > non-functioning attempt at a 64-bit build. > > So if I can't figure out how to cross-compile a 64-bit kernel from > within the 32-bit system, I guess I'll have to tar up the broken 64-bit > system, build a 64-bit partial CLFS in the smaller partition (again), > and compile a 64-bit kernel in that partition. (Or just pinch the CLFS > kernel.) Then tar the CLFS system up, move the tar file to the big ext4 > partition, and untar the broken 64-bit LFS into the smaller partition, > move the newly compiled and hopefully working kernel into that > partition, and see whether it boots. > > I'm really wishing I hadn't accidentally deleted my tarred up half-CLFS :( > > OK, thanks for the advice. Unfortunately not physically present with > the machine for another week. I'd like to chroot into the 64-bit > system, and build DHCP, openssl, and openssh, but the chroot doesn't > work, since it is a different architecture than the currently > functioning system . . . > > Thanks again. > > РК I will suggest that you should prioritise saving the files, and repartitioning (from a live disk - SystemRescueCD works well enough for me, although on some of my boxes a recent version did not have a working network which was "interesting" - most of my backups are on nfs. For building new systems, having several partitions for '/' gives more options for rescue, and for trying things out. After that, build a 64-bit kernel. The instructions are essentially the same as LFS binutils pass 1 and gcc pass 1, but with --target=x86_64-unknown-linux-gnu. Use a special prefix to keep them separate from your normal tools, e.g. /opt/gcc64. In the kernel, you need to cross-compile - ensure the new gcc and ld are on your PATH and then 'make CROSS_COMPILE=something- menuconfig' or whatever. The 'something' will be the name-prefix of the new gcc and ld, I do not have any real cross-tools areound to check. Pass it for each step of the build, including modules_install. Remember to select the option to let it execute 32-bit programs. That new kernel ought to be able to let you build a new system, but caution: if uname -m is x86_64, programs you build on the host system might thing they are on x86_64 and fail to build because the toolchain is actually i?86. This is the reason for 'linux32' and 'linux64'. It should also be able to boot the new system. Whether that system is 64-bit or 32-bit is a different question. I can vaguely remember doing all this several years ago, but I no longer have any notes on exactly how I built my first 64-bit system. There was a hint, but it seems to have disappeared and in any case so much has changed since then. All I can do is wish you well. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
