On Sat, Apr 2, 2016 at 1:25 PM, Yasha Karant <[email protected]> wrote: > There were two more postings by me with suffix [2] and then [3] pursuant to > the situation with SL7.2 Live on this particular platform, including the > Ubuntu description of the hardware. > As far as I can tell, all of the important hardware (harddrive and > controller, DVD reader/burner, WNIC, NIC, pointing device, video//graphics > card, sound card, CPU including FPU and MMU, and USB devices) are linux > supported, including in SL 7. Have I missed something? The BIOS are
You're missing the part that, until and unless the kernel supports the particular chipsets, it can and will misreport the actual hardware. This is a common problem, especially since the manufacturer of particular can, and will, have the same hardware describe mismatched names on the box, names on the hardware order forms, names in the published Windows drivers depending on release, and names in MacOS and Linux and UNIX kernels depending on who wrote them. And they also change chipsets without telling anyone or renumbering the mother board revision number. Been there, done that, actually scraped sealant and hot glue off of chips to read the chip numbers. > "secure boot", but that is a standard issue on current X86-64 hardware and > "secure boot" (read, proprietary closed source vendor controlling) can be > disabled for "legacy boot". The issue that causes the dracut complaint is a > missing file image on the RAMFS that a non-installed (e.g., live) system > uses. The Ubuntu test was with a USB flash drive -- would that make a > difference? Hard to tell. BIOS discovery of hardware is a programming horror show, with closed source legacy components taking up resources better used for cleaner, more modern versions but unchangeable for legacy compatibility reasons. I *wish* > As far as the older text-based installer, I fully concur with the respondent > below. A text based installer should at least be an option -- it worked > much better. However, the live non-installed system supposedly will not use > the installer. (I point out that the only enterprise competitor to EL is > SLES, and SLES is much more GUI and automated than previous EL versions and > also -- from direct experience -- is neither easy to configure nor properly > supported except for large commercial-style configurations. There also is > no equivalent to this professional email list serve for any SuSE product to > which I had even licensed access.) The SL 7.1 and SL 7.2 installers are, in my recent observation, *nasty*. They don't detect network devices correctly for VirtualBox based VM's and network based installation, and I've had to use the SL 7.0 installer and http://vault.centos.org/7.0.1406/ as my upstream repository for network based installation. This is not a SL problem, it happens with CentOS as well. > I understand that Ubuntu is not as stable as EL (although Ubuntu advertises > support and at least at one point claimed that it could be used for > production deployments -- something one dare not do with unstable > non-hardened systems) -- but is the issue here simply one of the kernel and > drivers? Red Hat does certify EL 7 for laptops For good reasons which you are enocuntering, yeah. And please, it's called "RHEL" for a reason. Please use its actual name for consistency. > ( > https://access.redhat.com/ecosystem/search/#/category/Laptop?sort=sortTitle%20asc&certifications=Red%20Hat%20Enterprise%20Linux%207&ecosystem=Red%20Hat%20Enterprise%20Linux > ), > but all I could find for EL 7 were products from Lenovo. Lenovo is not > that conservative in hardware, and certainly competes with both HP and Dell. I'd urge you to discard vendor published "compatible with Linux" recommendations. They're not reliable, because vendors change hardware unannounced and because Linux tools grow more sophisticated. > Other than stating that EL 7 will not work, are there any other suggestions? Try SL 7.0 before being completely certain. Also, if you're putting the ISO image on a USB installer, you're adding another variable.
