First I want to see if I get any freezes while building the new LFS out of my existing one. If this is a hardware fault, it is unlikely to be confined to Slackware! Installing lmsensors is an excellent idea, though I don't think an overheated environment is likely to be the problem, as the machine stands free on the floor with space all around it, well away from the radiators. The floor is carpeted but I never heard of a computer that had a ventilation grill in the bottom! Most of the heat should be coming out of the back, and there is about a foot of space between that and the wall.

I am not very happy about switching the boot method between uefi and legacy. That is generally not recommended as it is rather easy to forget to switch back. But when I have finished the LFS build with all its downloads, I shall once again have some free bandwidth. I have 3 GB per month, starting each month on the 19th. And with fewer systems now, I use a lot less bandwidth in updating. I've noticed that Slackware has very few updates compared with Debian or Crux. The memtest site recommends a usb drive of ">1 GB" for the full uefi version, which means between 1 and 2 GB. I can accommodate that as a one-off.

Sounds like a proper plan

my Ryzen 7 PC just went to the great desktop in the sky, it would randomly crash it would not lose power but the keyboard & mouse would just no longer respond and it would do it as often as twice a day, sometimes three times a day and on a good day only once a day, it did it with every distro i would put on it with every possible desktop, i changed video cards, i changed harddrives, i changed RAM sticks, i finally gave up trying to figure it out and remove the hard drives and video card and RAM sticks, then took it to the recycle bin downtown, my next PC is just going to have to be a boring old intel i5 quad core and hopefully it wont randomly crash,

Actually my cpu has a bad vibe too. When I was building gmp (which optimises itself for your particular cpu rather than just for the general x86_64-pc architecture), it identified my machine triplet as silvermont-pc-linux-gnu. I looked it up and found that Intel Silvermont processors have a history of going bad and sometimes failing to boot altogether. But so far no problems on lfs, and I've already done a very cpu-heavy job testing gcc.

got a new desktop PC, its a Dell Optiplex 7010-T and seems to run good, it came with 1 terabite hdd and win10 on it those spinning platters with win10 is slow as molasses in winter, so i updated win10 then pulled the drive out and set it aside just in case i need it later, then put in a 250 gig ssd and installed a fresh copy of Linux on it (slackware64-current)

so far so good,

Attached Thumbnails

 

I have now built a complete new LFS from my existing one without any freezes whatsoever. This involved some heavy-duty compiling (including gcc and kernel) so it probably hammered both the memory and the disk drive.

I did it all using Xterms rather than virtual consoles because all but one of my Slackware freezes have been in X. So it really looks as if the problem is in Slackware itself, I assume either X or the kernel, since those are the only programs that talk directly to hardware.

I notice that X in Slackware uses the Intel i915 driver whereas my LFS uses the modesetting driver. Do you think that could be anything to do with the problem? I have an Intel Silvermont J2900 4-core processor, apparently with the graphics included within it.

PS: I just installed lm_sensors and ran the sensors command. It showed that my processors are running at 33 degrees C, well within limits. 105 deg C counts as high.

Had you ever checked dmesg for errors about "bios bug"? Most Ryzen issues with instability and linux aren't actually instability, it's bios not completely enumerating the hardware to the kernel.

I think the different graphics driver or configuration of that driver could very possibly be an important issue, maybe even THE issue for your freezes. I've recently read about some earlier kernels i915 and some bug it had that has been cleared up in newer kernels. I wish I had gathered enough to tell you more but the upshot is you might want to add the latest kernel from Current as a boot option to see for yourself.

That said, it is my understanding that "modesetting" is not the driver but a switchable attribute of most graphics drivers, so you likely need to dig a bit deeper for what driver (and possibly firmware blob) is being utilized. Sorry I can't offer more but I have never stayed for more than a month or two on an Intel GPU. FWIW I always buy and use nVidia and disable modesetting in LILO (with append = "nomodeset") for at least the first boot after blacklisting FOSS Nouveau. This is just to insure a readable screen by these old eyes. After that I comment out that line and hard set "vga = 0x034c".

It would likely be fun as well as informative to use an app like KCompare (a 2-window graphic for "diff") to look at the respective working /boot/config files from LFS and Slackware to see any obvious differences in kernel configuration since I can't see how anything but the kernel options and/or version could be the issue. You have already noted that X or the kernel are at fault and my money is on the kernel.

Regarding temperatures, although my take from a lifetime in Electronics is "Heat...BAD!" and if I ever saw a CPU temp of 60C or above I'd shut down and see what was the matter, 33C is very good. However the nature of digital electronics these days is that the actual sources of heat (other than the widespread heat of the PSU) are primarily many, nearly and actually microscopic points. The more obvious hard-working chipsets have heatsinks or "spreaders" to present a greater cross section area to airflow to remove thermals. IIRC the last PC I built that didn't have a case fan was a 486 but many people don't obsess about heat as much as I do and that's fine in my book as long as you know for certain you have good airflow even if it is only from convection.

One of the reasons you have a nice 33C CPU temp is that if I understand correctly the PSU is an external "power brick", but that also mean your case lacks the exhaust fan that come with almost every responsible internal PSU. 33C isn't even as hot as the Australian Outback but we can feel it as it is likely a degree or three above ambient. The first test is simply to feel for moving warm air near the top of your tower case. For a glimpse into how obsessed I am, when building my PCs I use a form of "smoke" to be able to see airflow and dead spots in my cases.

Since LFS has worked fine thus far the thermal issue seems reasonable so there is little need for you to be similarly concerned with airflow. After all that mobo was presumably used in actual laptop enclosures successfully, but I thought you might enjoy knowing a little more about temps and airflow importance in PCs. FWIW higher temps risk errors long before risking physical damage but in that you seem reasonable safe.

Find out what kernel version and specific graphics module LFS is using and possibly compare the config options and/or upgrade the kernel in Slackware. That will in all likelihood fix your Slackware freezing issues.

Best Wishes

I did think about comparing the kernels, but I don't know any practical way to do it, given that Slackware uses a generic stock kernel and LFS a hand-rolled minimalist kernel designed to be used without an initrd. The differences between the two configuration files would probably fill a book! I suppose I could import the LFS kernel into Slackware and see if it makes any difference to the behaviour of the system, but it would be hard to tell, given that the freezes are only occasional. Switching Slackware's video driver to Modesetting should be simple enough; it's just a matter of popping a file into /etc/X11/xorg.conf.d.

My computer has a circular grill at the back which I assume belongs to the power unit fan. I have seen similar grills in every computer I have had. There is also a kind of grid along the left side which I have not seen before. I don't know if it's for cooling or for sound. I know so little about hardware!

PS: neither feels warm to the touch.

Hi hazel
Yes there are lots and lots of kernel options and the differences may indeed fill a book but you can narrow that field a great deal. Unless you encrypt your file system(s) the only compelling reason to have an initrd is to load the filesystem module (commonly ext4) very early in the boot process. Obviously choosing the "built-in" option as opposed to "off" or "on-demand loadable" solves that much simpler than initrd so you can ignore or do what you will with that difference. It has no bearing on freezes. Far more likely is either CPU Type and Timing (I'd read that whole section as it isn't very long and it is extremely informative). The other high likelihood is in graphics drivers. That may be affected for your hardware by kernel version but I still don't know if you have verified that both are using the "i915" module or not. That should get verified. Modesetting might possibly be an issue but I don't know much about it as I don't really utilize it.

Regarding thermal design am I incorrect about your PSU? Is it not just like a laptop/notebook power brick with house current at one end and a specializeed connector on the other?... or is yours simply a power cable direct to your tower (no "brick") ? Further ibehind the circular grillworks is there a fan? If there is a fan then you are golden whether you have a brick or not... just something to force the air to move besides mere convection.

Ah but I've changed a lot more than building in the filesystem! I've stripped out all the drivers that I know I don't need and built in things that I know are essential but that are usually compiled as modules in stock kernels (e.g. usb controllers, ethernet driver). The result is a kernel that loads in half the time a generic kernel takes.
I can certainly cross-check those two sections. Also any setting which includes the string "INTEL".
Yes, it has an adaptor. First desktop machine I've ever used that had one. All my previous ones used a standard kettle flex.
I've no idea. I haven't opened it and frankly I don't want to!

That is certainly commendable but the point was that an initrd is not required. You can choose with or without with no problems as long as the most basic requirements are managed in one way or another. FWIW I grew up much like it seems you did where it was a sign of prowess (not to mention performance) let alone a point of honor to create as tiny a kernel as possible. It is my understanding that in digital, when an instruction is needed from the kernel, the entire kernel must be scanned, so it is constantly being accessed in toto, thus the advantage of tiny. However I'm not certain this is still true, so I'm curious as to how you measure kernel load time.... simple boot time? This is a side issue but one I am a bit curious about.

The main thrust is that it shouldn't be difficult to compare the two kernels since you already apparently know what you need and what you don't need.

OK it is as I've read, a true notebook system simply mounted in a much more expansive case. It is entirely possible that the case is somewhat generic where there is a "cut-out" for a PSU or other fan but none is installed. You wouldn't need to open the case to verify. A flashlight should reveal its existence to your eyes since the grille is literally bolted to the fan if one exists. The fan blades are quite visible at such short distance. Also, if a fan exists and is connected to power and working, then one should feel air flow, so either way one can determine if the box is active or passive.

I'm guessing this is a rather minor point since assuming the mobo worked reasonably well in a tiny notebook case it should work even better in an expansive one. The only possible issue I can imagine is that in a small case both convection and active fan push can only create airflow close to everything on the board whereas in a large case dead spots are much more likely. As I've said I am rather obsessed with such things so I would just have to know for certain, but it is somewhat doubtful this is any concern for your new boxen.

I fully agree that the kernel is most likely the first place to look for freezes. There is nothing particularly radical (quite the opposite) in anything in the Slackware distro on top of the kernel that has any likelihood as a fault at all.

You were right, enorbet. There is no fan in there and no power unit either. I assume the actual power unit is that external "brick". I still don't know what the grid along the side is for but it feels cool to the touch so it is probably for sound.

I have replaced the Intel Xorg driver by the modesetting one and so far I have had no further freezes. But it is such an occasional thing that you really can't prove that anything works. You have to wait until you get a freeze and then you can say, "Well that does not work!"

If I do get another freeze, then I shall need to try a different kernel. Trying to compare kernel configurations between Slackware and LFS is hopeless! Even within the few sections you suggested, there are way too many differences. So the options are to install the Slackware-current kernel (simple) or to build the kernel that LFS 8.3 uses with the Slackware configuration (a little more complex). And then more watchful waiting.

Or of course I could just use the LFS kernel as is. But I am reluctant to do so because I gather that the kernels of major distros are usually tuned to work optimally with the rest of the software.

AFAIK Slackware kernels are not "tuned". They are vanilla. Assuming the LFS kernel is also vanilla I would have to try it for Slackware. zSince it is possible to simply copy over the appropriate files and add a stanza to /etc/lilo.conf to add, not substitute, a menu option there is no downside beyond not working and having to reboot. FWIW I have even used Slackware Install media recovery method with huge.s to recover numerous distros, including a few that use systemd. In the latter a lot doesn't work but it has been enough to get to a command line in some cases. It's pretty remarkable how resilient the Linux kernel actually is.

I meant that the build configuration is probably tuned to give the best results. I'm aware that Slackware does not use patches on any of its software. That's part of its philosophy. But you can build an infinite number of different kernels out of one kernel tree just by choosing different options. That's why I would prefer to rebuild the LFS kernel with the Slackware configuration rather than just import the binary version.