This is what I meant when I said "you keep reiterating the same "bugs" over and over without releasing much information". You say you tried numerous fixes. What did you try? Did you read my previous post? I'll even link to it for you: http://www.linuxquestions.org/questi...7&postcount=71
People that reported this error said it went away when using the generic-smp kernel, and now you're talking about non-root users that belong to the recommended groups. Although that is necessary as well, I recommended that you tried using the generic-smp kernel that came with Slack 12.0 and make an initrd.gz to see if it worked then. I have received no response to this in two posts.

It seems as though you are happier complaining than having a perfectly running system.

I don't see why it matters so much to you. I am not complaining.

The hal problems existed when this machine was running the generic smp kernel. I added my custom kernel after the fact, and actually had less problems when it was temporarily not supporting hal.

I will say that the DVD ROM problems have cleared up as if by magic. However, I remain unable to get to the native Linux partition directly. HOWEVER, it's not a problem for me. I am not complaining.

I have checked all the links provided above. I saw nothing about how this thing was done. All I saw was someone asking about using initrd.splash. I followed the link provided, and I saw nothing about what to put into the initrd. Am I just supposed to put a blank file called initrd.gz in my /boot directory, or is there something to put in it? This question remains unanswered. If it has been answered, could you point to the specific place, please? The provided links provided no information.

If you can be more specific, I'd like to see this information. If there is a possibility to get konqueror working like it does on my Slack-11 machines, I'd like that.

Blessed be!
Pappy

Sorry, see this thread linked from the the post linked above: http://www.linuxquestions.org/questi...d.php?t=567691

I couldn't find that thread when I searched before so I pointed you to the most relevant one I could find. In the one linked previously, they mention only in passing that they had to use the generic-smp kernel because they wanted to access the drives like normal.

Read posts 17-25 of the newly linked thread. I'm just a little obsessive compulsive, so I like everything wrapped up well. I'm not asking you to use the generic-smp kernel forever. I just want to see if this is a Slackware bug or a custom kernel bug.

Basically, you need to use the generic-smp (NOT the huge-smp) kernel instead (you don't have to delete your custom kernel or anything -- you could just create a new entry in /etc/lilo.conf that boots up to the generic kernel instead of your custom kernel). BEFORE rebooting into the new kernel, you must create an initrd.gz file in /boot. This is necessary because the file system is contained in a module in the generic kernels and must be loaded upon booting for anything to work. The instructions for creating an initrd.gz are contained in the README.initrd file contained in the /boot directory (this file is actually a symlink to /usr/doc/mkinitrd-1.1.2/README.initrd).

I just navigated to the /boot directory in a terminal and typed "mkinitrd -c -k 2.6.21.5-smp -m reiserfs" without the quotes (I'm using reiserfs for my root partition). If you're using another file system you'll have to read the README.initrd file for info on creating an initrd.gz.

Hope that helps (note: I didn't have time to proofread this post, so it may be really really crappy)

The link provided was one I already looked at. While it does discuss initrd, I fail to see how having an initrd (INITial Ram Disk) can in any way "mount" my linux native partition, as in make it readable under konqueror without having to resort to the using the "root" button, or any other work-around.

hehehe well, you maybe OCD, but at least you are honest about it, and I applaud you for your honesty. Too bad honesty is a commodity that is in short supply these days.

But I digress...

The link provided is one of the same links provided in a previous post, so it was less than forthcoming with the information I needed.

However, I am currently investigating my own solution to the hal "problem", vis a vis installing Slack-12 on another machine, removing all vestiges of hal, and recompiling KDE using the source from the install DVD. Since I don't really use this particular computer for anything earth-shaking, I can put it to the task of compiling the entirety of KDE-3.5.7 without the influnece of hal, and not miss anything in the interim. I could do it on my new laptop, but I have that particular setup of Slack-11 working as close to flawlessly as an install of Slack-11 can possibly run. I may be willing to experiment, but when I have something set the way I want it, I am not about to mess around with "perfection".

While I still fail to see what difference having an initrd.gz file is going to make in allowing me to see my Linux partition without having to use a work-around under konqueror, I am going to give that a go on the machine I am C-U-R-R-E-N-T-L-Y installing a new iteration of Slack-12.

My limited understanding of initrd.gz is that it installs important modules before they are called by the kernel, such as file system modules (reiserfs for instance) so that the kernel won't panic due to the fact that the person compiling the kernel in question didn't directly compile that support into the kernel. In other words, initrd.gz seems to be a work-around in and of itself. I fail to see, given that understanding of initrd.gz, how having one can suddenly make all things right as rain in hal-land.

But life is for learning, and I would be remiss in my own "study" and understanding of Linux in general, and Slackware in specific if I didn't at least try. Before I set to the task of recompiling KDE in a hal-free zone, I will see about gving initrd.gz a whirl. The worst that can happen is it won't work...and in that case, there is nothing lost but a little bit of time. If it does, I can start a thread about it. Same thing for recompiling KDE. Whatever happens, I'll be sure to post it here.

Well, I don't really grade people on whether or not their is proof of proofreading when it comes to their posts. I am anal about it for myself, but I don't hold others to that standard, so you are safe..hehehe.

It wasn't a bad post, but it didn't shine any new lights. No biggie! I am at the point where I really want the Slack-12 hal bugs to be gone. Yes, I can work around them. No, they aren't really that annoying as bugs go. I have dealt with worse bugs from other Linux distros. Hal is really more of a pain in the rectal region than it is anything really major. With that said, I still maintain that somehow these problems had to have surfaced before the release of Slack-12. If that is the case, I would think the only proper thing for the Slackware team to do would be to pubish a definitive "fix" for the errors caused by hal.

Ah, cool and groovy! The Slack-12 setup program has just finished installing, and is starting configuration. Therefore, let me sign off and see if an initrd.gz really does anything of value in the hal situation. My assumption is no at this point, but we shall see what we shall see.

Blessed be!
Pappy

It's not the initrd.gz that does anything at all to fix the partition access from media:/ in Konqueror, it's the generic-smp kernel that comes with Slackware 12.0. They've included or not included some obscure option in the kernel that allows the root partition to be accessed using the icons. I have no idea what it is, and it probably has something to do with HAL, but I have no idea. I'm no expert. Basically I'm just asking you to try the generic kernel instead of your custom compiled one because root partition access through Konqueror is known to work using the generic kernel. The only reason I mentioned an initrd.gz is because you just happen to require it when you use the generic kernel. If you really want, you could use Slackware 12.0's generic-smp .config file and compile a new kernel (using the 2.6.21.5 kernel, of course) but just compile the file system into the kernel instead of as a module to avoid using an initrd.gz, but that's more work.

Seriously, trying this out would take all of 5 minutes and would do no permanent harm whatsoever to your system. If it doesn't work, just change /etc/lilo.conf to boot into your other custom kernel.

Here's the procedure. Add this to the end of your /etc/lilo.conf file:
Then create an initrd.gz as described above. Then run /sbin/lilo. Then reboot and choose the new kernel to boot from (ie highlight the LinuxGeneric option at the lilo prompt and press enter). Make sure you start KDE as a non-root user that has been placed into the cdrom, plugdev, audio, video, etc. groups as required by HAL and open Konqueror and see if you can access the root partition. Done. To reverse this procedure, remove the non-root user (actually I would recommend leaving this, but it's your system), remove the newly added section in lilo.conf and then run /sbin/lilo, delete the /boot/initrd.gz file and the /boot/initrd-tree directory, and reboot into your custom kernel. Done. No harm done to your system and you discover whether or not the problem is with your custom kernel or with Slackware.

Plus, if anything goes wrong with the generic kernel (ie you messed up), all you have to do is reboot and since you left the original lilo entry in /etc/lilo.conf you can just boot into your old kernel and your computer will be good-as-old.

Really no risk involved and not much time wasted to prove or disprove your bug theory. Your incredibly long posts (not a bad thing, just a fact) probably took longer to type than the time it would take to try this out.

Let me say that this actually works. It allowed me to access my native Linux partition with the icon, instead of using the work-around. I will speak a little more later on that.

Also, I apologize for not getting right back to you yesterday. My day was rather long, and when it was time to play with the computers, I was just a bit tired, and I decided to go to bed instead of replying. I also wanted to try an experiment, which worked rather well. More about that later, as well...now let me get to your message.

As strange as it was for me to watch it happen with my own eyes, I can vouch for the fact that it works. Now, as to the reason why...therein lies a strange and sticky wicket. I am not even sure I understand it.

Used by itself, the generic smp kernel will not allow access to the Linux native partition directly. Using initrd, the drive can be directly accessed. Curiously, all I needed to do was the simple mkinitrd followed by mkinitrd -m reiserfs. The computer did all the "heavy lifting" so to speak.

I noticed something in the Slack supplied generic smp kernel. It is front-loaded with support for all the file systems directly. Also, all the modules are loaded by default. Therefore, having initrd load the reiserfs module early results in an error. I also noticed that if you run the file system as a module, and use initrd, the kernel will panic. Therefore, it appears as if to make this work, you not only have to directly install support for your particular file system, you also need to set up a file system module as well.

Which brings me to my experiment. The people on the Slackware team were kind enough to put the config files that generated the kernels in the /boot directory along with said kernels. Using the generic smp config file, I compiled a 2.6.22.1-smp kernel. I had to compile it twice. First I compiled it with direct support for reiserfs, then I recompiled it so that reiserfs was a module. Using the kernel with direct reiserfs support, I created initrd loading just the reiserfs module.

That setup ALSO now works to allow me access to my native Linux drive directly. The downside is that it makes for a big kernel, and even larger amounts of modules since that generic kernel is set up to support just about anything hardware-wise you can throw at it. Now, the experiment changes to find out what is the absolute minimum you need compiled into the kernel in order to make it work. Could it be just smp support? I'll find out soon enough.

It actually took a few hours to make it happen. Part of that time was installing Slack-12 on the machine; the one I am currently using, a PII 450 tower. Another part was analyzing the structure of the generic kernel, and compiling it as version 2.6.22.1-smp.

CUTTING HOW-TO

I know about the risks involved with compiling custom kernels. I have a generic lilo.conf that I set up specifically for kernel compilation experiments. It's seen a lot of use here of late.

Anyway, it is nice to know that even though the fix doesn't make absolute sense, it works. Given my experience setting up Slack-11 and Slack-12, I still say that Slack-11 requires a lot less debugging to get it up and running properly.

With that said, I can also say there are a few niceties in Slack-12 that do make it worth the change.

Oh, and something that I'd like to kill off right now as an untruth, at least from where I am sitting. I am presently logged in as root. Everything is apparently working as expected, even as root. I can see all my hard drives, and access them all directly in konqueror. And yes, if I install a DVD into one of the two DVD drives, it comes up automatically. All this as the root user. Hmm...I have it on great authority that isn't supposed to happen. Well, it does, and I am sitting here as proof positive.

Blessed be!
Pappy

PS, I hope this helped with your OCD issues...

DISCLAIMER: This is my experience as a result of doing experiments in order to get the hal portion of slack-12 working properly. It is not the gospel truth. It is my experience. Your results may vary, and probably will!

I want to thank T3slider for continuing to needle me on this issue. Because of that, I have discovered some things about hal, and how to get it working.

First, initrd is a must. I don't know why, but it is. With it, I can now directly access my Linux native partition using the drive icon provided. Without it, there is no direct access. Even though initrd is loading a module that is already compiled into my kernel, reiserfs, it is apparently a must. Go fig!

Second, the kernel has to have smp support activated. I activated it directly. I didn't set it up as a module. While I am reasonably sure that it can be set up as a module and be functional as well, I can't say that with 100% accuracy, and therefore, I won't. However, I am going to compile a new kernel for the tower system doing the same thing I did to get this one working, except I'll set up smp as a module.

Third, all debates aside as to whether or not it is wise to operate with only a root user, if you add root to the plugdev and cdrom sections of the /etc/group file, you can access your CD ROM and DVD ROM drives, and the Linux native partition as well, assuming you have a smp-enabled kernel and initrd.

It is an untruth that you must create another user in order to be able to see all your drives. The root user can and does work in this scenario. I should know. I am currently logged on to this computer, and the tower machine as root, and everything is hunky-dory in hal media land.

So, at long last, I can join the chorus of those who have been happily computing away with hal without one hint of problem. Boy howdy, it was a lot easier debugging Slack-11.

Blessed be!
Pappy

It was a long walk Pappy...

pappy, I am very impressed. You went to a lot of effort and basically figured out the problem and a solution for custom-built kernels. As to why the initrd works...who knows. But it appears as though you were very thorough (and even included controls to ensure it was the initrd.gz).

Thanks for your effort on this matter -- now when I compile my custom kernel (I haven't had enough time to labor through all the kernel options yet) I'll know how to get Konquerer to work properly (well, actually, I don't really access my drives from media:/ very often, but it's nice having everything working anyway. )

As for the 5 minute thing -- sorry, I was assuming you had a complete slack 12.0 installation up and running (and if I had read your previous post more thoroughly I would have known this wasn't the case).

Anyway, thanks again for all your effort (and patience with me).

[edit]As for root being able to access drives, I guess that makes sense and also disproves many people.

And I noticed your disclaimer about this only being your experience -- I take it that's to prevent another epic battle of words? )[/edit]

I'm not sure who said that root wouldn't be able to access the drives, but as for me, I've never stated that to be the case. In fact, there are numerous posts by me on alt.os.linux.slackware indicating that it would work fine if root is in the plugdev group. Just FYI

Yes, it was a very long walk. Frankly, had the troubles hal generated with my systems not been so confounding, I'd have probably gone searching for them a few weeks back. However, that wasn't the case...and even though there was some preparation for the shock that hal was going to bring, I hadn't read any of it before I tried Slack-12 on this machine (Toshiba laptop), so I was ill prepared for the video glitches, and everything that followed.

I thought better about it, and realized that by not dealing with the hal problems, I was in essense giving up on the idea of giving Slack-12 a fair trial. That's really not my style. Had it not been for T3slider and a few others giving me a small ration of poo, I would have shrunk from the challenge.

Now I have Slack-12 functioning as expected on two systems...which is two systems more than I would have been willing to install it on a few weeks ago.

Blessed be!
Pappy

You're welcome. While I am not one to be a classic go-getter, once I find a problem that peaks my interest, I grab hold like a Pit-bull and won't let go. You're also right, it's nice to have everything working up to my expectations. It's not too often that happens. This is apparently one case in which things did work out in my favor, even with the initial reluctance to take hold of the flame.

Noey problemo, dude. If I am really impressed by anything, it's the speed with which Slackware can dump 4.5 gigs worth of stuff onto a hard drive in thirty minutes, especially considering the speed and age of the system on which this stuff was dumped. Hell, some distros I have tried can only pump half that much data taking almost five times as long (I'm looking at you, Fedora).

Once again, you are very welcome. I am glad that I could be of service. To me, that's the idea and the ideal behind Linux. I know I will never be on par with some of the Linux gurus who kept up with Linux from the get go. However, there is something I can contribute. I didn't work repairing computers and setting up networks in offices and not learn a bit about hardware, software, and everything in between.

Yeah, I really had a problem with the idea of Slackware limiting your choice to use your system as root. I am used to the idea of not having a root account with the Ubuntu family, Ark Linux, and some other distros more geared to the newbie. I am not used to it for the likes of Slackware. I just couldn't wrap my head around the idea that Slackware would deny me my right to destroy my system with root access... Thankfully they allowed me that option. Bless you guys!

And yes, I am going to disclaim what I write here. I don't want to get into matching wits in a place that isn't really about that. That's something I save for OpEdNews.com and some other political debate sites I visit. I come here to learn, and to share my experience. I don't come here to pronounce my superiority.

Firstly, I don't know enough to make such a pronouncement. Secondly, even if I did know enough, I'd still not be arrogant enough to rub that "fact" in other peoples' noses. Thirdly, as I have said before, I really don't take this all that seriously. It's a way to feed my inner geek, not a way for me to justify my existence, or proclaim my unlimited intellect. It's a way for me to use my computers without having to give my pound of flesh to the Redmond Computer Mafia.

Besides, even if I did know it all, I would still be looked down upon by some because I am not a Linux purist. The fact that I still use Windoze would rub many the wrong way. Once again, that would be counter to what I come here to accomplish.

Anyway, I am going to do a bit more playing, then I am going to consider writing a how-to on skirting the issues and troubles with Slackware-12. While this thread has done much to do that already, it's still a little scatter shot in its presentation.

Blessed be!
Pappy

I know you didn't I went back through the posts about this topic. rkelson was fairly vehement about the need for a non-root user. T3slider suggested it might be the root of the trouble (pun intended).

Well, my testing shows that if you are like me, and want to use root access with Slack-12, you can do it. I am doing it right now.

Please note, I am not listing anyone's name to shame them. I just wanted those who made that statement to reevaluate it in light of evidence to the contrary. I invite them to test my conclusion for themselves. That conclusion is, one need not be limited to a non-root user in order to be able to use Slackware-12.

Anyway, for now, I am just happy that there has come a point of resolution with this issue, at least as far as my computers are concerned. I am also really happy that I did get Slack-12 going, because Knemo rocks! I love watching my network operate...on those days it wants to operate without having fits...like tonight...some birthday present, eh?

Blessed be!
Pappy

Yes. I'll openly admit it. It's for your own good.

There are two types of Linux users. Those who know why running as root is a bad idea, and those who are going to find out why running as root is a bad idea.

Perhaps, but in consideration of how screwed, glued, and tattooed my internet connection has been of late, I doubt anyone could get through to me to do any real damage. Even if they did, it's not like this computer (or any of my other "children") are in serious trouble, or are doing anything I'd consider mission critical. Now, if my children were doing mission critical things, such as supporting a burgeoning business, that would be another matter entirely. Then I'd really consider having a non-root alter-ego. Until that happens, I don't see the harm.

I also know that it's less than a good idea to operate a Windoze NT derived operating system as "administrator". However, since the time I first installed Windoze NT on a system I owned, I have only set up alternate users for networking with samba...which is recent. And I only did that because it eliminates the need to keep retyping my samba passwords.

Besides all that, when you consider the fact that only one of my machines has an installation of Slackware that's more than a month old, and the fact that the two most important machines in my stable are only up and running when I am there with them, it seems to me that I stand more chance of causing the damage to these systems myself than I do having some enterprising young pups getting in through two firewalls and reeking havoc on my happy family.

Back to the real point here: while it may be a bad idea to log in as root, and while it may subject your systems to the possibility of attack from others, operating your system as root will not prevent hal from working. And since this discussion thread is about hal, I think it is only right to tell people that hal and root access aren't incompatible...especially for those of us who are the second kind of Linux users you have listed above.

Blessed be!
Pappy