ran out of input data

xushi · 02-27-2006, 08:08 AM

Hi all.

For some reason my server crashed today, and when i reboot it, it starts lilo, selects the kernel (2.4.31) and says

Loading Slack101

refreshes, and then i get a black screen and that's it...

I tried booting from CD, and everything seems fine. I replaced the kernel with the one found in slack 10.1 cd (2.4.29), and it gave me the same problems.

This time i booted with vga=normal and i get this error message

Code:

Loading............................
Uncompressing Linux...

ran out of input data

-- System halted

Searching LQ and googling didnt give me that good results. I'm wondering if anyone can aid me here.

Thanks.

satinet · 02-27-2006, 08:55 AM

did you change the kernel between the crash?

sounds like you haven't updated lilo properly.

http://lists.debian.org/debian-user/.../msg01910.html

however, it could be some other bug...

xushi · 02-27-2006, 09:31 AM

Quote:

Originally Posted by satinet

did you change the kernel between the crash?
sounds like you haven't updated lilo properly.
http://lists.debian.org/debian-user/.../msg01910.html
however, it could be some other bug...

Already checked that link out. thanks.

Hmm, i updated the same way i always update it.. manually by downloading the tgz images from slackware's package repo in slackware.com, remove the old, install the new, run lilo, and reboot. For some reason, this machine is not liking the default 2.4.32. And when i tried the 2.4.29 it also gave the same problems.

However, i just ran fsck -fv not only on my / hard drive, but the other one connected too, and both reported problems, some missing inode stuff, etc.. fixed them all. I also noticed many wierd files in /boot i've never seen before (like boot.123, something.img) ..

I just removed the kernel again from pkgtool, deleted everythiing in /boot, reinstalled 2.4.29, ran lilo, rebooted, and i think that did the trick. I don't mind staying with 2.4.29... this is just a simple server and any kernel would do.

I hope this helps anyone else who gets a similar problem. My hypothesis of the cause? A very bad crash.. check your partitions, check the /boot folder, and reinstall the kernel.

satinet · 02-27-2006, 11:18 AM

i think there is a bug in this somewhere, also a crash is pretty rare. know what caused it??

BCarey · 02-27-2006, 12:58 PM

You might want to be extra diligent about backing up your data for a while, as this could have been a hardware failure.
Brian

xushi · 02-27-2006, 01:06 PM

Quote:

Originally Posted by satinet

i think there is a bug in this somewhere, also a crash is pretty rare. know what caused it??

I'm afraid not.. But could it be from over stressing it? It's been on for months, with alot of traffic going through it, and it can barely stay running. It's a p3 600 with 128Mb ram, running X + ... err.. fwm i think.

Quote:

Originally Posted by BCarey

You might want to be extra diligent about backing up your data for a while, as this could have been a hardware failure.
Brian

Heh.. yea i juse backed up all the data out of it. I hope not.. but you might be right. I bought it second hand a few months ago, and it had 2 sticks of ram in it of which both failed within a month. I replaced them with a good 128Mb one.

Is there a way to have a system log to log everything that happens, including any crashes, kernel panicks, segfaults? dmesg is good but it can't record crashes (from what i see).

satinet · 02-27-2006, 01:13 PM

what are you using the box for if i may ask??

syslog is more verbose. and the kernel logger is klogd.... not sure how to config it tho. i've never investigated what it does to be honest... logs kernel stuff eh ;-)

xushi · 02-28-2006, 08:18 AM

Quote:

Originally Posted by satinet

what are you using the box for if i may ask??

syslog is more verbose. and the kernel logger is klogd.... not sure how to config it tho. i've never investigated what it does to be honest... logs kernel stuff eh ;-)

Let's hope the logs don't eat up too much space.. the / partition has 100mb free left.. hehe

I use the box as a download server for anything (legal) i need to download for my degree which i cant from uni (blocked ports & limited bandwidth).

I'll read up on the loggers. Thanks.

xushi · 02-28-2006, 01:23 PM

Crap.... i really hate it when i'm proven wrong in such hardware related situations... double c... argh. Does the following mean i need to replace my hard drive?

I noticed the past few days when using df -h i only get

Code:

/dev/sdb1              17G   16G  9.3M 100% /mnt/hd2

But i know the hard drive has a few gigs free in it.. So i check dmesg, and this is what i see

Code:

kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,3), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
PCI: Found IRQ 11 for device 00:11.0
PCI: Sharing IRQ 11 with 00:07.2
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
00:11.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xdc00. Vers LK1.1.18
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:07.2
PCI: Sharing IRQ 11 with 00:11.0
uhci.c: USB UHCI at I/O 0xdce0, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: shpc_init : shpc_cap_offset == 0
shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.5
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
PCI: Found IRQ 10 for device 00:0e.0
scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec 29160 Ultra160 SCSI adapter>
        aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs

(scsi1:A:6): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
(scsi1:A:9): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
  Vendor: QUANTUM   Model: ATLAS10K3_18_WLS  Rev: 020W
  Type:   Direct-Access                      ANSI SCSI revision: 03
  Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
  Type:   Direct-Access                      ANSI SCSI revision: 03
scsi1:A:6:0: Tagged Queuing enabled.  Depth 8
scsi1:A:9:0: Tagged Queuing enabled.  Depth 8
Attached scsi disk sda at scsi1, channel 0, id 6, lun 0
Attached scsi disk sdb at scsi1, channel 0, id 9, lun 0
SCSI device sda: 35916548 512-byte hdwr sectors (18389 MB)
 sda: sda1
SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
 sdb: sdb1
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT2-fs warning (device sd(8,17)): ext2_read_super: mounting ext3 filesystem as ext2

The bottom part caught my eyes, sdb is my scsi disk, and it's ext3, not ext2 ... I'm backing up everything out of it as we speak, but are there any tests i can do to make sure if it's busted or not? It comes to me as a shock because it's a SCSI hd that should last more than 5 years... =/

From /var/log/syslog

Code:

Feb 26 19:47:03 storage kernel:         <Adaptec 29160 Ultra160 SCSI adapter>
Feb 26 19:47:03 storage kernel:         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
Feb 26 19:47:03 storage kernel: 
Feb 26 19:47:19 storage kernel: (scsi1:A:6): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit)
Feb 26 19:47:20 storage kernel: (scsi1:A:9): 160.000MB/s transfers (80.000MHz DT, offset 63, 16bit)
Feb 26 19:47:23 storage kernel:   Vendor: QUANTUM   Model: ATLAS10K3_18_WLS  Rev: 020W
Feb 26 19:47:23 storage kernel:   Type:   Direct-Access                      ANSI SCSI revision: 03
Feb 26 19:47:23 storage kernel:   Vendor: IBM       Model: DDYS-T18350N      Rev: S96H
Feb 26 19:47:23 storage kernel:   Type:   Direct-Access                      ANSI SCSI revision: 03
Feb 26 19:47:24 storage kernel: scsi1:A:6:0: Tagged Queuing enabled.  Depth 8
Feb 26 19:47:24 storage kernel: scsi1:A:9:0: Tagged Queuing enabled.  Depth 8
Feb 26 19:47:24 storage kernel: Attached scsi disk sda at scsi1, channel 0, id 6, lun 0
Feb 26 19:47:24 storage kernel: Attached scsi disk sdb at scsi1, channel 0, id 9, lun 0
Feb 26 19:47:24 storage kernel: SCSI device sda: 35916548 512-byte hdwr sectors (18389 MB)
Feb 26 19:47:24 storage kernel: SCSI device sdb: 35843670 512-byte hdwr sectors (18352 MB)
Feb 26 19:48:26 storage kernel: EXT2-fs warning (device sd(8,17)): ext2_read_super: mounting ext3 filesystem as ext2

fsck -fv /dev/sdb1

Code:

root@storage:/mnt# fsck -fv /dev/sdb1
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
                                                                               
      92 inodes used (0%)
       1 non-contiguous inode (1.1%)
         # of inodes with ind/dind/tind blocks: 31/35/0
 3459169 blocks used (77%)
       0 bad blocks
       0 large files

      72 regular files
      11 directories
       0 character device files
       0 block device files
       0 fifos
       0 links
       0 symbolic links (0 fast symbolic links)
       0 sockets
--------
      83 files

Code:

root@storage:/mnt# hdparm /dev/sdb

/dev/sdb:
 readonly     =  0 (off)
 readahead    = 120 (on)
 geometry     = 2231/255/63, sectors = 35843670, start = 0

And on a side note.. i don't really understand the relation between this situation, and the kernel error i previously had. Linux is installed on another harddrive.

Edit:
Erm.. where in /proc can i find the info about the scsi hard drive? I can only find this,

Code:

root@storage:/proc/scsi# d
aic7xxx/  ide-scsi/  scsi  sg/
root@storage:/proc/scsi# ls aic7xxx/
1
root@storage:/proc/scsi# ls ide-scsi/
0
root@storage:/proc/scsi# ls sg
allow_dio  debug  def_reserved_size  device_hdr  device_strs  devices  host_hdr  host_strs  hosts  version
root@storage:/proc/scsi#

I was looking for something like /proc/ide/ide1/settings

Franklin · 02-28-2006, 07:08 PM

I have seen some of these errors before. I don't "think" this is a hardware issue.

I wonder if something corrupted lilo and/or the MBR during the crash. I know you stated that you ran lilo after changing the kernel, but I wonder if removing lilo and reinstalling it might help. I realize I'm grasping at straws here, but "ran out of input data --- System halted" is a lilo error, and the other errors regarding reading the ext3 as ext2 I've seen during a f'd up Debian install on a multi-boot system. I don't remember the cause or the cure any longer, but the effect was due to an improperly loaded kernel and/or modules.

Just a thought. Ignore at will

xushi · 03-02-2006, 07:57 AM

Hmm, it's running fine for the past day or two.. I'll take your advice and reinstall or upgrade lilo. Would i just need to upgrade it and run lilo again ?

Franklin · 03-02-2006, 06:36 PM

I wouldn't upgrade it necessarily. I think uninstalling and then re-installing might be enough to see if indeed lilo was corrupted by the crash. Then again, if it appears to be running OK perhaps one should not temp fate?

When I'm trying to solve problems by trial and error I try to make small changes to track effects easier and limit the introduction of new variables into the system. Besides, if it worked fine before, I doubt it suddenly needs an upgrade.

As far as reinstalling, yes after it is reinstalled you will need to run "lilo" as root before rebooting.
The easiest way would be through pkgtool - setup - liloconfig and reinstall it to the mbr.

Good luck!