I have a system at home I use for everything. Personal use (Slack 10.0),
Gaming (Windows) and work (RHEL - RedHat Enterprise Linux). It has 4 hard
drives, 2 IDE and 2 SATA, a cdrw, and a DVD Rom. Just recently I
installed RHEL on hdb. Windows is on hda and Slack is on sda. sdb is
used for storage. After installing RHEL, Slack became FUBAR. On boot no
startup scripts are executable. No name is given to the machine and
login is impossible as TTYs are inaccessable. If I log in to RHEL, mount
the Slack partitions and chroot, everything seems hunky-doryish and I
can do nifty things such as post to AOLS saying "Hey look what I screwed
up!".

Since the machine cant write to logs when I boot Slack, I dont have any
to show. I'm willing to give whatever information you guys request to
troubleshoot. I've never seen anything like this before. It's completely
fucked. Hell, I'm spending friday night staring at it instead of....
yeah, the other stuff.

I've looked at lilo.conf and it's kosher, the kernel didn't change (I'm
running 2.6.8.1 in Slack) and I didn't allow RHEL to write a boot loader
as I use Slack to do that sort of stuff.

Has anyone out there seen anything like this before? I'm flummoxed!
Flabbergasted even, and many other F words!

--
The good thing about standards is that there are so many to choose from.
-- Andrew S. Tanenbaum

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Handover Phist dared to utter,
> I
> installed RHEL on hdb. Windows is on hda and Slack is on sda. sdb is
> used for storage. After installing RHEL, Slack became FUBAR. On boot no
> startup scripts are executable. No name is given to the machine and
> login is impossible as TTYs are inaccessable.

This sounds _exactly_ like what happens when you boot the Slackware
live cd with a kernel that doesn't have support for the CD-ROM (for
example, booting bare.i in a SCSI cd-rom drive). I'm willing to bet
you you've nixed something in your boot loader, and I think it's most
likely an initrd for the 2.6 kernel included with Slackware 10.0. It's
been awhile since I used RH, but back then it _always_ used an initrd
for loading modules. If you do the same for Slackware and your kernel
versions are different, the first thing I would check is to ensure that
Slackware isn't using RHEL's initrd by mistake. If that was the case,
it couldn't load up certain required modules and all kinds of stuff
goes bad.

> If I log in to RHEL, mount
> the Slack partitions and chroot, everything seems hunky-doryish and I
> can do nifty things such as post to AOLS saying "Hey look what I screwed
> up!".

Definately a kernel thing, again, most likely related to the boot
loader. Since you can chroot into the Slackware installation and have
everything work, it most likely hasn't actually modified anything with
Slackware.

> I'm willing to give whatever information you guys request to
> troubleshoot.

Bootloader config files for both RHEL and Slackware 10.0, without
comments.

> I've looked at lilo.conf and it's kosher, the kernel didn't change (I'm
> running 2.6.8.1 in Slack)

Aha! Somehow I knew you were running the 2.6 kernel.

> and I didn't allow RHEL to write a boot loader
> as I use Slack to do that sort of stuff.

This is almost defiantely where you went wrong. Describe for me the
boot process, 'cause you've for some strange reason got 4 hard drives
to do the task of 1 (seriously, this is what extended partitions and
big drives are for). Obviously the BIOS looks one drive before looking
at the others, is this where your boot loader is? Are there boot
loaders on other HD's? Do you hand off to the flagged partition or
install the boot loader in the MBR. More info please.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCTrblvgVcFKpJf4gRAogbAJ9G6RDPLr0a78tBIrJ3ee KccZ6ocQCeKkK2
VDoR1V9WFQWBIyazDOGZpCQ=
=dqsC
-----END PGP SIGNATURE-----

+Alan Hicks+ blithely blithered
>
>
> This sounds _exactly_ like what happens when you boot the Slackware
> live cd with a kernel that doesn't have support for the CD-ROM (for
> example, booting bare.i in a SCSI cd-rom drive). I'm willing to bet
> you you've nixed something in your boot loader, and I think it's most
> likely an initrd for the 2.6 kernel included with Slackware 10.0. It's
> been awhile since I used RH, but back then it _always_ used an initrd
> for loading modules. If you do the same for Slackware and your kernel
> versions are different, the first thing I would check is to ensure that
> Slackware isn't using RHEL's initrd by mistake. If that was the case,
> it couldn't load up certain required modules and all kinds of stuff
> goes bad.

I was thinking something like this. It _has_ to be something
kernel/module related. Glad you replied Alan .

>> I'm willing to give whatever information you guys request to
>> troubleshoot.
>
> Bootloader config files for both RHEL and Slackware 10.0, without
> comments.

Relevant lilo.conf entries in Slack:
---------------
boot = /dev/sda1
bitmap=/boot/bootlogo.b
bmp-colors=6,0,0,15,9,0
bmp-table=22p,30p,1,19,
bmp-timer=35p,340p,13,0,0
prompt
timeout = 100
default = Linux

image = /boot/vmlinuz_2.6.8.1
root = /dev/sda1
label = Linux
append = "hdc=ide-cd hdd=ide-cd"
read-only

other = /dev/hda1
label = Windows
boot-as = 0x80

image = /vmlinuz
root = /dev/sda1
label = Experimental
append = "hdc=ide-cd hdd=ide-cd"
read-only

image = /boot/vmlinuz-2.4.21-4.EL
root = /dev/hdb1
label = RH_Devel
read-only
----------

>> I've looked at lilo.conf and it's kosher, the kernel didn't change (I'm
>> running 2.6.8.1 in Slack)
>
> Aha! Somehow I knew you were running the 2.6 kernel.

and 2.4.21 in RHEL, but modules for each system are stored on separate
drives. Here's an fdisk -l for you:

---------------
Disk /dev/hda: 80.0 GB, 80054059008 bytes
255 heads, 63 sectors/track, 9732 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 * 1 9731 78164226 7 HPFS/NTFS

Disk /dev/hdb: 80.0 GB, 80054059008 bytes
255 heads, 63 sectors/track, 9732 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 * 1 32 257008+ 83 Linux
/dev/hdb2 33 669 5116702+ 83 Linux
/dev/hdb3 670 796 1020127+ 83 Linux
/dev/hdb4 797 9732 71778420 5 Extended
/dev/hdb5 797 923 1020096 83 Linux
/dev/hdb6 924 988 522081 82 Linux swap
/dev/hdb7 989 1115 1020096 83 Linux
/dev/hdb8 1116 9732 69216021 83 Linux

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 122 979933+ 83 Linux
/dev/sda2 123 183 489982+ 82 Linux swap
/dev/sda3 184 9729 76678245 5 Extended
/dev/sda5 184 669 3903763+ 83 Linux
/dev/sda6 670 791 979933+ 83 Linux
/dev/sda7 792 9729 71794453+ 83 Linux

Disk /dev/sdb: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 9729 78148161 c Win95
FAT32 (LBA)
------------

Sda is my boot device. Bios hands off to it and lilo in the MBR takes
over. no other bootloader is installed. Kernels for any linux system I
run get copied to the /boot directory of / (/dev/sda1) manually after
the other linux is installed because either lilo is braindead or I
haven't done my homework properly. At any rate, all kernels reside
there. There is no initrd in use in the Slack system, all needed drivers
are compiled directly into the kernel, including ext[23] support. Slack
then mounts sda1 as root, and RHEL mounts hdb1. At this point all is
good, except that Slack then cant execute scripts needed to set basic
params and such. I have no way of knowing at this point what exactly is
missing in the boot process since that kernel is monolithic.

This is going to be one of those "How the hell did I miss that" things,
I just know it.

>> and I didn't allow RHEL to write a boot loader
>> as I use Slack to do that sort of stuff.
>
> This is almost defiantely where you went wrong. Describe for me the
> boot process, 'cause you've for some strange reason got 4 hard drives
> to do the task of 1 (seriously, this is what extended partitions and
> big drives are for). Obviously the BIOS looks one drive before looking

Bah. I need more disk space, I add a disk. As I described above, sda is
the boot disk, everything branches out from there with slack controlling
the boot sector.

> at the others, is this where your boot loader is? Are there boot
> loaders on other HD's? Do you hand off to the flagged partition or
> install the boot loader in the MBR. More info please.

Nope. No other boot loader. It's just easier this way.

--
Let's call it an accidental feature.
-- Larry Wall

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Handover Phist dared to utter,
> Relevant lilo.conf entries in Slack:

<snip>
> image = /boot/vmlinuz_2.6.8.1
> root = /dev/sda1
> label = Linux
> other = /dev/hda1
> label = Windows
> boot-as = 0x80
> image = /vmlinuz
> root = /dev/sda1
> label = Experimental
> image = /boot/vmlinuz-2.4.21-4.EL
> root = /dev/hdb1
> label = RH_Devel

I don't see anything wrong provided all your kernels are under /boot on
the Slackware install, but I would suggest removing the ide-scsi
things, as they are bad form with 2.6 kernels.

> and 2.4.21 in RHEL, but modules for each system are stored on separate
> drives.

Alright, let's try this. Since you've already got that 2.4 kernel for
RHEL in place under /boot, copy it's modules over to
/lib/modules/2.4.whatever and setup lilo.conf such that Slackware uses
that kernel instead of 2.6.8.1, reboot, and see what happens.
Alternatively, you could attempt to start RHEL with your 2.6.8.1 kernel
and see what it does.

> Sda is my boot device. Bios hands off to it and lilo in the MBR takes
> over. no other bootloader is installed. Kernels for any linux system I
> run get copied to the /boot directory of / (/dev/sda1) manually after
> the other linux is installed because either lilo is braindead or I
> haven't done my homework properly.

Question. Is /boot it's own partition and have you be any chance
confirmed that you have free space there? Perhaps your kernel is
corrupted somehow?

> There is no initrd in use in the Slack system, all needed drivers
> are compiled directly into the kernel, including ext[23] support. Slack
> then mounts sda1 as root, and RHEL mounts hdb1. At this point all is
> good, except that Slack then cant execute scripts needed to set basic
> params and such. I have no way of knowing at this point what exactly is
> missing in the boot process since that kernel is monolithic.

Like I said above, try another kernel. Shoot, try using the sata.i
kernel from the 10.1 install disks or something. That might get you a
good bit further.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCTvx0vgVcFKpJf4gRAgeHAJ0bfbrciKvjINJrhfYw7u MTcBE8ZwCffkfu
1wLlsLT4Bd70eODWQtXmPt0=
=V8hD
-----END PGP SIGNATURE-----

Handover Phist wrote:
> +Alan Hicks+ blithely blithered
> Relevant lilo.conf entries in Slack:
> ---------------
> image = /boot/vmlinuz_2.6.8.1

Hi, my is /boot/vmlinuz-2.6.8.1, make difference?

Handover Phist blithely blithered
> I have a system at home I use for everything. Personal use (Slack 10.0),
> Gaming (Windows) and work (RHEL - RedHat Enterprise Linux). It has 4 hard
> drives, 2 IDE and 2 SATA, a cdrw, and a DVD Rom. Just recently I
> installed RHEL on hdb. Windows is on hda and Slack is on sda. sdb is
> used for storage. After installing RHEL, Slack became FUBAR. On boot no
> startup scripts are executable. No name is given to the machine and
> login is impossible as TTYs are inaccessable. If I log in to RHEL, mount
> the Slack partitions and chroot, everything seems hunky-doryish and I
> can do nifty things such as post to AOLS saying "Hey look what I screwed
> up!".

Very strange one indeed, this one! And tracked down to the symlink
between /bin/sh and /bin/bash. I replaced it with sh -> bash as opposed
to sh -> /bin/bash

ln -s bash sh

while chrooted to the old system, and next boot was hunky-dory. Odd
since the structure hasn't changed in the least. The install of RHEL on
a separate disk was the catalyst for this. Got me on why.


Thanks to Alan Hicks for assistance.

--
AMERICAN WASTE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In alt.os.linux.slackware, Handover Phist dared to utter,
> Very strange one indeed, this one! And tracked down to the symlink
> between /bin/sh and /bin/bash. I replaced it with sh -> bash as opposed
> to sh -> /bin/bash
>
> ln -s bash sh

..... That doesn't make a damn bit of sense. Anyone have any idea why
this was (apparently) the problem? I cannot for the life of me imagine
why this would be a problem. There's gotta be something we're missing.

> Thanks to Alan Hicks for assistance.

Anytime.

- --
It is better to hear the rebuke of the wise,
Than for a man to hear the song of fools.
Ecclesiastes 7:5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCVnCyvgVcFKpJf4gRAuh5AKDIP/O+jM/Ev+WQ58zoLdYG+E+AFQCgzvOO
R78W7uOMydUunxwFDjAnenI=
=NS1R
-----END PGP SIGNATURE-----

+Alan Hicks+ blithely blithered
>
> In alt.os.linux.slackware, Handover Phist dared to utter,
>> Very strange one indeed, this one! And tracked down to the symlink
>> between /bin/sh and /bin/bash. I replaced it with sh -> bash as opposed
>> to sh -> /bin/bash
>>
>> ln -s bash sh
>
> .... That doesn't make a damn bit of sense. Anyone have any idea why
> this was (apparently) the problem? I cannot for the life of me imagine
> why this would be a problem. There's gotta be something we're missing.

I'm with you on this, I have no clue why this would make any difference
at all, but that's what happened. I googled for a week looking for
answeres and the only thing I could find that made any sense was the
startup scripts not being executable for some reason. The first in each
is #!/bin/sh. Reestablishing the link did the trick.

I work on these machines for a living. This one stumped all the techs I
work with as well, which makes fixing it all that much more satisfying.

--
All the waters of the earth are in the armpit of the Great Frog.
-- R. Crumb

Handover Phist wrote:
> Very strange one indeed, this one! And tracked down to the symlink
> between /bin/sh and /bin/bash. I replaced it with sh -> bash as opposed
> to sh -> /bin/bash
>
> ln -s bash sh

this makes me ask myself two things: what would have happened if you had
recreated the symlink as it was, i.e., `ln -s /bin/bash sh'? and how
are your other symlinks functioning?

oh, and another thing: how on earth did you figure this one out? or was it
just a lucky guess?

--
Joost Kremers joostkremers@yahoo.com
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9

On Fri, 08 Apr 2005 16:56:49 +0000, Joost Kremers wrote:
> Handover Phist wrote:
>> Very strange one indeed, this one! And tracked down to the symlink
>> between /bin/sh and /bin/bash. I replaced it with sh -> bash as opposed
>> to sh -> /bin/bash
>>
>> ln -s bash sh
>
> this makes me ask myself two things: what would have happened if you had
> recreated the symlink as it was, i.e., `ln -s /bin/bash sh'? and how
> are your other symlinks functioning?

hmmm. my fresh 10.1 install has /bin/sh -> bash
So i wonder, also. how it got to be /bin/sh -> /bin/bash
in the first place.

big weirdness.


> oh, and another thing: how on earth did you figure this one out? or was it
> just a lucky guess?

yeah give that man one shiny silver Bozo point emblazoned
with a gold Clue.



--
William Hunt, Portland Oregon USA