UEFI, win8, x86_64 musings

"win8" laptop
I mentioned recently that I bought a "win8.1" laptop for someone who lives in a country town.
I have had to hand it over, and she is happily using it. That town is Carnarvon, and we did the tourist thing, visiting Shark Bay and Monkey Mia. Other places too, such as the big dish that was used to track the first moon landing, banana plantations, the "blowholes" just north of Carnarvon.

Wonderful climate in Carnarvon, warm but with an incredibly strong and cooling sea-breeze every day.

So, are my UEFI-booting experiments at an end? Perhaps I should buy a small "win8" laptop for myself. Problem is, I am quite happy with my current laptop, in one respect it is throwing money away just to buy a laptop for Quirky Linux booting experiments. Will think about it.

x86_64 Quirky
I decided to add the functionality to the Quirky build system, to build a x86_64 Quirky Unicorn. Which I then did, and right now have come to a dead stop.

When I get to the point where the 'rootfs-complete' is created and a 'chroot' is performed, I can do a successful chroot, but only because busybox is statically compiled. None of the dynamically-linked programs work. I am doing this chroot from a running Fatdog64 or Slacko64.

If, for example, I try "chroot rootfs-complete /bin/bash --help", I get the message that bash is "not found". This very obscure message has to be the most obscure one that the developers of the dynamic linking mechanism could dream up. It can hide a variety of problems.

Everything is setup correctly. 'ldconfig' has been run, /etc/ld.so.conf has the right paths in it. All libraries are present. The most likely problem is a library mismatch, which should not be, as I have used only the official Ubuntu x86_64 DEBs for this initial build.

But anyway, I did some testing. I compiled 'binutils' statically in Landley's Aboriginal Linux x86_64 root filesystem, which has the utilities 'readelf' and 'objdump'. What I was looking for was an ABI-mismatch, that it, 'bash' wanting say libc.so.6 with "GLIBC_2.3" compatibility. But, no problem there.

So, the "not found" problem is a complete mystery to me. I'll give it a rest for a day or two.

I could of course use Rob Landley's excellent root filesystem to compile more packages statically, to be able to perform most console operations after chrooting into rootfs-complete, but that is only postponing the problem.

Oh, yes, that Aboriginal Linux -- Rob has gradually replaced the Busybox applets with Toybox applets, however I have found that to be unsatisfactory. To compile 'coreutils', the Toybox 'rm' and 'ls' were inadequate. I had to compile Busybox and point rm and ls to it.

---

Comments

Ha ha ha ha

How many days have I been working on this? ...three or four.

My speculations got wilder, but this evening I got to thinking about how chroot works, and the architectural differences between Fatdog64, Slacko64 and my QU64.

A simple chroot operation inherits many things from the parent. It suddenly dawned on me that it probably does not care about my /etc/ld.so.conf and associated ldconfic caches inside rootfs-complete -- instead it inherits the paths from the parent.

For the libraries, they are /lib64 and /usr/lib64 in Fatdog64 and Slacko64. Whereas QU follows Debian/Ubuntu multiarch structure and the libs are in /lib/x86_64-linux-gnu and /usr/lib/x86_64-linux-gnu.

The solution is simple:

# cd rootfs-complete

# ln -s lib/x86_64-linux-gnu lib64

# cd usr

# ln -s lib/x86_64-linux-gnu lib64

<

That's it, the incompatibility between Slacko64/Fatdog64 and QU64 is now fixed, chroot works, the dynamic utilities now work.

I built QU64, entirely from Ubuntu DEBs, except for one busybox PET, and it boots. I get to the commandline only, as X apps such as JWM and ROX-Filer are missing.

I installed it, and the "devx" PET, and attempted to compile 'bash'. But, got a configure error, that the C compiler is not working.

The 'configure' script creates a little test program, 'conftest.c'. Well, I created that separately, and tried to compile it;

# gcc conftest.c

/usr/bin/ranlib: conftest.c: File format not recognized

<

I have been looking around for information about this, the light has not come on yet.

Tags: linux