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 "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?

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.)

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 ( ), 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.

Other than stating that EL 7 will not work, are there any other suggestions?

Yasha Karant

On 04/02/2016 04:40 AM, Nico Kadel-Garcia wrote:
On Sat, Apr 2, 2016 at 12:00 AM, Yasha Karant <> wrote:
SL-72-x86_64-2016-02-03-LiveDVDkde.iso would not boot on a HP Pavilion
Laptop Computer  model N5R26UA#ABA, although the list of hardware on the
machine should have been supported by SL 7.  Fortunately, one of my students
works at the store selling the machine, and his manager had a bootable USB
flash drive with several 64 bit linuxes on it.  Both ubuntu and mint booted,
so, presumably SL 7 should boot.  The DVD image was verified/tested before
using it.

Below is the (rather long) journalctl output from the attempt to boot SL 7
-- can anyone identify what is failing and how to fix it?  We have 14 days
to return the machine for full credit provided I do not modify the harddrive
(that I shall not do unless we keep the machine and install SL 7).

Any suggestions?  Is  there a way to test boot, without install, including
X, from the 4 Gbyte regular SL7.2 install DVD (after burning the iso file to
a DVD)?

Yasha Karant
[Very long records deleted]

First: SL, like hte upsteam RHEL, is really a stable server grade
operating system. The kernels will never be bleeding edge, with the
latest support for the latest laptop chipsets, many of which tended to
be very leading edge and off-brand. And Ubuntu tends to be leading
edge: they're not very stable for server grade systems, but rather
tend to the latest chipsets.

Second. the heavily reduced kernel and configs used by Anaconda for
the boot operating configurations can be..... problematic. I've also
had problems with 7. and 7.2, that did *not* happen with 7.0. In fact,
I just installled a server with 7.0 successfully, and was able to
update, when 7.1 and 7.2 CD's were unable to boot it.

Third: the "rescue" mode should still be available, adding the word
"rescue" to the boot kernel options. I really wish they'd list rescue
mode, and *not* on that ghods-awful X based "spoke and wheel" logic
installer. The older, text based installer worked very well, took up
much less screen space, was easier to read, and had consistent layout.
It also worked *much better* for remote consoles and
virtualizatization consoles.

Reply via email to