Linux-Development-Sys Digest #496, Volume #6     Tue, 16 Mar 99 23:14:20 EST

Contents:
  Re: how to load ram disk from LILO? (Phil Howard)
  Re: how to load ram disk from LILO? (Phil Howard)
  Re: After Week 1 With Linux -- licking wounds. (Sami Tikka)
  Re: After Week 1 With Linux -- licking wounds. (Nix)
  Re: Tripwire 1.2 core dumps on Linux 2.0.36 and 2.2.1 (Lukasz Trabinski)
  Re: kernel won't uncompress when boot from CD (Phil Howard)
  Re: After Week 1 With Linux -- licking wounds. (Steve Smith)
  glibc2 questions (Clint Davis)
  Re: Tripwire 1.2 core dumps on Linux 2.0.36 and 2.2.1 ([EMAIL PROTECTED])
  Re: Where can I find the ELF format specification. ("John E. Garrott")
  Re: After Week 1 With Linux -- licking wounds. (Shashi M Sharma)
  kernel (Eldhose John)
  Re: After Week 1 With Linux -- licking wounds. (Alexander Viro)
  Re: After Week 1 With Linux -- licking wounds. (Darin Johnson)
  Re: After Week 1 With Linux -- licking wounds. (Darin Johnson)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: how to load ram disk from LILO?
Date: Tue, 16 Mar 1999 22:25:00 GMT

On 15 Mar 1999 20:22:17 +0100 Villy Kruse ([EMAIL PROTECTED]) wrote:

| The initrd parameter in /etc/lilo.conf is not pased on to the kernel,
| but is used by the lilo program directly.  When runing lilo, the
| absolute disk addresses of the kernel AND the initrd file are stored in
| the /boot/map file.
|
| When the system is booted, the kernel is loaded, but the initrd file
| is also loaded into memory.  Then a pointer to the memory copy of the
| initrd file is passed on to the kernel inself before the lilo loader
| passes on control to the kernel start-up code.
|
| When loading with syslinux basically the same thing happens, except
| syslinux doesn't use the /boot/map file to find the files to be loaded.
| Syslinux will use the dos directory to directly locate the files to be
| loaded by name.
|
| The way to create an initrd file is the same whether you use lilo or
| syslinux.

Some other difference exists somewhere.  When I use syslinux, things work
just fine.  When I use lilo, the kernel gives the messages like it is
getting the initrd, including saying it is found at block 0 as it also
does with syslinux, but it fails to successfully mount the initrd.  It
is the same initrd I built for both, so the initrd data itself is good.
Something is either wrong in lilo or my configuration thereof.

Since syslinux is working, it's not a critical issue.


| Redhat systems have been using initrd file to support scsi disk units
| with their modular kernel for quite a while now (since kernel 2.0 came
| out), so this does work.

So that they can mount root from an insmod supported device.  That's great
when you need to avoid having so many different, or one big fat, kernel,
as they do need to do for installation and the initially installed kernel.

I always compile in every driver I consider to be crucial to my systems.
My use of modules is very rare though it may be of benefit when making a
bootable CD based Linux for others to run.

Of course, not everyone wants to recompile their kernel.  At least Linux
is flexible enough to allow things to work both ways for different people.
I hope it stays that way, as opposed to forcing us all into a "common
denominator" as Microsoft does.

--
Phil Howard           KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: how to load ram disk from LILO?
Date: Tue, 16 Mar 1999 22:47:23 GMT

On Mon, 15 Mar 1999 17:36:10 +0000 Bryan Hackney ([EMAIL PROTECTED]) wrote:

| The reasons are: some misbehaved daemon requires /dev to be writeable. If you
| remount /dev after init starts to run, telinit cannot communicate with init.
| This is bad.

In "man init" I read:

INTERFACE
    Init listens on a fifo in /dev, /dev/initctl, for messages.  Telinit uses
    this to communicate with init.  The interface is not very well documented
    or finished. Those interested should study the initreq.h file in the src/
    subdirectory of the init source code tar archive.

and

SIGUSR1
    On receipt of this signals, init closes and re-opens it's control fifo,
    /dev/initctl.  Useful for bootscripts when /dev is remounted.

So if you remount /dev, just signal init to deal with it.

--
Phil Howard           KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

------------------------------

From: Sami Tikka <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 22:29:01 +0200

[EMAIL PROTECTED] (Rupert K. Snoopowitz) writes:

> When reading books, one does not need to learn how to read again for each 
> new book they pick up.  This is invariably the case with CLI's.  New 
> commands, new syntax, new methodology.. It can be quite frustrating for 
> most of us.

And it is the same with a program with a graphical user interface. I
witness it every day at work. The basic user just cannot handle the
(sometimes subtle) changes in the UI. E.g. upgrade from MsMail to
Windows Messaging to Outlook.

I grant you that some aspects are common to every program in the Mac
and Win world, like the use of the clip-board, cut and paste. But
similarly, there are aspects of the command line interface (or
specifically, a Unix shell) that are always the same regardless of the
application you are using: the redirection of output and input,
pipelines, etc.

Some things are the same and some things change.
-- 
Sami Tikka, [EMAIL PROTECTED], http://www.iki.fi/sti/

------------------------------

From: Nix <$}xin{$@esperi.demon.co.uk>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 20:47:22 +0000

Tim Kelley <[EMAIL PROTECTED]> writes:

> Windows developers:  Study the Linux CLI.  There's a lot to be said in
> this for what makes a computer truly useable and powerful.

I think you mean `study the Unix CLI'.

Please say `Unix' if not speaking of Linux-specific stuff. (eg /proc is
a Linux feature, but the pipeline/toolset philosophy and the CLI in
general are Unix things.)

> No pain, no gain.

And, in the case of Windows, pain, no gain.

Or so I found it.

-- 
`Have you ever considered life expectancy? You have a life expectancy
 of seventy years, but if you eat pure plutonium, it's going to be
 less.' --- Kieran Barry

------------------------------

From: Lukasz Trabinski <[EMAIL PROTECTED]>
Crossposted-To: comp.security.unix
Subject: Re: Tripwire 1.2 core dumps on Linux 2.0.36 and 2.2.1
Date: 16 Mar 1999 22:42:12 GMT

Peter 'Luna' Altberg <[EMAIL PROTECTED]> wrote:
> Hi all,

> Have anyone similar problams as I compiling/running Tripwire? I have tried
> both compiling myself with different settings, and running a binary dist
> from RedHat. And on three different machines. Always the same thing:

> ### Phase 1:   Reading configuration file
> ### Phase 2:   Generating file list
> ### Phase 3:   Creating file information database
> Segmentation fault (core dumped)

Try this: (if you have RedHat)

ldd tripwire
libm.so.6 => /lib/libm.so.6 (0x40005000)
        libc.so.6 => /lib/libc.so.6 (0x4001e000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2aaaa000)

rpm -qf /lib/libm.so.6
glibc-2.0.7-29

Let's use strace... ;)

-- 

                    _[   Łukasz Tr±biński   ]_                    
PgP Key: finger:[EMAIL PROTECTED], SysAdmin @wsisiz.edu.pl

------------------------------

From: [EMAIL PROTECTED] (Phil Howard)
Subject: Re: kernel won't uncompress when boot from CD
Date: Tue, 16 Mar 1999 22:10:28 GMT

On Tue, 16 Mar 1999 19:15:10 GMT John Montgomery ([EMAIL PROTECTED]) wrote:

| Phil Howard wrote:
|
| > I did.  syslinux truly will not operate on a ramdisk.  It doesn't like
| > what it gets for the blocksize.  However, looking at the source code with
| > the idea in mind of coding in a kludge to deal with ramdisk, I found it
| > already has a kludge to deal with loopback.  So I switched gears and used
| > loopback instead of ramdisk.  Now it works.  Now I've successfully built
| > my own rescue CD which boots off the CD and runs from /dev/ram.
|
| Could you post an explanation of how to do this?  I'd like to make one myself if I 
|could
| figure out how.  Thanks!

Be sure you have loopback support compiled into your kernel, or the module
loaded if it's available as a module.  I'd just compile it in as it does
not seem to be very big at all.  It is best to be root when doing all this.

Create a base file that will pretend to be the filesystem device.  I don't
know if this can work over NFS/Samba, though.

    dd if=/dev/zero of=floppy.img bs=1024 count=1440

Format it with a filesystem.  For most filesystems you can use the appropriate
variation of mkfs, but you will probably need the -F option to force it to
ignore that it is not a real device.  For MS-DOS, all I find to do formatting
is mformat, and I can't get it to work on a file.  So I stored a compressed
copy of a pre-formatted floppy for that purpose.

So for ext2 and the like:

    mke2fs -F -m 0 floppy.img

And for MS-DOS FAT12 format (and this won't need the dd above):

    zcat < fat12-empty.gz > floppy.img

Make sure you have a mount point:

    mkdir floppy.mnt

Now mount it:

    mount -o loopback floppy.img floppy.mnt

Populate it using ways you like, or maybe something like this:

    (cd mystuff;tar cf - .) | (cd floppy.mnt;tar xpf -)

If you're making it bootable with LILO, make sure there is a file
called floppy.mnt/etc/lilo.conf (or symlink to one that will work
when chroot'd) and do:

    lilo -r floppy.mnt

Unmount it:

    umount floppy.mnt

Now if you are making it bootable with syslinux, be sure the necessary
ldlinux.sys and syslinux.cfg files are in there and do:

    syslinux floppy.img

And now you have a filled in floppy sector image file.  You can dd this file
straight to a floppy.  If you have to make lots and lots of floppies with
the same exact thing, this can really speed things up.  This file can also
be written to a floppy on Windoze using RAWRITE.EXE.  If you are making a
bootable CD using El Torito, you would use this file as the boot image:

    cp floppy.img cdfiles/boot.imag
    mkisofs -b boot.img -c boot.catalog -o mycd.iso cdfiles

--
Phil Howard           KA9WGN
[EMAIL PROTECTED] [EMAIL PROTECTED]

------------------------------

Date: Tue, 16 Mar 1999 18:34:44 -0500
From: Steve Smith <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.

Jeff Szarka wrote:

> On Sun, 14 Mar 1999 15:53:47 -0500, [EMAIL PROTECTED] (Julian Thomas)
> wrote:

> :In <[EMAIL PROTECTED]>, on 03/14/99
> :   at 05:33 PM, Sid Boyce <[EMAIL PROTECTED]> said:

> :>Have you ever watched
> :>anyone trying to use Windows to copy a file to floppy for you ?, it's
> :>painful.

> :No - Start - Programs - MS DOS prompt.  CD to the directory, copy file a:

> :Not even very hard if it's a long file name - copy 'long filename'
> :a:newfile


> If you don't feel like moving to the directory just use:

> copy x:\path\file.ext x:\path

> Hard huh?

Uhh...  We *are* talking about Windoze?

Right click on the filename.  Select "Send to".  Select the floppy. 
Watch the cute little animation as it copies.

Most Windoze users don't read the manual.  (Big surprise, right? :-) 
Also, most Windoze users are not technical types, and are terrified of
experimentation.  Might mess up the system.  This is how those outfits
who sell training courses in Windoze stay in business.


--
Steve Smith                          [EMAIL PROTECTED]
Agincourt Computing                +1 (301) 681 7395
"If I can't dance, I'm not joining your revolution."

------------------------------

From: Clint Davis <[EMAIL PROTECTED]>
Subject: glibc2 questions
Date: Tue, 16 Mar 1999 17:00:59 -0800

I have noticed that new packages that use ./configure are 
requiring glibc2 now.  

I have SuSe 6.0 and Caldera 1.3-->  is it possible to get these
new libraries without having to compile them?  Installing new
libraries is a pain and I am hoping that someone has done some of this
work up front for the rest of us.

It is too bad that the newer versions of linux from various vendors
do not have glibc2 ( libc6 ).

Clint

------------------------------

From: [EMAIL PROTECTED]
Crossposted-To: comp.security.unix
Subject: Re: Tripwire 1.2 core dumps on Linux 2.0.36 and 2.2.1
Date: 17 Mar 1999 01:53:04 GMT
Reply-To: [EMAIL PROTECTED]

http://raven.genome.washington.edu/security/tripwire-1.2.1.1.tar.gz

this is tripwire with patches to fix the 8bit bug, the fp bug, the zlib
patches and a work-around for static compiles under solaris.

this is a temporary home.  after i figure out where to put it permanently
i'll put up md5 checksums and pgp sign it and include pointers to the
commerical version, etc, etc, etc...

-- 
Lamont Granquist ([EMAIL PROTECTED])
ICBM: 47 39'23"N 122 18'19"W

------------------------------

From: "John E. Garrott" <[EMAIL PROTECTED]>
Crossposted-To: comp.unix.bsd.freebsd.misc,comp.unix.programmer
Subject: Re: Where can I find the ELF format specification.
Date: Tue, 16 Mar 1999 16:36:14 -0800

Zhuang Hao wrote:
> 
> Hi, all,
> I need the detailed the ELF specification. Where can I find it ?
> I'm also interested in the structure of the shared lib (.so) file
> of FreeBSD 2.x.x, which does not support ELF.
> 
> Thank you very much.
> 
> - Hao

ftp://metalab.unc.edu/pub/Linux/GCC/elf.ps.gz        

Hope this helps,

John

------------------------------

From: Shashi M Sharma <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 18:19:43 -0800

Tim Kelley <[EMAIL PROTECTED]> writes:

> Windows developers:  Study the Linux CLI.  There's a lot to be said in
> t
Nix <$}xin{$@esperi.demon.co.uk> writes:

> his for what makes a computer truly useable and powerful.
> 
> I think you mean `study the Unix CLI'.
> 
> Please say `Unix' if not speaking of Linux-specific stuff. (eg /proc is
> a Linux feature, but the pipeline/toolset philosophy and the CLI in
> general are Unix things.)
> 
> > No pain, no gain.
> 
> And, in the case of Windows, pain, no gain.
> 
> Or so I found it.
> 


Does this mean that I have a linux virus on my solaris machine ?

[1]% ls
(null)/       dev/          home/         lost+found/   platform/     TT_DB/     
   xfn/
bin@          devices/      INFORMIXTMP/  mnt/          proc/         usr/
cdrom/        etc/          kernel/       net/          sbin/         var/
core          export/       lib@          opt/          tmp/          vol/
[2]/% showrev
Hostname: charvak
Hostid: 809eb95e
Release: 5.6
Kernel architecture: sun4u
Application architecture: sparc
Hardware provider: Sun_Microsystems
Domain: 
Kernel version: SunOS 5.6 Generic 105181-05 March 1998

------------------------------

Date: Tue, 16 Mar 1999 21:29:12 -0500
From: Eldhose John <[EMAIL PROTECTED]>
Subject: kernel

Hi, 
I am new comer to Linux. I wanted to find out how the kernel works,
so I searched through the source code. But it was an unplesent experince
I could not find any starting point. Please help me to solve the mistory.



------------------------------

From: [EMAIL PROTECTED] (Alexander Viro)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 22:00:58 -0500

In article <[EMAIL PROTECTED]>,
Shashi M Sharma  <[EMAIL PROTECTED]> wrote:
>Does this mean that I have a linux virus on my solaris machine ?
>
>[1]% ls
[snip]
>bin@          devices/      INFORMIXTMP/  mnt/          proc/         usr/
[snip]
>[2]/% showrev
[snip]
>Kernel version: SunOS 5.6 Generic 105181-05 March 1998

Nope.

$ /bin/ls -F /proc
0/     136/   161/   2/     222/   2752/  3/     6676/  6758/  6768/
1/     1512/  176/   211/   229/   280/   5452/  6677/  6759/  6769/
123/   153/   180/   216/   239/   283/   5454/  6685/  6766/  6781/
125/   159/   193/   219/   274/   286/   5470/  6734/  6767/
$ uname -a
SunOS weyl 5.6 Generic_105181-06 sun4u sparc SUNW,Ultra-5_10

$ /bin/ls -F /proc
1/           206/         28937/       4/           kcore        pci
12050/       212/         28938/       apm          kmsg         scsi/
12638/       215/         28945/       bus/         ksyms        self@
13/          218/         29299/       cmdline      loadavg      slabinfo
168/         219/         29300/       cpuinfo      locks        stat
170/         220/         29334/       devices      meminfo      swaps
175/         222/         29403/       dma          misc         sys/
177/         25621/       29404/       filesystems  modules      tty/
185/         25622/       29405/       fs/          mounts       uptime
197/         25623/       29406/       ide/         net/         version
2/           25997/       3/           interrupts   parport/
203/         28936/       3510/        ioports      partitions
$ uname -a
Linux bird 2.2.3 #23 Mon Mar 15 23:14:14 EST 1999 i586 unknown

Notice lots of additional stuff on Linux box.

-- 
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

------------------------------

From: Darin Johnson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 19:46:24 -0800

[EMAIL PROTECTED] (Rupert K. Snoopowitz) writes:

> To learn how to use a 'modern' CLI, one must learn hundreds of commands, 
> their various switches and parameters, etc.  Having to do this, imho, is 
> archaic.

Sounds like you're describing a non-modern CLI.  Most users never need
to learn more than a few commands, and very few ever have to learn
various options.  Besides, a CLI often doesn't define more than a
handful of commands anyway, all those "hundreds" just happen to be
external utilities and tools.

You're implicitly assuming that no CLI *ever* can go beyond the
limitations you see now.  What if someone said "for a modern GUI, one
must learn to navigate tortuous menus, know when to use the left,
right, or middle button, and what keys to push at the same time"?
It'd be absurd.  Yet you're doing the same thing essentially.

And what's wrong with learning hundreds of commands?  No one is
*forcing* you to do that.  Now I could understand the frustration back 
in the days where one had to employ their brains in order to use
computers and thus learning commands was required for many jobs; but
that's not true today.

If you think the CLI is archaic, then fine - it's archaic.  You've
said it, now move on.  You will never get everyone to agree with you,
so why bother?  Do you feel compelled to try and convince us, to help
us out of our primitive tribal nature out of altruism?  If not, then
why expend the energy when you know we'll never agree with you?
What's wrong if someone does something archaic, or inefficient, or
suboptimal, when it doesn't affect you?  If you're concerned about
people doing archaic things, then why not join the Peace Corps so
you can show people better agricultural methods and actually do
something useful?  Just let us poor deluded and primitive CLI people
alone (and don't take our picture cuz it'll steal our souls).

> I beg to differ on this..  I challenge that one can create a GUI that is 
> just as powerful and feature rich as a CLI, while also easy to use and 
> learn.  Doing this sort of thing has actually been my job for several 
> years now, and the more I do it, the more I'm convinced that CLI's are 
> not necessary to achieve "real computing power".

The best I feel is a cross between the two.  It's been done, but few
have ever tried to do it again.  Primarily because it wasn't done for
novice users, it was done for experts.  I'm speaking of lisp machines.

Part of the problem with GUI's from my view, is that much of their
overriding goal is to provide something easy for a novice to use.
This would seem in many cases to eliminate opportunities for
non-novice features and interfaces!  Ie, look at MSVC++, which is a
prime example because it's designed for the non-clueless, yet it
treats them dolts.  (on the other hand, with the advent of MSVC 5,
I can claim that I use Emacs because it's smaller and more efficient :-)


> There are many other reasons I believe CLI's are antiquitated.

Name some.  Or one.  You haven't named one yet, or at least not
something that wasn't vague.  Ie, an "I've become convinced that..."
is not a reason.

> Bah.. still picking on technicalities.

But if you can't get the technicalities right, all we can assume is
that you don't know what you're talking about!!

> Anyway, this is my conclusion:  Unix people are in large intellectual 
> folk..  Myself, being an old Mac guy, am obviously a visual person.  My 
> expectations when it comes to working with my computer are obviously 
> quite different than many Unix/Linux people.

What'd you use before a Mac?  Was it something with a crappy CLI, and
the arrival of the Mac so profoundly affected you that you've come to
consider all CLI's to be crap?

> As fun as learning the shells is for many of you all, please understand 
> that for folks like me, it is thoroughly maddening.

Then don't bother learning it.

> I believe Linux is in a unique position to really drop a nuclear bomb on 
> these guys..  But, what it will take is a world-class GUI based system to 
> do this.

OK.  Then help create one.  Obviously we don't know anything about
these powerful GUI's, so you're the one to lead the project.  That's
the Linux way.

> Or maybe it isn't... Maybe it's just a geek OS with a forever fringe 
> market and the ultimate destroyer-of-microsoft is going to come from 
> somewhere else.

Linux is *NOT* the destroyer-of-microsoft!!!  When are you Linux
newbies going to learn that!  Linux was not designed to compete with
Microsoft, it is not meant to be a Windows killer, and it does not
have any political motivations!  What is is instead is an effort to
create a free version of UNIX, and a great version of UNIX.  Those are 
the core design goals of the chief developers.  If you want politics,
join the FSF, if you want a Windows killer, start your own project, if 
you want to compete with Microsoft, get a job with one of their
competitors.

-- 
Darin Johnson
    "Floyd here now!"

------------------------------

From: Darin Johnson <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.questions
Subject: Re: After Week 1 With Linux -- licking wounds.
Date: 16 Mar 1999 19:14:28 -0800

> > The CLI is primative.  This has been proven years ago with the Mac and 
> > its resulting copy-cat of Windows.  Now, please go postal and stop 
> > threatening.

This "proven" thing must be a different definition than in my
dictionary.

Anyway, eating food is primitive, sex is primitive, silicon is even
more primitive, etc.

Robert Krawitz <[EMAIL PROTECTED]> writes:

> What I read you as saying is that CLI's *in general* are primitive,
> which is a whole different kettle of fish.  I will disagree vigorously
> with this.  Why are children's books typically full of pictures, while
> adult books typically have much more text?

Hmm, lots of adult books that have more pictures than text :-)

But in a sense, CLI's were invented first, thus they're more
"primitive", where primitive means they're just older.  But I got the
distinct impression that "primitive" was used to imply outdated,
poorly designed, not desired by anyone with a sense of sophistication,
etc.  But that's all untrue.  Except for the Windows CLI of course :-)
They're not out of date and they're still being developed; many are
well designed, and plenty of computer experts (ie, sophisticated
users) use them.

-- 
Darin Johnson
    Support your right to own gnus.

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list (and comp.os.linux.development.system) via:

    Internet: [EMAIL PROTECTED]

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-System Digest
******************************

Reply via email to