Re: [cobalt-users] Update failure installing Qube3-ml-Update-4.0.pkg

[Sonny Taite <sonny@xxxxxxxxx>]

Okay Lloyd,

If you want to continue to debug the old drive do the following:

Boot it up and run the command:

dmesg > /tmp/boot.messages

Now more (or vi) the file /tmp/boot.messages - this will give you quite a
detailed list on what happened during boot up. You will be looking for
entries for the dp* driver and the eth0/eth1 interfaces coming up, or errors
around that point.

You may also like to check the state of the kernel modules with

modprobe -c

AND

lsmod

modprobe -c will show you the current config - which modules are turned
on/off etc

lsmod will show you which modules are currently loaded.


Work on what the boot.messages file is saying first as that may give direct
clues as to what is happening to your network.


Let us know how that goes.

Sonny.





On 9/25/02 9:00 AM, "Lloyd Kvam" <lkvam@xxxxxxxxx> wrote:

> Sonny Taite wrote:
> 
>> Always a tricky problem!
>> 
>> My only advice is before you give in, try to work out why it is not booting,
>> and why the ethernet devices are not coming up.
>> 
>> If you can get a command line:
>> 
>> 1. cat /etc/modules.conf - looking for alias eth0 dp83815 and eth1 dp83815
>> 
>> Short version: this says load the kernel module/driver for eth0/1
> 
> 
> Yes, these lines are present
> 
> 
>> 
>> 2. if these exist use "ifconfig eth0 up" command to see if it will come up
>> without any more mucking around
> 
> 
> It will not come up.  No such device.
> 
> 
> 
>> 3. if 1 is true but 2 is not, then cd /etc/sysconfig/network-scripts and
>> look at the ifcfg-eth0 and ifcfg-eth1 files - they will have the information
>> for your networks.
> 
> 
> These are OK.
> 
> 
> 
>> 4. thank the allmighty command line, and curse the gui gods.
> 
> 
> AMEN
> 
>> 5. if none of this works, and the machine won't even boot, then it might be
>> easier to restore the machine, rather than follow detailed instructions from
>> the mailing list.
> 
> 
> We restored onto a second disk drive.  We then tried applying the updates to
> the
> new drive.  It also failed at this update!?*%$#  So we restored the new drive
> again and tried to debug the old drive.
> 
> 
>> Give that stuff ago and let us know how you get on.
>> 
>> 
>> 
>> rgs
>> Sonny
>> Cazab Communications Limited
> 
> We have the mail server back in operation by copying files from the old drive
> to the new drive.  (etc/*mail* + passwd group shadow)  The GUI is unable to
> list
> the users, though they can still check mail through POP and it accepts mail
> through
> SMTP.  Apparently there is a backend database that holds this user
> info separately from the normal files.  Manual updates to the normal files
> seem
> to be in constant danger of getting replaced from the gui driven mechanism.
> 
> Where is the backend database?  Can I simply copy that from the old drive to
> the
> new drive?  Alternatively if I can get the old drive working, we can simply
> copy back
> the latest mail and mqueue contents and be back in business.