SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
This what /boot looks like after a successful install of Slack 12.
This is new to me, my last install being 10.2 and this is the first
time I have seen a separate system map associated with a specific
kernel, not to mention the addition of a config file for each one.
Even when I previously rebuilt a kernel I never changed the system map
or had to worry about config. I'm not sure I even know what the
config file is or is supposed to do.
As I recall, a specific system map for a particular kernel compile could
remain in the /usr/src tree and it would not cause a problem with boot.
It looks like I may have to compile a kernel from source since I am
getting too many error messages from the current setup.
While I am no stranger to compiling a kernel, the addition of a
separate system map and config file gives me pause. I'm not sure
just how to go about it under the new scheme.
As you can tell from the above, I am booting the
vmlinuz-huge-smp-2.6.21.5-smp kernel version and I haven't yet
changed the symlinks to try the others. I will do that of course
but I think I would rather compile a new kernel which includes
only what I need for my machine. I do however wish to leave the
other kernels as is.
Anyone able to explain these new additions and how to recompile
properly?
You are getting errors at boot because you are using the huge kernel.
From Slackware-12.0 CHANGES_AND_HINTS.TXT:
Code:
It is recommended that you use one of the generic kernels (either the plain
kernel-generic or kernel-generic-smp) for daily use. For most systems,
you should use the generic SMP kernel if it will run, even if your system
is not SMP-capable. Some newer hardware needs the local APIC enabled in
the SMP kernel, and theoretically there should not be a performance penalty
with using the SMP-capable kernel on a uniprocessor machine, as the SMP
kernel tests for this and makes necessary adjustments. Furthermore, the
kernel sources shipped with Slackware 12.0 are configured for SMP usage,
so you won't have to modify those to build external out-of-tree modules
(such as NVidia or ATI proprietary drivers) if you use the SMP kernel.
If you are using one of the non-SMP kernels (huge.s or generic.s) and need
to compile third-party modules (such as the proprietary NVidia driver),
have a look in /extra/linux-2.6.21.5-nosmp-sdk/ for information on what
is needed to build them.
As stated earlier, it is recommended that you use one of the generic kernels
rather than the huge kernels; the huge kernel is primarily intended as
an "installer" and "emergency" kernel in case you forget to make an initrd.
However, if you do use one of the huge kernels, you will likely encounter
errors like this:
kobject_add failed for uhci_hcd with -EEXIST, don't try to register
These occur because the respective drivers are compiled statically into the
huge kernels but udev tries to load them anyway. These errors should be safe
to ignore, but if you really don't want them to appear, you can blacklist the
modules that try to load in /etc/modprobe.d/blacklist. However, make sure you
remove them from the blacklist if you ever decide to use the (recommended)
generic kernels.
The System.map file in /boot is not necessary. Your system will find it with the
kernel anyway. It was there in Slackware-10.2:
Those errors with huge (if they're what I think they are) are harmless [to do with "huge"ness of so much many drivers are compiled into the kernel then udev comes along and tries to load (as a module, same thing as what's compiled into kernel) a driver(s), "oop" it's already in there (the error) IOW "doubling up (is redundant)" but AFAIK this doesn't hurt anything.
Mine did that.
I long ago decided to try the Slack 12.0 generic-smp kernel.
So, I made an initrd for that kernel. Then I added said kernel and its initrd to lilo.conf
generic-smp long since been my default kernel with the huge is still a choice during bootup.
I did nothing more than the above, ie nothing done with map or others.
I realize that the errors I am getting can probably be safely ignored
(e.g. kobject_add failed), but I am more curious about System.map and
config.
I realize that System.map is simply a symbol table and usually resides
in the /usr/src tree after a recompile and which the kernel will find,
if needed, upon boot. However, I am wondering if it isn't better to copy
the new System.map to /boot. In other words, is it more efficient to
have it in a place where it can be more easily found?
Secondly, what is config and what is it used for? Since it is listed in
/boot, it leads me to believe that it is necessarily a part of the boot
process.
I have also never seemed to need an initrd to boot a kernel. Maybe a
generic one is used automatically, but I have always been under the
impression that initrd simply loads certain device drivers and other
software bits which may not be available at the inception of boot.
I'm really not certain, but what is the point of including initrd in
lilo.conf?
The System.map file is found in three different ways, but atm
I can't remember them. It is not needed to be in /boot. If you
want more of an explanation, Google is your friend. It is found
in the top level directory of the kernel source, wherever you
build your kernel (~/kernel/linux-2.x.y/ for me).
The config files are the configuration files for those kernels.
You will probably never need them, but if so, that is where Pat
has chosen to put them for you.
An initial ram disk image (initrd) is need to load modules before
your root partition is mounted. There is /boot/README.initrd in
Slackware to explain this.
Last edited by Bruce Hill; 05-02-2008 at 09:06 AM.
Early boot process/happenings ie the mount / and read from / portion of the boot
"Early boot process/happenings" ie the "mount / and read from /" portion of the boot process
There's no generic initrd auto used.
Yes, an initrd loads things that *will* (not may) be needed.
Importantly, (given Slack 12.0 generic-smp kernel) it's that some hardware and file sys combos will load and run without an initrd while other (and different) hardware and file sys combos will *not* load and run without an initrd.
As far as 100% of *Whatever*, in the way of support (drivers, file sys support, and etc.), that is needed for this early boot stuff ie to get the "/" partition mounted and reading from "/" -- such support must come from either (1) being all, 100% of it compiled into the kernel or (2) *part* of it compiled into the kernel and in this case the other part *must* be provided by initrd.
My hardware and file sys combo in conjunction with the Slack 12.0 generic-smp kernel falls into the 2nd of those two different scenarios (initrd is mandatory or else kernel will panic).
(whenever an initrd is needed) what is the point of including initrd in lilo.conf?
That's the .conf file where lilo looks when lilo (this is a part of the boot process) goes to load an operating system.
lilo's job is to load an operating system (also offer choice of more than one kernel and/or OS, ie, lilo can load MS Windows).
Mine, kernel will panic (as in *no running OS* gets loaded) if initrd is not found.
Panic (unless initrd) because: I use (1) ultra 160 scsi hard drive and (2) the Linux EXT3 file system. The Slack 12.0 generic-smp kernel *does not* have support for these two compiled in. So, OS can't get "/" partition mounted and read from "/" without said support of which all of this takes place relatively early on in the boot process.
Oh, the EXT3 would get used/mounted as EXT2 -- but I want the journaling and EXT3 features/characteristics. IOW if I used IDE (pata, not sata) instead of scsi -- then, *without an initrd*, my sys would boot and run but my file sys would be EXT2 not EXT3.
Thanks for your input. It sparked a little more interest and I found
myself looking at the Slackware-HOWTO, which I thought was an old
document carried forward unchanged from year to year. Much to my
surprise it contained some pretty detailed descriptions of the kernels
and the need for an initrd for the generic ones.
So I think I'd like to try the generic kernels, but I am now faced with
creating my own initrd according to the HOWTO:
Quote:
A disadvantage is that the generic kernels no
longer include *any* filesystems, so old initrd.gz files are
not usable (they would have needed new modules anyway), and
it is trickier to get a custom binary or modules or whatever
into the installer for guru-install purposes.
After reading README-initrd, I am less sure of how to create an initrd
for my purposes. It would appear that the only purpose of initrd
in this instance is to provide file system code for ext3. Of the two
examples given I am not sure which one I should use.
If you recompile the kernel properly, and build in support for
your / filesystem and the drive containing it's controller, you
will not need an initrd.
What type of filesystem do you use for root? Once you know that,
you can issue
Code:
less /boot/config-generic-smp-2.6.21.5-smp | grep -i reiserfs
where you substitute the type of your filesystem where I put
reiserfs. If it is M, then you need it in the initrd. If it is Y,
then you don't need it in your initrd. In the above example I see
CONFIG_REISERFS_FS=m so if my / partition uses reiserfs, it will
need to be put into the initrd to run the Slackware generic kernel.
The other thing you need is support for the controller of the drive
which contains your / filesystem. For example, this computer:
Code:
mingdao@silas:~$ /sbin/lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South]
00:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit Ethernet Controller (rev 13)
00:0c.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
00:0c.1 Input device controller: Creative Labs SB Audigy Game Port (rev 03)
00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South]
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
00:11.6 Communication controller: VIA Technologies, Inc. AC'97 Modem Controller (rev 80)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation GeForce 7300 GT (rev a2)
has both an IDE interface and a SATA RAID controller. Slackware is
on a SATA drive, so I need support for the VIA VT6420 chipset. Issue
Code:
less /boot/config-generic-smp-2.6.21.5-smp | grep -i via
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
CONFIG_VIA_FIR=m
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_SATA_VIA=y
CONFIG_PATA_VIA=m
CONFIG_VIA_RHINE=m
CONFIG_VIA_RHINE_MMIO=y
CONFIG_VIA_RHINE_NAPI=y
CONFIG_VIA_VELOCITY=m
CONFIG_HW_RANDOM_VIA=m
CONFIG_I2C_VIA=m
CONFIG_I2C_VIAPRO=m
CONFIG_SENSORS_VIA686A=m
CONFIG_AGP_VIA=m
CONFIG_DRM_VIA=m
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_VIA82XX=m
CONFIG_SND_VIA82XX_MODEM=m
shows me that support for CONFIG_SATA_VIA=y is built into the kernel.
Therefore, I have support for my drive's controller, and will not need
to build that into an initrd.
Last you need to know what partition contains your / filesystem. Issue
Code:
anna@peter:~$ mount
/dev/hda8 on / type jfs (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hda9 on /home type jfs (rw)
/dev/hda1 on /Windows type vfat (rw)
/dev/hda5 on /WinXP type ntfs (ro)
/dev/hda6 on /Storage type vfat (rw)
192.168.1.11:/home on /serverhome type nfs (rw,rsize=8192,wsize=8192,hard,intr,addr=192.168.1.11)
192.168.1.11:/backup on /server1 type nfs (rw,rsize=8192,wsize=8192,hard,intr,addr=192.168.1.11)
192.168.1.11:/backup2 on /server2 type nfs (rw,rsize=8192,wsize=8192,hard,intr,addr=192.168.1.11)
and you will see that on Anna's computer, the / filesystem uses JFS
and is located at /dev/hda8 (my computer uses LVM and LUKS, so it's
output shows "/dev/mapper/vg-root on / type jfs (rw)". I chose to
give you an easier example of "mount" output.)
You take those three factors and make your initrd with this command:
where /dev/hdb3 is the partition that will be mounted as /
It appears that command should do it for you.
--
Yes, *of course*, *absolutely*, as in:
Quote:
I suppose if I were to recompile the kernel, I wouldn't need an initrd at all.
Perhaps an easy compile would be to grab the Slack source for 12.0 generic-smp, copy its config and then when you edit the config, all you'd need to add is ext3 file sys support (given if you're using ext3 file sys) then compile. IOW only alteration is adding ext3 file sys support.
initrd was **fast and easy** for me (might as well have some slack time for me!!!) I *need* this (time) since I too often need many more around to its!!!!
Wanna manage my 'puters for me? Wanna put my Intel dual core hardware (motherboard, etc.) into a 'puter case for me, then install Slack 12.1 then install Xen, Vmware server, KVM.
Wanna learn me which of those virt. machines will be my fav Virt Machines?
I got too much to do (not *just* computers) (but I *most certainly* [I can't go back] [IOW after learning Linux/Unix way, Slackware, etc.] I'm spoiled, couldn't use MS Windows for very long even if I was forced to.
If it is M, then you need it in the initrd. If it is Y,
then you don't need it in your initrd.
I finally realized that the "config" files in /boot are
nothing more than kernel compile configuration files. I guess
Pat put them there for reference purposes, but the symlink
sort of fooled me. I thought that the files were somehow used
in the boot process.
Anyway, if I
Code:
less /boot/config-generic-smp-2.6.21.5-smp | grep -i ext3
or
less /boot/config-generic-2.6.21.5 | grep -i ext3
So I will have to build a initrd for ext3. After reading the
mkinitrd man page, I suppose I could use either of the
commands mentioned previously but the following seems to be
the most specific (altered to hdb2 for my machine):
I was puzzled about one thing. My kernel sources (usr/src/linux-2.6.21.5)
did not seem to match the description's above. I was under the mistaken
impression that mkinitrd would compile the module from source code
until I read that the -k switch looks in /lib/modules for one already compiled.
Sometimes my uninformed suppositions lead to important distinctions. This tidbit
of information is well worth knowing.
One final (hopefully) question here. Would there be any reason that I couldn't
make one initrd from either 2.6.21.5-smp or 2.6.21.5, and use it for both?
I can't thank everybody enough for all the great input I have received
here. I had fully expected to receive the usual limited responses to
my initial question, but am delighted that this thread has blossomed
into the very informative narrative it is. I have never been happier
about pursuing the answer to a mind numbing (at least for me)
question, that I probably haven't worded very well to begin with.
You are correct ... if it is M, then it is a module. If it is Y,
then it is statically built into the kernel. If it is a module,
and you need to to mount/read your / filesystem, then you must
use an initrd image. If it is built into the kernel (Y), then you
do not need an initrd image.
The symlinks to System.map and config in /boot are not important,
but the symlink to vmlinuz is ... that's your kernel. But note
that you can boot a kernel NOT symlinked to vmlinuz, so
long as you have the full path in LILO. Here's my present file:
Code:
mingdao@silas:~$ cat /etc/lilo.conf
# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
boot = /dev/sda
compact # faster, but won't work on all systems.
# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used. We don't specify it here, as there's just one column.
bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
bmp-timer = 65,27,0,255
# Standard menu.
# Or, you can comment out the bitmap menu above and
# use a boot message with the standard menu:
#message = /boot/boot_message.txt
# Append any additional kernel parameters:
append="panic=15 vt.default_utf8=1"
prompt
timeout = 50
# default = Slack-libata
# VESA framebuffer console @ 1024x768x64k
vga = 791
# ramdisk = 0 # paranoia setting
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz-2.6.25.1
initrd = /boot/2.6.25.1-initrd.gz
root = /dev/vg/root
label = Slack-2.6.25.1
read-only
image = /boot/vmlinuz-2.6.25-libata
initrd = /boot/2.6.25-libata-initrd.gz
root = /dev/vg/root
label = Slack-2.6.25
read-only
image = /boot/vmlinuz-generic-smp-2.6.24.4-smp
initrd = /boot/initrd.gz
root = /dev/vg/root
label = Slackware
read-only # Partitions should be mounted read-only for checking
# Linux bootable partition config ends
# Windows bootable partition config begins
other = /dev/sda1
label = Windows
# map-drive = 0x80
# to = 0x81
# map-drive = 0x81
# to = 0x80
table = /dev/sda
# Windows bootable partition config ends
Use the generic-smp-2.6.21.5-smp kernel, because if you use the
uniprocessor kernel you can have other issues; such as trying to
install the Nvidia proprietary, free drivers. That is also noted
in CHANGES_AND_HINTS.TXT iirc.
What about your hard drive controller?
And also, Slackware-12.1 has been released. If you have everything
backed up, I would seriously consider getting it and installing a
new, fresh, Slackware.
Glad we were able to help you ... if anything is not clear, continue
to ask until it is cleared up for you.
No kernel modules found for Linux 2.6.21.5
mount: mounting /dev/hdb2 on /mnt failed
ERROR: No /sbin/init found on rootdev (or not mounted) Trouble ahead.
Kernel panic - not syncing: Attempted to kill init!
So the initrd built from 2.6.21.5-smp will not work for the non-smp generic
kernel. Hardly a surprise.
Renamed initrd.gz to initrd-smp.gz and reran the build with:
Altered lilo.conf to use the separate initrd's for each kernel, reran LILO and
can now boot both generic kernels.
Although I didn't look at the config IDE sections for each generic kernel, it
appears that IDE was built into the kernels (which you would expect) since I
had no trouble booting w/o any IDE configuration in initrd. I guess SCSI and some
of the more exotic setups such as fibrechannel and maybe RAID would require
some sort of inclusion in initrd. But as you say, if config says =y, you don't
need it in initrd.
I should also point out that it apparently doesn't matter where System.map for
these kernels reside. The System.map symlink in /boot remained unchanged
Code:
System.map -> System.map-huge-smp-2.6.21.5-smp
and either this was ignored and the kernel found the right table or it is
simply unnecessary.
This has been a tremendously informative exercise for me and wish to etend
my appreciation again.
generated a /boot/initrd.gz , you can run the following command to add modules for the 2.6.21.5 kernel as well:
Code:
mkinitrd -k 2.6.21.5 -m ext3
By leaving off the "-c" switch (shorthand for "create" - run "mkinitrd --help" to see the parameters explained), mkinitrd re-uses the existing directory tree /boot/initrd-tree and merely adds the new kernel modules there before re-building the initrd.gz file from that directory tree.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
