Language Selection

English French German Italian Portuguese Spanish

SabayonLinux 3.26 on my HP Pavilion Laptop

Filed under
Linux
Reviews
-s

SabayonLinux 3.26 was released on Jan 7, only a short time after 3.25. This maintenance release is the last of the 3.2 series and the team will now concentrate on 3.3. While many reviews shout accolades to this rising star, Tuxmachines once again suffered a loss of data making our experience a bit mixed. This is a short description of our time with SabayonLinux.

Since SabayonLinux is based on gentoo and should really amount to a fully functional gentoo system without all the work, this system is still falling a bit short of that perceived goal. But not by much. Without the loss of data, the time spent configuring hardware and services wouldn't be begrudged. However, upon install, I was left to spend a coupla hours learning grub and getting back into my other systems. The loss of data isn't confined to that unpleasantness. Take a hint from Tuxmachines, don't try to use a shared home partition.

I have openSUSE 10.2 installed on the machine I used for SabayonLinux, but am still searching for that near-perfect system. openSUSE falls short in two mostly insignificant areas - or one mostly insignificant and one a bit less so. I mentioned the fugly font situation in my review of openSUSE, but I was to discover I'm having problems with the video players and .bin files. I can live without watching certain video formats, but I've grown quite spoiled in the area of font rendering.

The boot phase and desktop is very much in the tradition of Sabayon as I've known it. It is different from much of the pack while being very tasteful and attractive. This latest incarnation features customized splashes and graphics in peachy orangy hues. It's nice looking, even if my description doesn't express it. The fonts are much better in SabayonLinux out of the box that I've experienced with openSUSE even after experimenting and tweaking. The system features KDE 3.5.5, kernel 2.6.19, Xorg 7.1.99, gcc 4.1.1, and lots of nice software. The desktop includes a nice wallpaper, lots of transparency, and the Kickoff menu. So it makes a good second impression.

However, that second impression was marred by the first. The livecd bootsplash lists several boot options. These include SabayonLinux, a Music Edition choice, a Quake4 demo, and an Internet Kiosk NX mode, as well as text and gui installs. I wasn't having the best of luck in livecd mode, so after my second lock-up I decided to boot into the gui install mode. This option boots into a fluxbox desktop and starts the anaconda installer. It is your basic anaconda installer, with a few of the tedious steps removed. I supposed I was still undecided on some points and while setting up the partitions I defined my /boot, /home, and /. The first of my mistakes. The second mistake was that I chose not to install a bootloader as I find openSUSE's quite attractive. I figured I could edit the bootloader to include SabayonLinux later as I do on my desktop. Well, SabayonLinux did abide by my decision not install a bootloader, but it still overwrote the grub.conf/menu.lst with empty files. Wtf? Being a lilo person up until the install of openSUSE on this laptop, I was a bit out of my element. It took well over an hour (probably closer to two) for me to read up and fix the issue. Quite annoying. Ok, I admit, very annoying.

My third mistake was (naming a shared home partition and) using the same username as used on openSUSE. When I finally got grub squared away and got back onto openSUSE, I found all my files and data in /home/srlinuxx gone and nothing in their place. No skeleton files, no Desktop, no .kde or anything. WTF? So, the next coupla hours were spent restoring openSUSE to a usuable state. I've been installing various Linux distros for a long time now, and have never had this happen before. Very, very annoying.

The other problems with SabayonLinux can probably be attributed to my lack of knowledge, at least to a large degree. I've been using gentoo a long time as my main os, and my workhorse system has been in place so long that I may have forgotten more than I recall. Perhaps things have changed a bit as well. So, hardware detection and setup are other areas in which I'm having problems.

The graphics are detected and configured correctly. Nvidia drivers are loaded and a 1200x800 desktop results. It looks really nice. However my sound is not working. I've booted up perhaps a dozen livecds on this new laptop and SabayonLinux is the only system that does not configure the sound correctly. I see a lot of "dummy" modules loaded for it and trying to modprobe the correct modules results in 'module not found.' I'm going to have to rebuild the kernel it looks like.

The next issue is almost embarrassing to mention as I'm sure it's my own fault. Getting wireless to work is not really a problem, but keeping it after reboot is. I use ndiswrapper to utilize the windows driver for my wireless chip and have no problems there. I must first rmmod bcm43xx and then modprobe ndiswrapper to get the hardware working. Knetworkmanager can then connect to my access point most of the time. Sometimes I have to iwlist scan before it will see them. I'm not sure what's up with that. But the problem lies in having to do this each boot. I put ndiswrapper in the /etc/modules.d/autoload/kernel file and have even put bcm43xx in the modules.blacklist file, however each boot bcm43xx is loaded first and my wireless chip doesn't work. As stated, I'm sure this is a short-coming of my own and I can work this issue out, but it's not very newbie friendly. I guess as long as I'm rebuilding the kernel for sound support, I can take out bcm43xx to solve that. Big Grin

The next issue is once again my fault I'm sure. But I experience occasional lock-ups. I've tried using noapic which seems to lessen the occurrences, but it still happens. I'm going to have to explore and experiment with other boot options I guess to get around that, in hopes it can be cured. Where the one boot where the keyboard quit working after 30 seconds fits in I'm not sure.

My next issue is that same mplayer .bin issue experienced with openSUSE. This head scratcher is very puzzling. I've installed addition codecs and rebuilt mplayer on both systems, and have not figured this one out yet. But I had hopes it'd work in SabayonLinux.

The final issue I'd like to point out is erratic touchpad performance. The pointer does not move smoothly and at times stops. At other times it seems to have a mind of its own. This works flawlessly in openSUSE and all the other livecds I tested. So, this is yet another area I'd have to bone-up on if I wish to use SabayonLinux.

Here's the rub: I got this laptop for Christmas and I was wanting to get a working Linux install without a lot of fuss, muss, work, and time. That's the whole point of using a binary distro like openSUSE or SabayonLinux. If I wanted to rebuild kernels and applications, spend hours googling, and reading howtos I could have just installed Gentoo from scratch.

SabayonLinux looks real nice and includes the cool 3D effects of XGL and AIXGL (which I haven't bothered to test), but all in all, openSUSE is closer to working more properly than SabayonLinux. To be quite honest, I think I will not even bother working out these issues as time is of the essence. I know SabayonLinux does nicely with desktops and the developers are a small team. Their efforts are highly commended and they have garnered lots of nice reviews. But I don't think SabayonLinux is for my HP Pavilion laptop and my goals for it. I admit I'm still a laptop newbie and I sure could get to know my hardware really well if I choose to persue SabayonLinux. Smile

Previous attempts:





UPDATE: 01/13/07 - I've worked through or around most of the issues I complained about in this article, but one. This last one is the deal breaker though. SabayonLinux still intermittently locks up - tight. No sysrq dance to the rescue. So, I think I give up for sure this time. But as stated, I think Sabayon has lots of good qualities and would make some folks a real nice system - it just doesn't work well on my HP laptop.

Never. Ever. Use. Shared. Partitions.

...except for the swap Smile

re: Never. Ever. Use. Shared. Partitions.

Yeah, no sh*t.

----
You talk the talk, but do you waddle the waddle?

Yeah I have used this distro

Yeah I have used this distro once before.
I had trouble initially (not just this distro but all kernels prior to 2.6.19 have broken acpi for my HP Pavillion laptop, and I am yet to try 2.6.19, will probably build an LFS soon to stay vanilla)
This distro was the worst though, the version prior to last failed to boot at all into any graphics on the last release which caused me great frustration. I finally got it to boot eventually, with a broken acpi (noacpi caused it to hang???) so my system was burning up at 70C trying to run compiz without hardware acceleration. (Was not happy Sad )

I looked up on the disk and the reported ati driver that came with the distro was different to the one on the disk and as I decided to install this distro onto the disk and sort out the problems from there, they seemed easy enough to fix, rebuild the kernel to use the then experimental acpi-fix and get the latest ati driver which had full support for my card and in x86-64.

The install seemed to go without worry, I installed it on a clean hard disk, the disks unmounted and remounted cleanly afterwards so I was happy to risk rebooting to go into lilo in openSuse to add the new kernel.

Bang! I hit the same problem I had as you guys, no bootloader even after I said don't install one. No openSuse install disk to hand, just overwrote the dvdrw for this broken distro. so from here I had to install the only system I had to hand, a mandriva disk. I then had to boot into this system, add openSuse to the lilo menu and boot back into that system to delete the mandriva disto I don't want and clear that dvdrw so I never make the same mistake again.

Distro shows a lot of promise, but when I 'complained' on the forum that my card was unsupported in the version of the ati driver that was on disk i was pointed to a page showing the card running without hardware acceleration that the card was supported. I figure that was some troll so I never followed up the matter, but I kept an eye on this distro, when the installer works I may try it, but I will have probably just learnt to install a vanilla gentoo by then.

I have built an LFS (linuxfromscratch.org) distro on 2 machines before now, blindingly fast as I only install a basic setup, basic firewall and then KDE with full graphics support. I have no need for the likes of samba and cups and gnome a lot of the time, they are fantastic projects but not needed for my everyday use, i dabble with them on a distro where they come install, but I know what I use and so I prefer just to have that (a problem on rpm distro's imho).

Well I have a slightly worse opinion of this distro than most but nice to read a review from someone interested about it.

For the bcm43xx issue, write a simple init script to rmmod the bcm43xx module and modprobe the ndiswrapper.
That's what I am doing in openSuse 10.2, nice the kernel has experimental support for bcm43xx at last but I have a bcm4318 which from what I have heard doesn't work without the windows driver being loaded in some form.

re: Yeah I have used this distro

At least it didn't eat my partition table this time. Actually, come to think of it, it would have only taken me 10 minutes to fix that. Big Grin

Quote:

For the bcm43xx issue, write a simple init script to rmmod the bcm43xx module and modprobe the ndiswrapper.

I'd probably stick those commands in the local.start file (which is gentoo's equivalent to rc.local).

----
You talk the talk, but do you waddle the waddle?

bcm43xx issue

It doesn't matter what you do, as long as it's built into the kernel, this little bastard of a driver will be detected and loaded. Hal or udev or some running process has to do with that. I've been fiddling with sabayon on my hp laptop (dv6119) for about a week or so now, so bear with me.

I'm used to the barebones type distros, and only decided to try sabayon because it was hailed as one of the best 64bit distros out there.

I've learned you've either got to rename the actual driver and suffer with a startup error message, or rebuild the kernel without support for the bcm43xx module which will be done eventually anyway.

ndiswrapper works fine on most hp laptops with the bcm wifi chip.

I'm still undecided on this distro, but I do give them plenty of props for a job well done on setting up a gentoo based system fast and pretty damn accurately.

btw: you may want to try out the irqpoll boot parameter if your headphone jack and/or usb mass storage gives you a problem. worked for me.

re: bcm43xx issue

debauchery1st wrote:

btw: you may want to try out the irqpoll boot parameter if your headphone jack and/or usb mass storage gives you a problem. worked for me.

Oh no kidding? I'd given up on getting that earphone jack to work. In fact, you may have noticed, I've practically ignored its existence - forgetting to even mention it in my "laptop" articles. Wow, I'll try that. Thanks.

Yeah, I keep trying Sabayon. One of these days it'll be ready for me. ...or me for it. Big Grin

----
You talk the talk, but do you waddle the waddle?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

KDE: Linux and Qt in Automotive, KDE Discover, Plasma5 18.01 in Slackware

  • Linux and Qt in Automotive? Let’s meet up!
    For anyone around the Gothenburg area on Feb 1st, you are most welcome to the Automotive MeetUp held at the Pelagicore and Luxoft offices. There will be talks about Qt/QML, our embedded Linux platform PELUX and some ramblings about open source in automotive by yours truly ;-)
  • What about AppImage?
    I see a lot of people asking about state of AppImage support in Discover. It’s non-existent, because AppImage does not require centralized software management interfaces like Discover and GNOME Software (or a command-line package manager). AppImage bundles are totally self-contained, and come straight from the developer with zero middlemen, and can be managed on the filesystem using your file manager This should sound awfully familiar to former Mac users (like myself), because Mac App bundles are totally self-contained, come straight from the developer with zero middlemen, and are managed using the Finder file manager.
  • What’s new for January? Plasma5 18.01, and more
    When I sat down to write a new post I noticed that I had not written a single post since the previous Plasma 5 announcement. Well, I guess the past month was a busy one. Also I bought a new e-reader (the Kobo Aura H2O 2nd edition) to replace my ageing Sony PRS-T1. That made me spend a lot of time just reading books and enjoying a proper back-lit E-ink screen. What I read? The War of the Flowers by Tad Williams, A Shadow all of Light by Fred Chappell, Persepolis Rising and several of the short stories (Drive, The Butcher of Anderson Station, The Churn and Strange Dogs) by James SA Corey and finally Red Sister by Mark Lawrence. All very much worth your time.

GNU/Linux: Live Patching, Gravity of Kubernetes, Welcome to 2018

  • How Live Patching Has Improved Xen Virtualization
    The open-source Xen virtualization hypervisor is widely deployed by enterprises and cloud providers alike, which benefit from the continuous innovation that the project delivers. In a video interview with ServerWatch, Lars Kurth, Chairman of the Xen Project Advisory Board and Director, Open Source Solutions at Citrix, details some of the recent additions to Xen and how they are helping move the project forward.
  • The Gravity of Kubernetes
    Most new internet businesses started in the foreseeable future will leverage Kubernetes (whether they realize it or not). Many old applications are migrating to Kubernetes too. Before Kubernetes, there was no standardization around a specific distributed systems platform. Just like Linux became the standard server-side operating system for a single node, Kubernetes has become the standard way to orchestrate all of the nodes in your application. With Kubernetes, distributed systems tools can have network effects. Every time someone builds a new tool for Kubernetes, it makes all the other tools better. And it further cements Kubernetes as the standard.
  • Welcome to 2018
    The image of the technology industry as a whole suffered in 2017, and that process is likely to continue this year as well. That should lead to an increased level of introspection that will certainly affect the free-software community. Many of us got into free software to, among other things, make the world a better place. It is not at all clear that all of our activities are doing that, or what we should do to change that situation. Expect a lively conversation on how our projects should be run and what they should be trying to achieve. Some of that introspection will certainly carry into projects related to machine learning and similar topics. There will be more interesting AI-related free software in 2018, but it may not all be beneficial. How well will the world be served, for example, by a highly capable, free facial-recognition system and associated global database? Our community will be no more effective than anybody else at limiting progress of potentially freedom-reducing technologies, but we should try harder to ensure that our technologies promote and support freedom to the greatest extent possible. Our 2017 predictions missed the fact that an increasing number of security problems are being found at the hardware level. We'll not make the same mistake in 2018. Much of what we think of as "hardware" has a great deal of software built into it — highly proprietary software that runs at the highest privilege levels and which is not subject to third-party review. Of course that software has bugs and security issues of its own; it couldn't really be any other way. We will see more of those issues in 2018, and many of them are likely to prove difficult to fix.

Linux Kernel Development

  • New Sound Drivers Coming In Linux 4.16 Kernel
    Due to longtime SUSE developer Takashi Iwai going on holiday the next few weeks, he has already sent in the sound driver feature updates targeting the upcoming Linux 4.16 kernel cycle. The sound subsystem in Linux 4.16 sees continued changes to the ASoC code, clean-ups to the existing drivers, and a number of new drivers.
  • Varlink: a protocol for IPC
    One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1. The announcement came from Harald Hoyer, but he credited Kay Sievers and Lars Karlitski with much of the work. At its core, varlink is simply a JSON-based protocol that can be used to exchange messages over any connection-oriented transport. No kernel "special sauce" (such as kdbus or bus1) is needed to support it as TCP or Unix-domain sockets will provide the necessary functionality. The messages can be used as a kind of remote procedure call (RPC) using an API defined in an interface file.
  • Statistics for the 4.15 kernel
    The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall. This development cycle was supposed to be relatively calm after the anticipated rush to get work into the 4.14 long-term-support release. But, while 4.14 ended up with 13,452 non-merge changesets at release, 4.15-rc6 already has 14,226, making it one of the busiest releases in the kernel project's history. Only 4.9 (16,214 changesets) and 4.12 (14,570) brought in more work, and 4.15 may exceed 4.12 by the time it is finished. So far, 1,707 developers have contributed to this kernel; they added 725,000 lines of code while removing 407,000, for a net growth of 318,000 lines of code.
  • A new kernel polling interface
    Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance. On January 4, Christoph Hellwig posted a new polling API based on the asynchronous I/O (AIO) mechanism. This may come as a surprise to some, since AIO is not the most loved of kernel interfaces and it tends not to get a lot of attention. AIO allows for the submission of I/O operations without waiting for their completion; that waiting can be done at some other time if need be. The kernel has had AIO support since the 2.5 days, but it has always been somewhat incomplete. Direct file I/O (the original use case) works well, as does network I/O. Many other types of I/O are not supported for asynchronous use, though; attempts to use the AIO interface with them will yield synchronous behavior. In a sense, polling is a natural addition to AIO; the whole point of polling is usually to avoid waiting for operations to complete.

Security: OpenSSL, IoT, and LWN Coverage of 'Intelpocalypse'

  • Another Face to Face: Email Changes and Crypto Policy
    The OpenSSL OMC met last month for a two-day face-to-face meeting in London, and like previous F2F meetings, most of the team was present and we addressed a great many issues. This blog posts talks about some of them, and most of the others will get their own blog posts, or notices, later. Red Hat graciously hosted us for the two days, and both Red Hat and Cryptsoft covered the costs of their employees who attended. One of the overall threads of the meeting was about increasing the transparency of the project. By default, everything should be done in public. We decided to try some major changes to email and such.
  • Some Basic Rules for Securing Your IoT Stuff

    Throughout 2016 and 2017, attacks from massive botnets made up entirely of hacked [sic] IoT devices had many experts warning of a dire outlook for Internet security. But the future of IoT doesn’t have to be so bleak. Here’s a primer on minimizing the chances that your IoT things become a security liability for you or for the Internet at large.

  • A look at the handling of Meltdown and Spectre
    The Meltdown/Spectre debacle has, deservedly, reached the mainstream press and, likely, most of the public that has even a remote interest in computers and security. It only took a day or so from the accelerated disclosure date of January 3—it was originally scheduled for January 9—before the bugs were making big headlines. But Spectre has been known for at least six months and Meltdown for nearly as long—at least to some in the industry. Others that were affected were completely blindsided by the announcements and have joined the scramble to mitigate these hardware bugs before they bite users. Whatever else can be said about Meltdown and Spectre, the handling (or, in truth, mishandling) of this whole incident has been a horrific failure. For those just tuning in, Meltdown and Spectre are two types of hardware bugs that affect most modern CPUs. They allow attackers to cause the CPU to do speculative execution of code, while timing memory accesses to deduce what has or has not been cached, to disclose the contents of memory. These disclosures can span various security boundaries such as between user space and the kernel or between guest operating systems running in virtual machines. For more information, see the LWN article on the flaws and the blog post by Raspberry Pi founder Eben Upton that well describes modern CPU architectures and speculative execution to explain why the Raspberry Pi is not affected.
  • Addressing Meltdown and Spectre in the kernel
    When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly. First, a couple of notes with regard to Meltdown. KPTI has been merged for the 4.15 release, followed by a steady trickle of fixes that is undoubtedly not yet finished. The X86_BUG_CPU_INSECURE processor bit is being renamed to X86_BUG_CPU_MELTDOWN now that the details are public; there will be bug flags for the other two variants added in the near future. 4.9.75 and 4.4.110 have been released with their own KPTI variants. The older kernels do not have mainline KPTI, though; instead, they have a backport of the older KAISER patches that more closely matches what distributors shipped. Those backports have not fully stabilized yet either. KPTI patches for ARM are circulating, but have not yet been merged.
  • Is it time for open processors?
    The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea. Given the complexity of modern CPUs and the fierceness of the market in which they are sold, it might be surprising to think that they could be developed in an open manner. But there are serious initiatives working in this area; the idea of an open CPU design is not pure fantasy. A quick look around turns up several efforts; the following list is necessarily incomplete.
  • Notes from the Intelpocalypse
    Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel. All three disclosed vulnerabilities take advantage of the CPU's speculative execution mechanism. In a simple view, a CPU is a deterministic machine executing a set of instructions in sequence in a predictable manner. Real-world CPUs are more complex, and that complexity has opened the door to some unpleasant attacks. A CPU is typically working on the execution of multiple instructions at once, for performance reasons. Executing instructions in parallel allows the processor to keep more of its subunits busy at once, which speeds things up. But parallel execution is also driven by the slowness of access to main memory. A cache miss requiring a fetch from RAM can stall the execution of an instruction for hundreds of processor cycles, with a clear impact on performance. To minimize the amount of time it spends waiting for data, the CPU will, to the extent it can, execute instructions after the stalled one, essentially reordering the code in the program. That reordering is often invisible, but it occasionally leads to the sort of fun that caused Documentation/memory-barriers.txt to be written.