Bug 502286 - Kickstart induced error
Kickstart induced error
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-23 03:05 EDT by A.J. Werkman
Modified: 2009-06-30 17:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-30 17:45:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Attached traceback automatically from anaconda. (173.18 KB, text/plain)
2009-05-23 03:05 EDT, A.J. Werkman
no flags Details

  None (edit)
Description A.J. Werkman 2009-05-23 03:05:25 EDT
The following was filed automatically by anaconda:
anaconda exception report
Traceback (most recent call first):
  File "/usr/lib/anaconda/booty/x86.py", line 154, in writeGrub
    f = open(cf, "w+")
  File "/usr/lib/anaconda/booty/x86.py", line 534, in write
    justConfig | (not self.useGrubVal))
  File "/usr/lib/anaconda/bootloader.py", line 204, in writeBootloader
  File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext
  File "/usr/lib/anaconda/text.py", line 712, in run
  File "/usr/bin/anaconda", line 965, in <module>
IOError: [Errno 2] No such file or directory: '/mnt/sysimage/boot/grub/grub.conf'
Comment 1 A.J. Werkman 2009-05-23 03:05:34 EDT
Created attachment 345180 [details]
Attached traceback automatically from anaconda.
Comment 2 Bill Nottingham 2009-05-29 00:05:23 EDT
How were you installing?
Comment 3 Bill Nottingham 2009-05-29 00:21:48 EDT
Let me rephrase - can you attach the kickstart you were using?
Comment 4 A.J. Werkman 2009-05-29 04:55:37 EDT
# Kickstart file Digifarma BV
url --url http://<server>/fedora/development/i386/os
lang en_US.UTF-8
keyboard us

# Network configuration.
network --device eth0 --bootproto static --ip <IP> --netmask <MASK> --gateway <GW> --nameserver <NS> --hostname host.digifarma.nl

rootpw ***********
firewall --disabled
authconfig --enableshadow --passalgo=sha512
selinux --disabled
timezone --utc Europe/Amsterdam

bootloader --location=mbr --timeout=20 --append="nomodeset"
clearpart --all --initlabel
#part /boot --fstype ext3 --size=512 --grow --maxsize=1024
#part / --fstype ext3 --size=1024 --grow

part /boot --fstype ext3 --size=512
part pv.7 --size=10 --grow --ondisk=sda
volgroup VolGroup00 --pesize=32768 pv.7
logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=1000 --grow --maxsize=1984
logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
#part swap --size=512 --grow --maxsize=1024

repo --name="Fedora rawhide - i386" --baseurl=http://<server>/fedora/development/i386/os



Comment 5 Chris Lumens 2009-06-02 10:09:21 EDT
The underlying problem is a filesystem error:

<6>sda1: rw=0, want=1311256, limit=1048576
<2>EXT3-fs error (device sda1): read_inode_bitmap: Cannot read inode bitmap - block_group = 5, inode_bitmap = 163906
<2>EXT3-fs error (device sda1) in ext3_new_inode: IO failure
<6>attempt to access beyond end of device

that is preventing the grub package from being installed:

Installing grub-0.97-50.fc11.i586
error: unpacking of archive failed on file /boot/grub: cpio: mkdir failed - Input/output error
Comment 6 Dave Jones 2009-06-03 14:11:25 EDT
my guess here is some kind of hardware problem.  Eric ?
Comment 7 Eric Sandeen 2009-06-03 14:16:57 EDT
Looks like another case of the device being smaller than the filesystem, something which anaconda was happily doing up until recently... dlehman? :)

Comment 8 Eric Sandeen 2009-06-03 14:23:34 EDT
On second (parallel) thought - A.J. is this /dev/sda1 still intact so we can do some inspection of it?

Comment 9 Eric Sandeen 2009-06-03 14:30:24 EDT
device limit is:	1073741824 (262144 blocks)
mkfs'd:			1069252608 (261048 blocks)
tried to read:		1342726144 (327814 blocks)

dunno what may have gone on in between.  Looking at /dev/sda1 would help.

Comment 10 A.J. Werkman 2009-06-04 03:38:53 EDT
I have this system intakt, as far as hardware is concerned. I use it as a testing machine, so the harddisks have been altered a lot since I ran into this bug.

But tell me what you want to know, what you want me to test.

Comment 11 Eric Sandeen 2009-06-04 11:22:56 EDT
A.J. if /dev/sda1 has been altered since the bug was filed then not so interesting, I guess.  If it's the same size, and un-mkfs'd since then, then I guess as a start I'd like to see what "e2fsck -fn" says about it.

Comment 12 Bug Zapper 2009-06-09 12:24:44 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 13 A.J. Werkman 2009-06-11 04:02:18 EDT
I have blank the disk after this bug a few times, so I can't garanty this information covers the situation that led to the bug. But I tried to reproduce the situation. I see block coutn errors, but don't know if this is relevant to this bug.

My "e2fsck -fn /dev/sda1" output is as follows:

Warning!  /dev/sda1 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
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
Free blocks count wrong (239641, counted=234257).
Fix? no

Free inodes count wrong (65237, counted=65235).
Fix? no

/boot: ********** WARNING: Filesystem still has errors **********

/boot: 43/65280 files (0.0% non-contiguous), 21407/261048 blocks
Comment 14 Eric Sandeen 2009-06-11 10:31:11 EDT
Well, checking live filesystems is expected to find some inconsistencies.

If you can recreate the problem from kickstart as originally reported, when things fail due to IO errors, -then- I'd like to be able to take a look at the filesystem, starting with an e2fsck -fn, as well as dumpe2fs -h output and the partition's size in /proc/partitions.

But if you've since had a successful install which overwrote the problematic filesystem, then I'm afraid the state of the filesystem is no longer interesting.

Comment 15 Eric Sandeen 2009-06-30 17:45:04 EDT
I'm going to close this, not sure we can get further info.  If you see it again, or can reproduce at will, please re-open and we'll keep diggging.


Note You need to log in before you can comment on or make changes to this bug.