I added devfs with my new kernel because the first guy who helped me build a new kernel for this comp told me to do so (but I don't know why). I'll read about devfs and see if I should be using it now or not.

Yes, but it doesn't here, unfortunately - unless I add the device. Does that tell me that there is a problem between /sbin/fdisk and /proc/partitions?

I booted into my old 2.4.22 kernel and fdisk -l worked fine from the command line. However, the 2.4.22 won't boot into X anymore. It gives the Nvidia module error. It was installed and worked fine when I was using that kernel. Don't know why it doesn't work now.

I'm not sure I know what a binary is, or to which binary you are referring. For /sbin/fdisk the size on her machine is 77612 and on my machine it's 86044. Sorry for my ignorance. I'm reading and trying to grow out of it.

*Another question. Isn't your new kernel size supposed to be smaller than your old kernel? What about this ->

devfs basically replaces the old /dev structure,
and only displays devices that are actually present.

Some of the things it does are ugly, though,
the name for hdd and scsi devices for instance ;)


/proc/partitions
looks like mine on the box with devfs (only
one of them ;} and I won't do it again)....
with TWO differences ....
I don't have any "empty partitions", and some
of my partitions are flagged major 22 rather than 3
which only means that you have both hdd's on the
same cable :) whereas I split them out :)

How did you upgrade the kernel? If the module for the nVidia
doesn't work that probably means that there are module
dependencies between a driver that gets loaded from X
but only exists in one version ... supposedly you should
have one in both /lib/modules/2.4.22/kernel/. and
/lib/modules/2.4.23/kernel/. somewhere ...


Cheers,
Tink

I got 2 identical hdd's, one cdrom and one dvd-rw. Should I have one hdd as primary and one cd as slave on each controller?

Downloaded linux-2.4.23.tar.bz2 and then cd /usr/src then rm linux then tar xjvf linux-2.4.23.tar.bz2 then ln -s linux-2.4.23 linux then make menuconfig then make dep then make clean then make bzImage then make then make modules then make modules_install then cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz-new-2.4.23 then cp /usr/src/linux/System.map /boot/System.map-new-2.4.23 then edit /etc/lilo.conf then run lilo then restart.

Code:

If the module for the nVidia
doesn't work that probably means that there are module
dependencies between a driver that gets loaded from X
but only exists in one version ... supposedly you should
have one in both /lib/modules/2.4.22/kernel/. and 
/lib/modules/2.4.23/kernel/. somewhere ...

Interesting...uuummm...There is a difference. But tell me how it was working before I upgraded the kernel?
After the initial Slack install I ran ->
and I did that after I rebooted after installing the new kernel, also - taken directly from /root/.bash_history.

And another question, if I may digress. Why is my new kernel image larger than my old kernel image? Maybe because I compiled most everything into my kernel with (Y) instead of using (M) for modules? And which is preferrable? I guess I would have to find the command to run to show me what procs are running, eh?

I appreciate your help.

Whats happenin' Chinaman? I still have no idea whats up with the fdisk thing, but as for the kernel upgrade: Drivers that arent included in the kernel need to be reinstalled after a kernel upgrade/recompile. I had to do it when I recompiled for my ALSA and Radeon stuff.

Compiling directly into the kernel as opposed to a module seems to be mostly a matter of preference. I usually use modules though, because they can be removed/inserted at will. Makes it easier for replacing older drivers, troubleshooting, or adding/removing hardware. All this can be done without a recompile when using modules.
The bit of size difference you are seeing could be from the difference in whats included in .23 vs. .22. When I ran Slack 9 I needed to compile 2.4.22 to get my hardware all working properly and noticed a size increase as well even though I loaded the old config file then removed some of the things I knew I didn't need.

Would make sense, but is probably not the
cause of the fdisk problem.

I've had one case of nvidia's module being
self-destroying in the past, I had to work around
it by copying it to a different location, and run
a cp from rc.modules each boot ... was really
annoying, had never seen anything the like
before.

Well, the advantage is that's it's slightly faster to
boot if all drivers are built-in, and it's more secure
because module-exploits become impossible. The
downside is that all drivers are loaded all the time,
rather than on demand - memory usage.


Sorry I can't give you any other hints with
the fdisk-problem though. But I'd guess that
it must have to do with the newly compiled
kernel.


Cheers,
Tink

Thanks, Tink - and everyone else. I appreciate all your help.

I've used Windoze for many years, and I am now migrating to *nix. But I don't want to run *nix with a Windoze mentality of reinstalling whenever something doesn't work just right, so I've read, and will continue to do so, looking for the cause of this little problem.

I've been using devfs without any fdisk -l problem for about 5 months and with Debian and Slackware.

Today I'll download the new stable 2.6 kernel and recompile. Perhaps that will solve the issue. I'll try running this one with modules instead of everything installed. I'll post back and report if fdisk -l works properly - as it still does in my 2.4.22 kernel.




And, can someone who is a true Slacker tell me if they'd recommend compiling the kernel from the .tgz file or from a .bz2 file. And, can a .tgz file be run just as well with tar -zxvf as with installpkg? What's the rule of thumb there? (Not that this matters today, since there is no .tgz for this kernel yet. I just want to understand what a long time Slacker thinks about these two methods.)

Well, basically it's just a matter of naming and the
compressor you use. tgz = tar.gz, using gzip as
opposed to bzip2 (tar.bz2) ... in slack's case the
tarballs usually also have a script in them (doinst.sh)
that is being run from installpkg, thus a simple
tar xvzf <suchandsuch>.tgz will not do quite the
same as the installpkg. If you're just looking at the
kernel source and the installation thereof it's probably
just that Volker has a slightly different kernel than
the stock-linux would have.


Cheers,
Tink

Thanks, Tink. What are your thoughts on the 2.6.0 kernel?

Honestly? :)

I haven't tried too hard to make it fly yet.

[philosophy mode]
I'm a very conservative person. As opposed
to the "Zeitgeist" I don't fall for the stupid idea
that newer always means better. I'd rather go
with Kung-Fu-Tse here and thoroughly think
through the consequences of what I am
about to do, and whether I will have actual
benefit from a change. ;} The fact that a majority
of people believe that change is a value in
itself is rather strange, if not to say stupid,
in my opinion. They're probably just victims
of the general principles of marketing, though
(which doesn't necessarily make them appear
brighter ;}).
[/philosophy mode]


Cheers,
Tink

Thanks, Tink.

I come here to LQ from too many years in the Windblows slum! But even there, I've never been the one to try their new marketing tricks (such as the eXPerience manure) until at least SP1 (ver B in the old days).

Now, it seems I was about to get caught on the "Johnny come lately" bandwagon here in the *nix world. Thanks for the wakeup call with your honest opinion.

Heh - I prefer to call it eXPeriment (and as much as
I've seen of it so far it's a complete and utter failure,
too, SP1 and all - same amount of reboots a day,
still blue-screens in normal working environments).

Pleasure mate ... it hasn't been that long that I
woke up and realised that I'm chasing phantoms
in the IT department ... I mean, it's not like I use
to take my car to the shop every 8 months to
get a faster engine, or replace my VCR because
it's successor has a tuner that can receive 50
instead of 40 channels [when I never watch more
than two of the already accessible ones in the
first place ;}].



Cheers,
Tink

Yes, you know in the other thread I told you I was going to try Slack and my intention was to get 8.1; but I mistakenly got 9.1 instead. I'm having many little quirks show up; however, I can see the format c:/q day (I'll actually write them both to zero's) when I remove Micro$loth from my comps on the horizon.

Quirks such as I'm typing in KMail and I hit Enter twice for a new paragraph and the Konqueror file browser opens two instances to the Trash folder. Seems that the Trash can on the KDE desktop was highlighted, though I've never intentionally even touched the guy with my mouse. Many little quirks like that, but I can overlook them. I see brighter days on my horizon! I've still got a lot of configuring to do, but it's all enjoyable, and I really like learning.

As for the modules and kernel things, I'll probably just do the 2.4.23 one again rather than getting a newer one. My buddy Scruff's going to give me a report on what he finds in 2.6.0, but like you, I haven't read anything I need from it.

Yes, I agree. I don't need but about 7 - 10 applications myself. I like where your cp says "fully content."

What's happening Chinaman?

I actually lost my nerve last night after we talked. Well, specifically I wanted to have a good back-up, clarify my own reasons for bothering with 2.6, and look into the new/improved compile methods for 2.6 before I actually went through with it

While I totally see where Tink is comming from, I also see many reasons for upgrading to 2.6.

For instance: 2.6 is preemptible. This means that the kernel can now be interrupted midtask so an application can complete whatever it may be doing at the moment. This should make for a faster "feel". It could also prove to be a disaster, but I won't know till I try

I am going to quote some stuff here that I read in a very descriptive article on 2.6. I am no kernel expert so everything I have learned about 2.6 has been interpreted from the net anyway... The article can be seen in it's entirety @ www.knigget.net/wwol26.html

"On the application software side, another change that will help make Linux programs more responsive (if they use the feature) is support for new "futexes" (or "Fast User-Space Mutexes") Futexes are a way in which multiple processes or threads can serialize events so that they don't trample on each other (a "race condition")."

"Dedicated storage busses, such as IDE/ATA ("Integrated Drive Electronics/Advanced Technology Attachment") and SCSI ("Small Computer System Interface"), have also received a major update during the 2.6 cycle. The most major changes are centered around the IDE subsystem which has been rewritten (and rewritten again) during the development of the new kernel, resolving many scalability problems and other limitations. For example, IDE CD/RW drives can now be written to directly through the real IDE disk driver, a much cleaner implementation than before. (Previously, it was required to also use a special SCSI-emulating driver which was confusing and often difficult.)"

"When dealing strictly with conventional Linux filesystems, the extended filesystems (either "ext2" or "ext3") are the systems most associated with a core Linux system. (ReiserFS is the third most common option.) As these are the filesystems that users care about the most, they have also been the most improved during the development of Linux 2.6. Principal among these changes is support for "extended attributes", or metadata that can be embedded inside the filesystem itself for a specific file. Some of these extended attributes will be used by the system and readable and writable by root only. Many other operating systems, such as Windows and the MacOS, already make heavy use of these kinds of attributes."

Audio & Multimedia: "Key among them are support for newer hardware (including USB audio and MIDI devices), full-duplex playback and recording, hardware and non-interleaved mixing, support for "merging" sound devices, and other things. Whether you are an audiophile or just someone that likes to play MP3s, Linux's improved sound support should be a welcome step forward" (2.6 also includes ALSA support)

I am the biased reporter here so these are some of the things I found most interesting and useful. There is quite a bit more though (this article alone is extremely detailed and longggg) and much of it will add to a more responsive feel even on desktop systems, as well as stability and security type features.

Compiling 2.6 is definitely on my agenda for this weekend so hopefully I'll have a more personal opinion to give later on.

Connect failed

Your request for http://www.knigget.net/wwol26.html could not be fulfilled, because the connection to www.knigget.net (unknown) could not be established.


I'll be waiting for your report. I couldn't read the knigget nuggets, though. I even tried with a proxy server. Many sites are blocked by the Chinese firewall.

My mistake: http://kniggit.net/wwol26.html
No 'www'. Sorry