VectorLinux
December 19, 2014, 03:55:11 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1]
  Print  
Author Topic: Bad experience with another slack-based distro (maybe libata too)  (Read 1225 times)
newt
Vectorian
****
Posts: 1132



« on: January 06, 2008, 12:19:06 pm »

So I decided, after a couple of years, to try a different flavor of linux for the fun of it.  I have a spare machine and figured it was time to try this slack-based distro I've heard good things about.  The experience I had on this particular system was far from ideal or fun.  It felt like I was fighting it the whole way.  So much so that I've given up playing with it anymore - at least for now.

The story goes like this:
Booted from non-live cd, chose standard boot option (for normal ide drives), and away it went - booting.  During the boot process it encountered some kind of hiccup that lasted about 4 minutes or so.  I kept getting "slow to respond" notices about my hard drive and cdrom, afterwhich I'd see a line about the dma mode was being bumped down.  After both devices had been bumped down to pio mode it continued the install in the typical ncurses fashion.  I followed through the install procedure without any problems until I got the actual "find the cd and install" part.  This is where it could not find my cdrom; strange, but this happened to me once with a vl install and I just started over again and all was well.  So, I rebooted and started fresh.  Same slow 4 minutes boot, same pio mode only, and same "cannot find your cdrom" problem.  I researched the problem a bit on another computer and figured I could back out of the installation, mount the cdrom manually, and continue again with the distro install.  Sure enough, I was able to mount the cdrom manually without any problems after which I continued with the distro install.  It finished with the package installs successfully.  Next came the lilo setup - I figured the normal mbr method was appropriate.  Nope; lilo didn't want to go - something related to an error on line 48.  Luckily the distro had an manual lilo configuration tool to use which worked fine.  Install was done - "Great!" I thought "Let's reboot!".  Up came lilo, selected the new distro and freeze.  Computer just sat there - no hard drive activity, no key response, nothing.  So I manually rebooted numerous times passing various lilo options in various combinations (noacpi, noapic, nolapic, ide-legacy, init 2, single user mode, random other options I could muster up) all of which did nothing to resolve the freezing/booting situation.  Finally I rebooted and started watching my hockey game on the tv; about 7 minutes later I notice the screen change.  The distro was continuing to boot - yipee; I must've been to quick to reboot on the "frozen" screen.  At this point it continued with some hardware setup but as it turned out ALSA could not find my ali on-board sound; no network devices found (I have two - built-in wired and wireless pcmcia); no usb setup (extra mouse and flash drive).   It finished and moved to the login screen.  I logged in and away I went.  The desktop was clean/polished and the system as a whole was VERY responsive.  I spent many hours over the course of 2 days trying to figure out the hardware issues that were encountered using various techniques I could find online and in their community forums, all to no avail.  The boot problem persisted such that I had to wait about 7 minutes total just to reach the login screen.  I could never get sound, usb, network devices to work.  The distro forum was not much help in resolving these issues either; admittedly I did not register or start my own topics but that's only because I had seen the responses posted to similar users experiences with basically the band-aid statement of "looks like it's libata in the new kernel and this is happening with other distros as well" (seems like a copout to me; Vec would have downgraded to a more universal kernel if this had happened [at least I hope he would have Cheesy].  I was dealing with so many problems that I didn't feel it necessary to continue, especially considering the help I imagined I'd get from the community.  I considered posting my troubles here since I know our community is glad to help with any distro problems, especially those related to slack-based distros, but didn't want to waste users valuable time with non-VL problems.  Overall, I'm bummed because the system felt really fast (surprisingly, faster than VL) and I was hoping to test drive the distro I had heard so much about, but with all of the obsticles I was facing I felt it would be a lost cause.  Aside from this one distro, there aren't any others I'm eager to try so I'll put VL58 back on and go on my merry way Grin

After this experience, I certainly hope libata doesn't rear it's ugly face at us in the future (if that's truely the cause of my troubles).

Any way, thanks to VL and all it's devs for doing such a wonderful job making as close to "perfect" distro as they can!!
Logged
uelsk8s
Administrator
Vectorian
*****
Posts: 2504



« Reply #1 on: January 06, 2008, 01:25:35 pm »

libata has reared it ugly head. we have not found a way around it thats why we will stick to 2.6.22.X kernels for now.
I have not heard of it causing problems with sound though.
it should speed up the system, but at the expense of what?

Logged
toothandnail
Tester
Vectorian
****
Posts: 2527


« Reply #2 on: January 06, 2008, 01:45:13 pm »

Even when libata doesn't cause major problems (like being unable to detect hard drives or opticals on some chipsets), it still has a number of drawbacks.

1. Limiting partition numbers to the SCSI maximum count of 15. For many people thats not going to be a problem, but many machines which are used for testing or are multiboot will be pushing that limit.

2. Disabling performance tuning via hdparm. While the libata drivers seem to enable DMA by default, there doesn't seem to be any way to do things that can be done simply with hdparm to further refine device performance.

3. Disabling the smart monitoring tools. Haven't checked lately, but the last time I did, smartmon reported ATA drives running under libata as not supporting SMART, so no safety checking is available.

To me, it seems like technology that was rushed and not thought about enough before being foisted on users. While treating all devices as SCSI devices has a good deal of logic, the current implementation seems quite broken, even after a good deal of development.

paul.
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!