I can't access to the root disk, help please
 

Hi, everyone.

I just installed slackware 12, and had root partition of 30gb, and /home of 10gb. As I am the sole user of this laptop, normally "root" is the default user, (sorry, i know it isn't a good idea).

The situation is that I can access the 9gb parition, but cannot access my 30gb root partition, when I double click the 30gb and here is what I got,,

"A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.freedesktop.Hal.Device.Volume" member "Mount" error name "(unset)" destination "org.freedesktop.Hal")"

Can someone help me on this? how to fix it or should I just ignore it.

Thanks in advance.

Mark

You need to read the HAL sticky ... it's very important, and that's why it's a sticky.

Yes, as H_TeXMeX_H said, everything you need is in the HAL stickied thread. I think I've typed out a response to that question 300 times by now. :)

In brief: I'm assuming you're using the huge-smp kernel. You shouldn't be. Switch to the generic-smp kernel (instructions are in the HAL thread near the end) and create an initrd (a necessary step when using the generic kernel).

The reason you can't access the root partition from media:/ has to do with the initial ramdisk. For whatever reason you NEED an initrd to have that functionality. You could, of course, simply type "/" without quotations in Konqueror and you would be able to browse your entire directory tree, but if you want the other functionality, you MUST switch to a kernel using an initrd (like the generic-smp kernel).

Have fun (and good luck).

[edit]Note that switching to the generic kernel is recommended anyway even if you don't want that functionality -- the huge kernel contains a LOT built in and requires extensive blacklisting to avoid errors (plus, I would imagine it is slower). You could also compile your own custom kernel, but whatever.[/edit]

Hi,

Why do you think the kernel would be slower?

Well, I'm absolutely a non-expert, but I just figured that if there was much more built-in to the kernel, more unnecessary crap would be running than with the generic kernel, causing slow-down. The slimmer the kernel the less work it has to do. But again, I'm probably wrong.

In my good old days, where PC only comes with 4MB or 8MB of RAM and disk space is only 200MB to 400MB, having a fat kernel is always something we don't like. I still remember how I tried to squeeze as much available memory from the system.

In additional, the default kernel is usually aims to run on most processors (is suppose to be generic). I prefer to run it with a more dedicated setup (where the kernel it aim to run on the specific hardware that I am using). For example, making sure the CPU optimization is setup only for my CPU. There was once. I was trying to boot up from a disk after its original main board died, forgetting that I had optimized it to run on an ViaC3, I put it on an AMD-K6 CPU, it obviously can't boot.

Anyway, I think I am still doing this because it feels like a habit. I don't remember I had ever used the kernel comes with Slack for any of my system.

No, you're not wrong, but the slowdown is maybe 0.5 sec or so ... maybe even less. But you are right about the other problem in that if too much is built-in to the kernel it may cause internal driver conflicts. I too recommend that if you have a bit of time and patience you can try to compile a custom kernel.

I've found the fastest and easiest way to compile a custom kernel is the following:

take a look at number 2 here:
http://www.linuxquestions.org/questi...09#post2672909

Start with the generic kernel and work from there ... I think that's the easiest way.

Hi,

Well, the kernel does not handle the hardware serially but via interrupts. That way the service is provided via the driver when needed therefore speed would be dependent on the device(s) usage for the machine. You are confusing processes with hardware management. If you want to speed things up then trim out services that you don't need or use.

The fatness of the kernel doesn't provide an indicator as to the speed of the system. As pointed out by others the trimming of the kernel does decrease the size. We no longer depend on the floppy as a recovery medium, even so the size of the 2.6 kernel when trimmed wouldn't fit on a 1.44MB floppy anyway.

I would suggest that you read the Linux Device Drivers, Third Edition which is in the Linux Kernel section of 'Slackware-Links' to get an idea how this is done. The Kernel Books link will get several links covering the 2.4 and 2.6 kernels.

Hi,

I agree that a custom kernel for the resident hardware is best fit. I usually use the default on my testbed system to keep a basic system that is working for experimentation. Others I will fit to the system.

Yes the fat kernel would not be ideal for a small system. The smallness of the kernel would indeed help in this area to allow a user to operate a small controller, programmable controller or a custom PC. These type of systems come to mind when thinking about custom kernels. Most modern day desktop or PC systems don't require a custom GNU/Linux kernel. Generally the user is left to decide which kernel to select for a boot of their system.

When a user does require a custom kernel it is not that difficult to do. There are a lot of guides for someone to cook a kernel by following the recipe. You can reference 'Slackware-Links' formerly 'Slackware LQ Suggestions Links!' for good online reference.

The size of the kernel does not impact the running speed of the system ... but it does impact the time it takes to boot. I know this very well, because I have an old laptop (the older one), where you can see a huge difference in boot time depending on kernel size. On newer computers, the time is about 0.5 sec or less difference ... you probably won't even notice it. In fact it's hard to prove this, because my timer is not accurate enough.

Thanks all guys for the response, and sorry to have made T3slider to type the response for the 301th time. Actually I figured that it could be the issue of Hal, but I just can't understand too much the sticky "Hal" thread,,, that is why I gave a shot in this forum..

Sorry for the laziness, I will read through the thread again,, slackware makes me learn the system, which is somehow intimidating.

Thanks again..

Mark

Actually, I agree, the HAL thread is a bit unclear (or maybe it's just too long, when I look at thread that long, I just skim through it and don't quite understand). Now, I don't think that I can explain it any clearer (and I've never needed to do it), so, I just point to it and say "read it".

"read it",,,, the beauty of slackware

I always compile a custom kernel just so I can enable only what I need (and also the stock kernel doesn't support certain things [like some ACPI stuff etc.]). Plus, running 2.6.22.9 feels better than running 2.6.21.5. I guess I'm a number hog (although I haven't had the guts to try out any testing versions for stability reasons).

As for reading about device drivers -- if only I had the time. ;)

As for the HAL thread, yeah, it's incredibly long. :) I guess I just refer everyone to it because I've read the whole thing. I would advise anyone installing Slackware 12.0 to read the whole thing -- there are valuable nuggets of information scattered throughout the thread. I'm not saying you have to read it in one shot (that may kill you off), but I would still advise getting through it. The beginning offers information on HAL and how to add yourself to the appropriate groups and the end diverges to talk about Konqueror's root partition access through media:/.

Well, you do have to read if you want to learn, don't you ?

Don't worry, you only have to read it once, then after using Slackware for a while, come back and post what you think of it again.