Pages

Search

Dunmon for Linux - Forums Linux

Dunmon for Linux - Forums Linux

Dunmon for Linux

Posted: 13 Sep 2005 08:28 PM PDT

Larry Blanchard wrote:
 

pppload
kpppload
xisdnload (if your modem is ISDN)

The following tools may also be useful:

nwload
gnetload
knetload
xnetload
trafflogger


---<(kaimartin)>---
--
Kai-Martin Knaak
http://lilalaser.dyndns.org/blog

Grub config

Posted: 13 Sep 2005 01:30 PM PDT

On Tue, 13 Sep 2005 22:30:21 +0200, Paul Floyd <0.0.1> wrote:
 

I agree that the Grub documentation is hard to read for a
couple of reasons, but I feel I cannot do a complete new
Grub documentation for you here.

I haven't read the Grub documentation for about two years or
so, so things may have changed, but what I used to find most
confusing is that this documentation uses old words in new
meanings, as when Grub has a concept of "root" which is another
thing entirely than what we are used to think of a "root" in
relation to mounted file systems.

The Grub "root" is similar to Unix' concept of Current Working
Directory. But then Grub's root is not a directory but a
partition. We could call it the Grub Default Partition (GDP).
After setting the GDP it is possible to refer to files using
a "relative path" relative to the GDP. In your top stanza, the
kernel command har an argument /boot/vmlinuz-2.4.20-8, which
really is (hd0,0)/boot/vmlinuz-2.4.20-8.


This supposes that the partition /dev/hda1 (or (hd0,0)) really
has a directory /boot, and that vmlinuz-* is in that directory.

Fedora and quite a few distributions prefer to keep the kernel
and initrd things in a separate partition, other than the
partition containing the root file system. Then, on the Linux'
root file system there is an empty directory /boot, and on the
separate partition there is no directory /boot. Instead the
kernel and the initrd files are in the root directory of the
separate partition, and when the separate partition is mounted
on the root file system's /boot directory, the kernel and
initrd files appear as /boot/vmlinuz* etc.

Conclusion: unless you tailored your setup differently during the
installation of FC4, partition (hd1,6) does not contain a /boot
directory. Change the kernel and initrd lines in the no-joy
stanza to read

kernel /vmlinuz-2.6.11-1.1369_FC4 ro root=/dev/sda7 rhgb quiet
initrd /initrd-2.6.11-1.1369_FC4.img

But here I am supposing that root=(hd1,6) line is correctly
pointing to the partition where the vmlinuz-2.6* file and friends
resides, and the /dev/sda7 is the correct name to use for the
Linux root file system. This is what I was referring to when I
wrote in the beginning that I cannot write a complete documentation.
You tell next to nothing about your system configuration, so I
cannot determine what is right and what is wrong in the stanzas.

Some tips: When booting the computer, the boot usually pauses a
few seconds showing a menu consisting of the title lines of the
stanzas in grub.conf. At that point, you can hit the "c" key, and
get a command line. Then you can type

find /boot/vmlinuz-2.6.11-1.1369_FC4

Grub will inspect all partitions it can access, and report every
instance it finds of the above path. Somewhat likely it won't find
any. The issue

find /vmlinuz-2.6.11-1.1369_FC4

and see if then reports there is one in (hd1,6) If there is,
I guessed right above. If not, I hope you now have some ideas
about how to explore the issue further.

I believe that if you are still with me, at this point the Grub
documentation is no longer so unclear.

(There is another sin against clarity that concerns the two
kinds of "install":

1. Under a running Linux kernel, run the "rpm" command and
install grub onto your system. A couple of files (stage1.5
for various filesystem types, like reiserfs, stage2...)
get installed into /usr/lib/grub*/ (details taken from memory).

2. Prepare the computer to boot using Grub, this is also
called "install grub". At this point, the stages that will be
used are copied to /boot/grub, and stage1 is copied to the MBR
(or whereever you ask grub to install). Before that, a special
copy of stage1 is prepared, containing hard-coded references
to the next stage, as well as a copy of the partition table
that is going to be owverwritten. A backup of the old MBR is
usually also saved in /boot/grub.)

Back to the (pre-)booting situation: If you find that the kernel
resides in (say) (hd1,5) instead,
you can exit the command line (Can't remember, was it the Escape
key?), and then move to the second stanza's title and hit the "e"
key. Follow the (very brief) instructions somewhere on the screen,
and you will be able to edit the stanza. You can change (hd1,6)
into (hd1,5) and then hit "b" to boot.

The stanza won't be edited on disk. If the changes work, you will
have to remember what you did, and repeat the changes in /dev/hda's
/boot/grub/grub.conf or wherever the working grub.conf is.

You may find that you can well have a single partition serving
as boot partition for both RH9 and FC4. All relevant files are
suffixed with the kernel version number in question, and they can
coexist in the same directory. I you later upgrade the kernel
while running FC4, you want that upgrade to update the correct
grub.conf file.

I then suggest that you mount /dev/hda1 somewhere (/mnt/hda1)
while running FC4, and copy /boot/*2.6.11-1.1369_FC4 to
/mnt/hda1/boot, and then unmount /boot, remove /boot from fstab,
and make /boot a symlink to /mnt/hda1/boot. I have not tried
anything exacly like this. This reflects how I understand things
work. I believe that after grub has done it's things, and the
kernel has loaded the rest of itself, /boot is not accessed
by a running linux system until you install a new kernel or
someting.

Good luck! (and ask again if you need to)
-Enrique

"su -" permission denied

Posted: 12 Sep 2005 09:30 AM PDT

On Mon, 12 Sep 2005 16:30:23 +0000, Abanowicz Tomasz shouted Hoy......
 

Check to see if su is SUID root

--
Tayo'y Mga Pinoy

Download and Install Thunderbird (newbie question)

Posted: 12 Sep 2005 05:05 AM PDT

On Mon, 12 Sep 2005 12:05:10 GMT, TooManyPutters
<com> wrote: 
Is there a README or a Makefile?
 
aptitude install mozilla-thunderbird


--
BOFH excuse #52:

Smell from unhygienic janitorial staff wrecked the tape heads

debian 3.1 dialup

Posted: 10 Sep 2005 04:06 PM PDT

Thanks very much. By following the excellent pppconfig dialog, I established
the dialup connection on the first try with no trouble at all.

Problems Installing FC4 on a small machine

Posted: 10 Sep 2005 04:11 AM PDT

On Tue, 13 Sep 2005 22:43:21 +0200, <co.uk> wrote:
 

:)
 

Not so bad as it sounds, because at this point you are not really have
a running system. You are in single-user mode, and nothing is running
other than the shell you are using and the commands you are issuing.
 

Good. I was (must have been) wrong in saying you should do this step
if it has already done so.

(A technical note that perhaps others can clarify: On older versions
of "init" there used to be two kinds of "single-user state", one in
which init starts a shell before processing /etc/inittab, and one
in which it processis /etc/inittab, but goes straight to runlevel
one. Runlevel one would not really have to be "single-user", it would
be whatever you put into the /etc/inittab.

With the former kind, upon exiting the shell, init continued and
processed /etc/inittab the ordinary way, obeying the "initdefault" entry.

I was under the seemingly incorrect idea that issuing the "single" option
to the kernel -- the kernel passes on all unknown options to init, and
perhpas all known ones too, I don't know -- would invoke the first kind
of "single-user state.

Now I presume that init had processed /etc/rc.d/rc.sysinit as directed
in /etc/inittab, the sysinit entry, and most likely continued to level one.

ON my FC4 system, runlevel one has two "services" running, the first of
which is "single". This script runs the other scripts (if any, and on
my system there is one, "cpuspeed"), and then signals init to change
to runlevel S, which is about what I described above.

Another theory would be that modern init does run the sysinit line
in /etc/inittab if this file is present, even when going to runlevel
"S".)

I believe you can find out the current level with ps -fp1, which
will show init's command line as "init [1]" or whatever the runlevel is.

I also believe that processes started directly from init have an
envoronment set up with variables

RUNLEVEL=5
PREVLEVEL=N

(Where "N" means there was no earlier runlevel in my case).

It seems that the login program removes these variables, so when you
log in, they are not there any more. However, I believe the shell started
by init on /dev/console in runlevel "S" does have these variables.
 

This is weird. That one should not be there because you are using tty1.
Or, am I missing something? There should be plenty of people who can
correct me here.
 

??? Can somebody help explaining this? Does mingetty check the runlevel
and just exit if it is "S"? If you ever get back to this point, can you
remember to try

strace -o /tmp/mingetty.strace -f /sbin/mingetty tty2 &

That is, there must not be any program using tty2 already -
ctrl-alt-F2 should give a black screen. This command will write
a line to "/tmp/mingetty.strace" for each system call mingetty
(or any of its subprocesses) does. That sometimes gives a pretty
clear picture of what is going on.
 

Did you get the confirmation questions?

Did the computer not hang at any point?

If you had no other screens available (the mingetty processes
not showing in ps) could you still ctrl-alt-F2 or ...F3 to get
another screen with another shell?

Or did you only inspect /var/log/messages after all runlevel 3 daemons
had started?

If the "rc 3" script ran to completion without hanging the computer
it indicates that the problem was with the graphical interface,
which is started from /etc/inittab, the line

x:5:once:/etc/X11/prefdm -nodaemon

This line is not run except in runlevel 5. So, setting initdefault to
3 appears to be the right thing.
 
# and unconfigures removed devices. Remembers
# earlier configuration in /etc/sysconfig/*
 
# lower levels if load is low. Requires hardware
# support. Saves energy.
 
# The latter if multiple PCs on the home network
# access internet through this computer.
 
 
 
# You want this.
 
# the /etc/fstab at a suitable time after the basic network
# has been started. 
# on your hardware, could be obsoleted by acpi. 
# early in the script. Do you run zero-conf autoipd? 
# if ACPI is supported. Somebody knows if apmd can be
removed? 
# IIRC does nothing unless you enble something somewhere 
# a mail server. 
# too, let it be. 
# not permanently on. (If you run backup through it, and
power is
# off during the normal backup hours, anacron can reschedule
it when
# power is back - and example 
# usb plug-and-play devices? 
# day the Epson is /dev/usb/lp0 and the Cannon is
/dev/usb/lp1 and the
# next day it's the other way around 
# the next upgrade. 

A trick: What is "kudzu"? Ok, got one file: /etc/rc.d/init.d/kudzu.

Try the command:

rpm -qf /etc/rc.d/init.d/kudzu

This answers "what rpm package owns this file?"
Answer: kudzu-1.1.116.2-2

Then, omitting the version (too error prone)

rpm -qi kudzu

Get information about installed package kudzu. The
description field usually tells something. If not perhaps

rpm -ql kudzu | less

See the list of files belonging to this package. Notice
man pages, html files etc. Or if there are other file
names that are less mysterious to you, this package is
related.

I hope this brings you a step forward.

-Enrique

Fedora networking out of the box

Posted: 09 Sep 2005 03:12 PM PDT

On Sat, 10 Sep 2005 05:21:51 +0200, Nico Kadel-Garcia <net>
wrote:
 

I too don't know. Perhaps you should install and run ethereal on eth0
to see what goes over the wire from your dhcp server or you adsl modem
or whatever applies to you.

On my system, I have an ADSL modem and use ppp-over-ethernet, there
is a script /etc/ppp/if-up that ultimately (through calling a script
/etc/sysconfig/network-scripts/ifup-post) that sets up resolv.conf.

If you have a regular dhcp server, I believe you need the package dhclient
and, of course, you need to run the daemon contained in it. Also, with
the package installed, man dhclient, or any other documentation file
below:

$ rpm -qlp /fedora/links/dhclient-3.0.2-12.i386.rpm
/sbin/dhclient
/sbin/dhclient-script
/usr/share/doc/dhclient-3.0.2
/usr/share/doc/dhclient-3.0.2/dhclient.conf.sample
/usr/share/man/man5/dhclient.conf.5.gz
/usr/share/man/man5/dhclient.leases.5.gz
/usr/share/man/man5/dhcp-options.5.gz
/usr/share/man/man8/dhclient-script.8.gz
/usr/share/man/man8/dhclient.8.gz
/var/lib/dhcp


-Enrique

Can't get pc speaker to work.

Posted: 09 Sep 2005 07:11 AM PDT

Michael Heiming <michael+heiming.de> wrote:
 

That's what I get for doing it from memory. :-) You only need that for a
different kernel version or if you've applied patches that add new
options though.

I'm surprised it took someone that long to spot it. ;-)
 

It might ease things up for you and the OP but I use Gentoo so it's near
useless to me. I did say these instructions were generic and I don't use
SuSE. :-)

--
Andy.

newbie debian 3.1 question

Posted: 09 Sep 2005 03:04 AM PDT

Thanks very much for the replies. I am certainly glad I tried debian out.

Linux with software RAID5?

Posted: 08 Sep 2005 04:02 AM PDT


"Davide Bianchi" <net> wrote in message
news:onlyforfun.net... 

And a more recent distribution than SuSE 9.0 and RedHat 9. RedHat 9 is
end-of-life and deprecated, SuSE 9.0 is still wildly out of date and SuSE
9.3 is vastly superior.

Distributions that support dual core Athlons

Posted: 07 Sep 2005 02:09 PM PDT

In comp.os.linux.setup Nico Kadel-Garcia <net>:
 
 

Irrelevant, if you go to rhn, the first available .iso AS4(x86)
is the update:

Red Hat Enterprise Linux AS 4 Update 1 (x86)

Same for RHEL 3:

Red Hat Enterprise Linux 3 Update 5 AS (x86)

Only an idiot would download the base release and then all
patches to upgrade if one can simply grab the update .iso
including most updates.

Your claims make no sense to me and I'd be glad if you could
simply stop wasting my time, thx.

[..]


--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 327: The POP server is out of Coke