On Mon, Apr 29, 2019 at 05:31:15PM -0400, Paul Rogers wrote: > > kernel driver was missing. A little more investigating and I found that I'd > > mis-GRUBbed something and had booted Manjaro using my LFS kernel. Aside > > from the missing wifi module, at least I know I'd recompiled the kernel > > properly - I just put it in the wrong place. > > Go sit under a tree, spend some "skull sweat" and imagine a reliable process > of how you can manage a dual- or triple-boot environment, and then make up > scripts that will do it properly in each system. Don't try to "wing-it" > everytime! > Sorry if this reply offends, it is intended to be mildly humorous, and a change (for me) from swearing again about upstream poppler (I spent ages trying to build the svn version of what will be this year's texlive source, using its shipped poppler as we now do, and got nowhere): Unfortunately, I think that only luatex has stopped using poppler for 2019 TH - but since I can't build TL I can't confirm even that. And perhaps a longer reply than I originally intended.
I'm taking a break from my current experiments on tuning (I intend to tune almost every package in my normal desktop builds to use "optimized" CFLAGS, CXXFLAGS, and similar, at the moment I think I've worked out how to add my own flags to almost all compiles, one or two like, I think, unzip [ forces -O3 ] don't seem worth the effort, and then making sure all my logs are verbose. After that, on to the interesting options (which may turn out to be not worth the effort/testing) - Paul and Bruce will already think I'm a "lost cause" ;-) But you have to start with winging it, and eventually notice where there are problems and hopefully both fix, or work around, them *and* remember the symptoms when they recur. I'm not good at that last point, tried to build gstreamer-1.16.0 the other day, initially forgot to create the build directory (I thought I'd pasted that from my template, but I hadn't), then thought "oh, it needs .." when I got the errors. And then, when they still happened I went to look at the build tree and noticed there was a gst/ directory next to it. DOH! and slapped head. Learning takes time. > [Framebuffers] > > > > I don't know/don't remember. But I'll look into. Another nice tip. Although > > I really do want to get my mad-scientist experiments off my so-called > > "work" computer. > > What did you set in this last kernel build? Look in > /usr/src/linux-X.Y.Z/.config. My scripts, mentioned above, get me through > the kernel configuration bit, then ask me if I've changed my mind, then quit > before compiling if I answer "y". So I can check .config the regular way. > ;-) > For modern kernels, I think there might be a .config.old created when you run 'make menuconfig'. What really made me spend the time replying is '/usr/src/linux-X.Y.Z'. Next thing, you'll be telling me you build the kernel as root (yeah, ok, the book does for the first build, and I admit I build most packages as root). But /usr/src ? Next thing you'll be advocating /usr/local for BLFS. Oh, wait, you do, don't you. ;-) My point is that we each, if we continue to use LFS/BLFS, need to find methods which suit us as individuals. What works for one of us can be regarded as horrendous by another. > > > > It's also got to be legible on a wide variety of screens! :-) > > For this kind of kernel you want to use "bog-standard" VGA drivers, no extra > nothing! You DO NOT want to boot into the GUI so screen resolution is > irrelevant, this is for rescue operations! All you want is the command line > and access to the base system standalone. If you can do that then anything > is possible. If you can't, nothing is possible. > On laptops, you probably _do_ want to eventually build a GUI of some sort, and for that it is easiest to use the kernel's framebuffer, and KMS, from the start - to help you find what firmware is needed - I'm told that even intel (Skylake and later) now need firmware for KMS. On modern hardware (my ryzen laptop is 1920x1080 on a screen with a 40cm diagonal) the default fonts can be unreadable in many cases. The kernel has a 12x22 framebuffer font available, my variation of that is provided by kbd (the fact that debian and its derivatives do not use kbd is one of the reasons I'm reluctant to ever try them on real hardware). After that, as Bruce said, Terminus. Or perhaps video=1366x768 on the kernel command line if that is accepted (or 1280x720). More generally, starting with a distro kernel which works (and converting some things from modules to built-in) is a working, if tedious approach. And distro kernels for laptops (particularly for High DPI as was, I think, originally mentioned) will usually use KMS unless they are "server-only". Specifically, when booting a new system and using it to build a graphical desktop, it is *not* only for rescue operations. For modern UEFI systems, using a host system for rescue may be a far easier way of rescuing a broken BLFS first build. After that, of course, you use it to update BLFS and perhaps build grub-UEFI, and from then on you've got the old system to use for rescues - if you made backups, of course. > > > > Oh, and if the machine's CPU is not the same as, or a superset of, > > the machine on which you built LFS, you may need to rebuild gmp if > > you didn't use the configfsf scripts. And although I'm a fan of > > using '-march=native' in my CFLAGS, that is fairly catastrophic for > > trying to build for a different micro-architecture :) > > > > ĸen > > Ken's right, GMP is going to be a PITA. But RTFM, there are ways to build, > i.e. crosscompile, it for a lowest common denominator CPU. I always do, > because the marginal performance improvements are worth less to me than the > ability to use any hardware in an emergency! > > > > > This might be part of my problem. My initial LFS build was constructed on a > > Core i7. The machine I want to continue LFS'ing on is only a Core i5. I > > Been there, done that. The problem is, sometimes you might get away with it, > sometimes not. IMO it's not worth the hassle of an optimized GMP. But then > my RoT is: I'm not interested in any "better performace" trick or upgrade > unless it's nearly 100% faster, and that hardly happens these days. Back > when I started with a 2MHz 8080, it was easy! > I understand that, *I'm* hoping mostly for faster, or smaller, builds (dropping -g from CFLAGS on packages which do not strip will at least help a little bit for size). But 5% faster, if repeatable, and added hardening (if things don't break - at least firefox/thunderbird and qtwebengine both use -UFORTIFY_SOURCE to turn it *off*) would be worthwhile. And it is all learning, which is what we are primarily about. > > Regardless, this (older, i5) machine has a fresh Manjaro install and I'm > > starting LFS over, using the development branch this time around. I know > > the risks and hazards and further complications that may entail, but > > breaking and fixing things is my definition of "fun". > > NOOoooooo! You don't break and fix things until you've got it working. Spoilsport! ;-) > > > important question is: when I get this version booting and running, do I > > get to be Counted a second time? :-) > > Also NO. > > And now I'll go back to adjusting the flags in my buildscripts, to scratch my itch. In theory, Arch and gentoo take efforts to ensure their own || the user's CFLAGS, CXXFLAGS, LDFLAGS get used. Sometimes, what they do for CFLAGS or CXXFLAGS works (no idea about LDFLAGS), other times it appears not to. Using CFLAGS="..." ./configure, or CXXFLAGS=, or sometimes 'sed -i "s/-g -O2/$CFLAGS/" seem to be my new-found friends ;-) ĸen -- With a few red lights, a few old bits, we made the place to sweat. No matter what we get out of this, I know, I know we'll never forget. Smoke on the water, a fire in the sky. Smoke, on the water. -- 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
