12.0 and HAL - READ THIS!

The_Outlander · 01-12-2008, 06:08 PM

Well, I gave up trying to solve my upgrade problems and installed 12.0 clean. Actually, the benefits were enormous, simplifying the initialization of slmodem, bluetooth and some other unique toshiba hardware. However, in order to get these things working I use a custom kernel (without smp) - it takes too long and is too much hassle to recompile the Slackware kernel with the options that I need, and, I don't have a dual core processor - as far as I can tell everything is working fine.

I understand that the software is optimized for the Slackware kernel - which I don't pretend to understand - but as far as I can see, my system is working just fine.

What benefits would be derived by compiling the next custom kernel with smp? Or is that a waste of time? Are there other issues to be considered, unique to the Slackware build process, that are not necessarily available to the user?

TO.

pappy_mcfae · 01-13-2008, 12:57 AM

Quote:

Originally Posted by Toods

I have read this all this thread and would just like to clarify my understanding of two points:

1.)That 'smp support' needs to be compiled into a custom kernel even when a uni-processor cpu is used? If this is really so, then HAL would not work with kernel-generic-2.6.21.5 supplied with the distribution would it?

Yes, it needs to be there. It doesn't matter whether or not you have more than one CPU (or a multi-core CPU). For whatever reason...and I honestly don't know the reason, Slackware 12 and its iteration of hal requires an SMP enabled kernel.

On my initial install, the SMP kernel was set up by default. All I needed to do was to set up the initrd, and I was on my way to an accessable root drive. Without the initrd and the SMP, I could but look at the icon for my root drive. I couldn't access it, unless I typed in a "/" in the url space on konqueror. It really isn't that much of a work around, but a work around it is.

I also have an install of Debian and three installs of Gentoo. The same kernels I compiled for Slackware are now running the Gentoo and the Debian machines. Neither of the other systems required me to set up initrd in order to function properly. However, they sure seem to like the SMP kernels I set up for them.

I don't know why it works the way it works. I just know that it works.

Quote:

2.)That an 'initrd.gz' file is needed to get HAL working even when using 'ext2' and support for this filesystem type is directly 'built-in' to the kernel?

If these are both true, is there any logical reason why these should be so?.

Bill.

As for reasons...I honestly have no idea. Slack-11 wasn't hamstrung by such trivialities. I almost completely gave up on Slack-12 until someone was forceful enough to make me try setting up the initrd. I'm sure you read that exchange if you read through this entire thread.

And yes, initrd is needed. Once again, I don't know the reason. All I know is that until I set up initrd, my root drive was inaccessible. I could access the fat partition and the NTFS partition without one single problem...but no dice on the root drive. Once the initrd was set up, I could navigate to any drive, and access everything, including USB stick drives, and so on.

The file system doesn't matter. I had one Slack-12 install that was set up on an ext3 partition, and two set up on reiserfs partitions. Until the initrd was installed, there was no direct access to the root drive on any of the machines.

Setting up the initrd isn't that difficult. Read the /boot/README.initrd for more details.

Blessed be!
Pappy

Bruce Hill · 01-13-2008, 02:07 AM

Quote:

Originally Posted by pappy_mcfae

Yes, it needs to be there. It doesn't matter whether or not you have more than one CPU (or a multi-core CPU). For whatever reason...and I honestly don't know the reason, Slackware 12 and its iteration of hal requires an SMP enabled kernel.

That's not correct at all ...

Although I don't have enough knowledge to tell you why that guy is wrong, I know he is wrong. You don't have to have a SMP kernel for HAL/Dbus to work, and I'm just posting evidence.

Code:

mingdao@silas:~$ cat /etc/slackware-version
Slackware pre-12.1
mingdao@silas:~$ uname -a
Linux silas 2.6.23.12 #13 Fri Jan 11 20:02:09 CST 2008 i686 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux
mingdao@silas:~$ cat kernel/linux-2.6.23.12/.config | grep -i config_smp
# CONFIG_SMP is not set

Here I am inserting an USB flash disk:

Code:

root@silas:~# tail -f /var/log/messages
Jan 13 13:00:17 silas sudo:  mingdao : TTY=pts/5 ; PWD=/home/mingdao ; USER=root ; COMMAND=/bin/bash
Jan 13 13:21:20 silas -- MARK --
Jan 13 13:41:20 silas -- MARK --
Jan 13 14:01:20 silas -- MARK --
Jan 13 14:21:20 silas -- MARK --
Jan 13 14:41:20 silas -- MARK --
Jan 13 15:01:20 silas -- MARK --
Jan 13 15:21:20 silas -- MARK --
Jan 13 15:41:21 silas -- MARK --
Jan 13 15:50:03 silas sudo:  mingdao : TTY=pts/4 ; PWD=/home/mingdao ; USER=root ; COMMAND=/bin/bash
Jan 13 15:56:38 silas kernel: usb 1-6: new high speed USB device using ehci_hcd and address 5
Jan 13 15:56:38 silas kernel: usb 1-6: configuration #1 chosen from 1 choice
Jan 13 15:56:39 silas kernel: Initializing USB Mass Storage driver...
Jan 13 15:56:39 silas kernel: scsi2 : SCSI emulation for USB Mass Storage devices
Jan 13 15:56:39 silas kernel: usbcore: registered new interface driver usb-storage
Jan 13 15:56:39 silas kernel: USB Mass Storage support registered.
Jan 13 15:56:44 silas kernel: scsi 2:0:0:0: Direct-Access     Kingston DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
Jan 13 15:56:44 silas kernel: sd 2:0:0:0: [sdb] 1952256 512-byte hardware sectors (1000 MB)
Jan 13 15:56:44 silas kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jan 13 15:56:44 silas kernel: sd 2:0:0:0: [sdb] 1952256 512-byte hardware sectors (1000 MB)
Jan 13 15:56:44 silas kernel: sd 2:0:0:0: [sdb] Write Protect is off
Jan 13 15:56:44 silas kernel:  sdb: sdb1
Jan 13 15:56:44 silas kernel: sd 2:0:0:0: [sdb] Attached SCSI removable disk
Jan 13 15:56:49 silas hald: mounted /dev/sdb1 on behalf of uid 1000
Jan 13 15:57:19 silas hald: unmounted /dev/sdb1 from '/media/disk' on behalf of uid 1000
Jan 13 15:57:28 silas kernel: usb 1-6: USB disconnect, address 5

and then as you can see, it was mounted by hald, then unmounted by the same, using that little Konqueror window that pops up with the drive options ... in Slackware-12.0 >, thanks to HAL/Dbus. For the record, I don't like it automounting, but HAL -- hardware abstraction layer -- is in itself A Good Thing (TM). That's why Windows has automatically detected your devices and loaded drivers for them ... for years!

And here I go again, mounting the Slackware-current install CD1 with the HAL demon, proving that it's not necessary to have a SMP kernel for HAL/Dbus to work in Slackware-12.0 >.

Code:

Jan 13 15:58:09 silas hald: mounted /dev/hda on behalf of uid 1000
Jan 13 15:58:15 silas hald: unmounted /dev/hda from '/media/Slackware Install' on behalf of uid 1000

and unmounting it, too.

I'm a n00b, but maybe when a real Slacker shows up he can tell us why -- and if I wanted to read a bunch, I'm sure I could find out me one self -- but I prefer taking a nap.

Edit: While we're at it, if support for the root filesystem, and for the controller for the drive where / lives is built into the kernel, there is NO initrd needed to boot it with Slackware ... or any other Linux, afaik.

If you run the Slackware generic kernel, however, it will require an initrd image ... because almost everything is modules, rather than built in.

The_Outlander · 01-13-2008, 06:24 AM

It seems to me that there are two separate issues;

1. SMP is not required to run HAL - not all the Slackware kernels require an initrd anyway, and HAL works just the same.

and quite independently;

2. The only reason to use an initrd (as pointed out) is that the Slackware-smp kernel requires it. Otherwise, it would not be possible to mount or access your / partition, whether it's on a separate primary partition or not.

They are not related - except, somewhere in this thread as I recall, it mentions optimizations to the Slackware packages for use with an smp kernel - however, an smp kernel it is not essential.

Bruce Hill · 01-13-2008, 07:24 AM

It is NOT true that the Slackware-smp kernel requires an initrd image. There are actually two Slackware-smp kernels at the moment, and only one of them would possibly require an initrd image.

Code:

mingdao@silas:~$ ls -l /boot/vmlinuz*
-rw-r--r-- 1 root root 1507832 2008-01-11 20:13 /boot/vmlinuz-2.6.23.12  <--- this is the one I built
-rw-r--r-- 1 root root 2074008 2007-12-05 07:25 /boot/vmlinuz-generic-2.6.23.9  <--- this and the other three below it ship with Slackware
-rw-r--r-- 1 root root 2182616 2007-12-05 06:55 /boot/vmlinuz-generic-smp-2.6.23.9-smp
-rw-r--r-- 1 root root 4438264 2007-12-05 07:35 /boot/vmlinuz-huge-2.6.23.9
-rw-r--r-- 1 root root 4605528 2007-12-06 04:40 /boot/vmlinuz-huge-smp-2.6.23.9-smp

Whether or not a kernel is built for SMP has nothing to do with an initrd image.

Code:

mingdao@silas:~$ less /server2/ftp/pub/Linux/Slackware/slackware-12.0/ANNOUNCE.12_0

There are two kinds of kernels in Slackware -- the huge kernels, which
contain support for just about every driver in the Linux kernel. These are
primarily intended to be used for installation, but there's no real reason
that you couldn't continue to run them after you have installed.  The
other type of kernel is the generic kernel, in which nearly every driver
is built as a module.  To use a generic kernel you'll need to build an
initrd to load your filesystem module and possibly your drive controller
or other drivers needed at boot time, configure LILO to load the initrd at
boot, and reinstall LILO.  See the docs in /boot after installing for more
information.  Slackware's Linux kernels come in both SMP and non-SMP types
now.  The SMP kernel supports multiple processors, multi-core CPUs,
HyperThreading, and about every other optimization available.  In our own
testing this kernel has proven to be fast, stable, and reliable.  We
recommend using the SMP kernel even on single processor machines if it
will run on them.

It seems there is a lot of confusion for new Linux users concerning an initrd image. Perhaps reading the files in a thread is easier than reading them on your computer:

Code:

mingdao@silas:~$ less /boot/README.initrd

Slackware initrd mini HOWTO
by Patrick Volkerding, volkerdi@slackware.com
Wed Dec 12 17:02:11 CST 2007

This document describes how to create and install an initrd, which may be
required to use the 2.6 kernel.  Also see "man mkinitrd".

1.  What is an initrd?
2.  Why to I need an initrd?
3.  How do I build the initrd?
4.  Now that I've built an initrd, how do I use it?


1.  What is an initrd?

Initrd stands for "initial ramdisk".  An initial ramdisk is a very small
Linux filesystem that is loaded into RAM and mounted as the kernel boots,
and before the main root filesystem is mounted.

2.  Why do I need an initrd?

The usual reason to use an initrd is because you need to load kernel
modules before mounting the root partition.  Usually these modules are
required to support the filesystem used by the root partition (ext3,
reiserfs, xfs), or perhaps the controller that the hard drive is attached
to (SCSI, RAID, etc).  Essentially, there are so many different options
available in modern Linux kernels that it isn't practical to try to ship
many different kernels to try to cover everyone's needs.  It's a lot more
flexible to ship a generic kernel and a set of kernel modules for it.

3.  How do I build the initrd?

The easiest way to make the initrd is to use the mkinitrd script included
in Slackware's mkinitrd package.  We'll walk through the process of
upgrading to the generic 2.6.23.9-smp Linux kernel using the packages
found in Slackware's slackware/a/ directory.

First, make sure the kernel, kernel modules, and mkinitrd package are
installed (the current version numbers might be a little different, so
this is just an example):

  installpkg kernel-generic-2.6.23.9_smp-i486-1.tgz
  installpkg kernel-modules-2.6.23.9_smp-i486-1.tgz
  installpkg mkinitrd-1.3.0-i486-4.tgz

Change into the /boot directory:

  cd /boot

Now you'll want to run "mkinitrd".  I'm using reiserfs for my root
filesystem, and since it's an IDE system the reiserfs module will be
the only one I need to load:

  mkinitrd -c -k 2.6.23.9-smp -m reiserfs

This should do two things.  First, it will create a directory
/boot/initrd-tree containing the initrd's filesystem.  Then it will
create an initrd (/boot/initrd.gz) from this tree.  If you wanted to,
you could make some additional changes in /boot/initrd-tree/ and
then run mkinitrd again without options to rebuild the image.  That's
optional, though, and only advanced users will need to think about that.

Here's another example:  Build an initrd image using Linux 2.6.23.9-smp
kernel modules for a system with an ext3 root partition on /dev/hdb3.

  mkinitrd -c -k 2.6.23.9-smp -m ext3 -f ext3 -r /dev/hdb3

The resulting initrd will automatically load the mbcache and jbd modules
used by the ext3 module.

To automatically use the current root filesystem and kernel, you can
simply use:

  mkinitrd -m ext3

4.  Now that I've built an initrd, how do I use it?

Now that you've got an initrd (/boot/initrd.gz), you'll want to load
it along with the kernel at boot time.  If you use LILO for your boot
loader you'll need to edit /etc/lilo.conf and add a line to load the
initrd.  Here's an example section of lilo.conf showing how this is
done:

# Linux bootable partition config begins
image = /boot/vmlinuz-generic-2.6.23.9-smp
  initrd = /boot/initrd.gz
  root = /dev/hda6
  label = Lnx26239smp
  read-only
# Linux bootable partition config ends

The initrd is loaded by the "initrd = /boot/initrd.gz" line.
Just add the line right below the line for the kernel image you use.
Save the file, and then run LILO again ('lilo' at the command line).
You'll need to run lilo every time you edit lilo.conf or rebuild the
initrd.

Other bootloaders such as syslinux also support the use of an initrd.
See the documentation for those programs for details on using an
initrd with them.


---------

Have fun!

Notice that Mr. Volkerding NEVER mentioned needing an initrd image BECAUSE of SMP - Symmetric multi-processing. Perhaps the best place to read about that is from the Linux kernel source:

Code:

Symmetric multi-processing support (SMP)

This enables support for systems with more than one CPU. If you have
a system with only one CPU, like most personal computers, say N. If
you have a system with more than one CPU, say Y.

If you say N here, the kernel will run on single and multiprocessor
machines, but will use only one CPU of a multiprocessor machine. If
you say Y here, the kernel will run on many, but not all,
singleprocessor machines. On a singleprocessor machine, the kernel
will run faster if you say N here.

Note that if you say Y here and choose architecture "586" or
"Pentium" under "Processor family", the kernel will not work on 486
architectures. Similarly, multiprocessor kernels for the "PPro"
architecture may not work on all Pentium based boards.

People using multiprocessor machines who say Y here should also say
Y to "Enhanced Real Time Clock Support", below. The "Advanced Power
Management" code will be disabled if you say Y here.

See also the <file:Documentation/smp.txt>,
<file:Documentation/i386/IO-APIC.txt>,
<file:Documentation/nmi_watchdog.txt> and the SMP-HOWTO available at
<http://www.tldp.org/docs.html#howto>.

If you don't know what to do here, say N.

This computer does not have two processors, or a dual core CPU. Therefore, the kernel that I built for it with the Linux kernel source from kernel.org does NOT have SMP built in. And if you fellers will slow down and check your thoughts against facts, you will find out that you CANNOT build SMP support as a module in the Linux kernel. If you choose CONFIG_SMP it can only be built in (Y), not a module (M). And if something is built into your kernel, there is no need to have an initial ramdisk image for it, because the purpose of the initrd is to load kernel modules, and something built in is NOT a module.

Hoping to clear up FUD in the 21st century ...

pappy_mcfae · 01-14-2008, 12:25 AM

Well, you know, if the people who put Slackware 12 together had taken the time to better document their stuff, then I wouldn't have had to fight for weeks to get it to work. And, I only got it to work after taking the steps indicated.

Gentoo doesn't have that problem. Debian surely doesn't have it. But Slackware 12 out of the box isn't properly set up to interface with hal. I don't care who you are, who you THINK you are, or what piece of crap computer you are using, Slackware 12 doesn't work properly out of the box!

And, after all the time put in by the underlings (such as myself), all the people who KNOW how it's supposed to work are coming out of the woodwork to tell those of us who couldn't get it to work that now we were all wrong.

Nice!

Whatever!

I'm glad I ditched Slackware for Gentoo. At least on that forum, they show respect for those who don't follow the same path, but manage to get their computers working nonetheless.

I'm wrong! Yep! Follow the words of others...listen to them. What a sorry bunch!

Pappy

Bruce Hill · 01-14-2008, 01:32 AM

Quote:

Originally Posted by pappy_mcfae

Well, you know, if the people who put Slackware 12 together had taken the time to better document their stuff, then I wouldn't have had to fight for weeks to get it to work. And, I only got it to work after taking the steps indicated.

You're probably getting tired of people pointing you to Slackware documentation to read, but:

Code:

mingdao@silas:~$ less /server2/ftp/pub/Linux/Slackware/slackware-12.0/ANNOUNCE.12_0

Among the many program updates and distribution enhancements, you'll find
two of the most advanced desktop environments available today: Xfce 4.4.1,
a fast and lightweight but visually appealing and easy to use desktop
environment, and KDE 3.5.7, the latest version of the award-winning K
Desktop Environment.  We have added to Slackware support for HAL (the
Hardware Abstraction Layer) which allows the system administrator to add
users to the cdrom and plugdev groups. Then they will be able to use items
such as USB flash sticks, USB cameras that appear like USB storage,
portable hard drives, CD and DVD media, MP3 players, and more, all without
requiring sudo, the mount or umount command.  Just plug and play.
Properly set up, Slackware's desktop should be suitable for any level of
Linux experience.

Those juicy tidbits (HOW-TO make HAL automount in a nutshell) were snipped from the Slackware-12.0 Announcement, available online or on the Slackware-12.0 CD1.

Quote:

Gentoo doesn't have that problem. Debian surely doesn't have it. But Slackware 12 out of the box isn't properly set up to interface with hal. I don't care who you are, who you THINK you are, or what piece of *@^! computer you are using, Slackware 12 doesn't work properly out of the box!

Man, that was pretty strong, Pappy.

Gentoo is not a distro prepared for use ... you must compile it all from source to get a working OS. But if you have the time and patience, it can be a nice one ... I have a friend back in the States who went from Mandrake to Gentoo ... a big step, but he loves it.

Debian is what I used between RedHat and Slackware. Those 3 different levels of packages, and the developers arguing like little kids about what should be in and what should not be in ran me away. Particularly when I wanted to "apt-get" KDE, and it was only available in Woody; but I was running whatever they named the bleeding edge at that time ... fall of 2003 ... and the devels there were too busy fussing over some libraries, so there was NO KDE except the Woody (and who wants a woody all the time?). I didn't see much use in taking the whole system back to the ancient Woody just to run a desktop environment, you know?

Just for my personal tastes, I prefer the monarchy of Slackware to the democracy of Debian ... and that's why there are different distros ... just like God made Sally's and Sue's and Sophia's, so we can have a nice set of choices.

Quote:

And, after all the time put in by the underlings (such as myself), all the people who KNOW how it's supposed to work are coming out of the woodwork to tell those of us who couldn't get it to work that now we were all wrong.

You should thank rworkman for starting this thread. Though I haven't asked him, perhaps he did it because of the many people who hadn't read the Announcement, and the Changes and Hints file, or couldn't figure out how to automount devices with HAL even after reading it. I've been told that years ago all Slackers would just tell you RTFM and never help at all.

Quote:

Nice!

Whatever!

I'm glad I ditched Slackware for Gentoo. At least on that forum, they show respect for those who don't follow the same path, but manage to get their computers working nonetheless.

I'm wrong! Yep! Follow the words of others...listen to them. What a sorry bunch!

Pappy

Well, I never meant to show you disrespect, so please forgive me. My posts were in reply to incorrect information that was posted. Someone who didn't know better might read what you posted and think it was correct. You really shouldn't come on to a Slackware forum and run Slackware down when your information is just plain wrong.

As for "listening to the words of others," if that was slung at me ... gee whiz, how can you get offended that I preferred the advice of Pat Volkerding and Linus Torvalds over Pappy McFae? Get a grip, man!

I'm more than a little hurt, too, because you didn't tell me "blessed be".

rkelsen · 01-14-2008, 02:12 AM

Quote:

Originally Posted by pappy_mcfae

But Slackware 12 out of the box isn't properly set up to interface with hal. I don't care who you are, who you THINK you are, or what piece of crap computer you are using, Slackware 12 doesn't work properly out of the box!

Pappy, I don't know what your bone of contention is here. One thing I can say for certain: Slackware 12.0 worked for me right out of the box. But that's probably because I followed the instructions. Furthermore, I don't have an initrd and my kernel is smp enabled and everything is working fine.

You have only one person to blame if it didn't work for you.

Quote:

Originally Posted by pappy_mcfae

I'm glad I ditched Slackware for Gentoo.

Would that be Gentoo "Type R" ?

Quote:

Originally Posted by Bruce Hill

I'm more than a little hurt, too, because you didn't tell me "blessed be".

That's funny.

rworkman · 01-14-2008, 08:10 AM

Quote:

Originally Posted by pappy_mcfae

Well, you know, if the people who put Slackware 12 together had taken the time to better document their stuff, then I wouldn't have had to fight for weeks to get it to work. And, I only got it to work after taking the steps indicated.

You mean the steps indicated in the documentation?

The only reason for this thread was to clarify the issue of "groups" output versus the actual content of the group file and how it *might* cause a problem *if* instructions weren't followed and necessary users added to the relevant lines in /etc/group.

Quote:

Gentoo doesn't have that problem. Debian surely doesn't have it. But Slackware 12 out of the box isn't properly set up to interface with hal. I don't care who you are, who you THINK you are, or what piece of crap computer you are using, Slackware 12 doesn't work properly out of the box!

Yes, it does, IF the directions are followed. Out of the box, HAL is enabled, but users are not allowed to mount devices. This is the system administrator's responsibility to decide if and/or which users can do that.

Quote:

I'm glad I ditched Slackware for Gentoo.

Somehow, I'm guessing that others share your gladness.

The_Outlander · 01-14-2008, 07:12 PM

Quote:

It is NOT true that the Slackware-smp kernel requires an initrd image. There are actually two Slackware-smp kernels at the moment, and only one of them would possibly require an initrd image

Your absolutely right Bruce. I was referring to the generic kernel - specifically the generic 2.6.21.5-smp kernel - which I think was the centre of Pappy's discussion.

The initrd issue is clear cut. If your file system is compiled as a module, you need an initrd - the initrd loads the necessary modules at boot - otherwise it is not required.

Hey Pappy, referring to your last post. And I'm not sure what your reaction may be, but, my understanding, is that, more than 50% of communication is non-verbal - a significant portion is missing in a written forum, therefore, I assume that people mean well, unless otherwise specifically stated.

You are right Linux documentation can be difficult to follow at times. In some cases, the writers assume a prerequisite level of experience. Slackware is probably an example of that.
Gentoo documentation is well structured and clear, in most cases - no argument there - much of the 'difficult" hardware on my machine is running thanks to Gentoo and other how to's.

Linux is a community with varying degrees of resources - good documentation is expensive to produce. I work in a document intensive industry that, depends on accurate, unambiguous documentation that, provides little opportunity for various interpretations - every thing must be clearly spelled out - it's a matter of safety. The resources required to produce, proof read and publish are enormous. Contribution is a solution for the Linux community, but whatever you propose must be reviewed by someone, to ensure that it is accurate, and not easily open to interpretation. I'd expect to take some flack - it's meant well, in most cases!

Cheers,

Have a good day.

Bruce Hill · 01-14-2008, 07:53 PM

The_Outlander,

Good post. I'm too harsh ... admittedly. My apologies to Pappy and others offended.

Documentation is a must for new users, of anything. If we really want someone to use our product, we must make it clear what they are to do. And programmers, by and large, are not good at writing understandable docs for the normal user. Especially when we have been "dumbed-down" on purpose by Microsoft.

The_Outlander · 01-14-2008, 09:01 PM

Bruce,

I think so too.

The other aspect is the production of documentation by well meaning, but less than expert users, and the need to review every contribution is time consuming for people who are most probably stretched to the limit, anyway.
Conversely, in order to re-write documentation, the writer needs to be reasonably proficient in the subject matter, in order to accurately reflect that intended by the original author. It is true that Microsoft has dumbed us down, but most newbies need to start somewhere with Linux.

In this busy world - particularly with adults (not so much time on their hands), clear concise documentation is a good and positive introduction to their first learning experience.

There is a need to spell things out - otherwise we might suggest, Ubuntu, or a similar distro, but is that what we really wan't. Would it be better to encourage newcomers to use Slackware, and provide the documentation required to get a brand new recruit on their way, and progressing upwards, along the learning curve - rather than assuming a level of insight and expertise in the first place, only to be discouraged.
That is not dumbing down - it is catering to the learning requirements of most people - the experts can skip the basics!

To create a strategic advantage and have people use our software, we need to produce something that differentiates our product from the others, even in a community such as Linux, which is becoming a viable choice in many applications. Looking over the forums defines what the state of Linux is, and possibly what it needs to be - that is, accessible to ordinary folks who, don't necessarily possess the level of expertise shared by people in this forum, for example.
Should we by default leave that to Microsoft, and allow them more of the market share?

Cheers

Dan Suson · 01-14-2008, 09:30 PM

Quote:

Originally Posted by rworkman

Re: entries in /etc/fstab

Okay, here's another hot topic that seems to be troubling a lot of people. From CHANGES_AND_HINTS.TXT:

Code:

Note that HAL will honor settings in /etc/fstab if a device is 
present there, so you could technically have removable devices 
defined in /etc/fstab, but if the fstab settings do not allow normal
users to mount them (with the "user" or "users" option), then HAL/dbus
will not allow them to be mounted either.
Also note that you will need to run "/etc/rc.d/rc.messagebus reload" 
after adding any users to plugdev, power, or video groups so that it 
re-reads the /etc/group file.

Put yourself in the cdrom and plugdev groups regardless, but here's an example to hopefully clarify what's written above.

Without a custom udev rule and an fstab entry, my Sandisk Cruzer Micro will be automatically assigned the next available /dev/sd* node by udev, and then I can mount it using HAL (well, actually DBUS via either KDE or XFCE, but that's inconsequential details for now) at /media/CRUZER_1024 (note that "CRUZER_1024" is the filesystem label that I put on it). The device will be mounted in /media with whatever name the filesystem label has.

Suppose I like for the device to be mounted in some other location for whatever reason. I would create a custom udev rule (how to do that is left as an exercise to the reader - there's ample documentation available on the subject) to assign a persistent /dev/cruzer1024 symlink to the device node, and then I would add the device to /etc/fstab like this:

Code:

/dev/cruzer1024 /mymountpoint vfat noauto,user,rw,dmask=0022,fmask=0133 0 0

At this point, I can mount/unmount the device from a command line *exactly* like I could in Slackware 11.0, or I can *still* use HAL (subject to same "actually" comment as above) to mount the device, and it will be mounted to the place and with the options specified in /etc/fstab.

I've tried to follow these suggestions. I've been able to get hald to automatically mount external drives when they are attached after booting, and I can read and write to these drives without a problem. I have three external hard drives, each with a label, that I need to mount frequently, but not always. I have added some code to rc.local to see if the drives are on, and if so they are mounted by label to the appropriate mount directory in /mnt. I use labels so that it doesn't matter what order or which other drives are already detected by the system. What I would like is for hald to mount these drives to the same places when I turn on the drives after starting the system. My fstab contains the following commands:

Code:

# Local removable file systems
LABEL="Music"    /mnt/Music       ext3        noauto,owner,users 0   0
LABEL="Work"     /mnt/Work        ext3        noauto,owner,users 0   0
LABEL="Backup"   /mnt/Backup      ext3        noauto,owner,users 0   0
# /dev/disk/by-label/Music /mnt/Music ext3 noauto,owners,users 0 0
# /dev/disk/by-label/Work /mnt/Work ext3 noauto,owners,users 0 0
# /dev/disk/by-label/Backup /mnt/Backup ext3 noauto,owners,users 0 0
#/dev/cdrom       /mnt/cdrom       auto        noauto,owner,ro    0   0
#/dev/fd0         /mnt/floppy      auto        noauto,owner       0   0

However, when I mount one of the drives (for example the Work drive) after system startup, the drive is mounted at /media/Work. My mtab is

Code:

/dev/hda2 / ext3 rw 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
usbfs /proc/bus/usb usbfs rw 0 0
/dev/hda3 /home ext3 rw 0 0
/dev/hda5 /usr/local ext3 rw 0 0
/dev/hda6 /mnt/vmware ext3 rw 0 0
none /dev/shm tmpfs rw 0 0
none /proc/fs/vmblock/mountPoint vmblock rw 0 0
/dev/sda1 /mnt/Backup ext3 rw,noexec,nosuid,nodev 0 0
/dev/sdb1 /media/Work ext3 rw,nosuid,nodev,data=ordered 0 0

As you can tell from the fstab, I tried using the /dev/disk/by-label to force the mount to go to /mnt/Work. In this case mtab wouldn't show the mount and konqueror would open with an empty window.

What am I missing?

Alien_Hominid · 01-14-2008, 10:18 PM

Pappy, try LFS. Then you'll know how linux system works and you'll know when something is needed or not and why.

The_Outlander · 01-15-2008, 01:13 AM

This may be of help. http://ubuntuforums.org/archive/index.php/t-223310.html

KillrBuckeye
July 28th, 2006, 03:47 PM
The volume labeling method worked for me, but I had to give up on using it in conjunction with fstab. Once all the volumes were labeled appropriately, the automounter created directories in '/media' corresponding to each of the labels, which is exactly what I wanted. All I had to do was change ownership and permissions on the directories, and I was set. For some reason if I kept the fstab entries, it seemed to conflict with the automounter and I was getting duplicate mounts and other weird problems.