Bug 602628 - Installation fails with --fsprofile largefile
Installation fails with --fsprofile largefile
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks: 582286
  Show dependency treegraph
 
Reported: 2010-06-10 07:05 EDT by Alexander Todorov
Modified: 2016-06-09 13:31 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-10 10:49:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tarball of all logs from stage2 (36.71 KB, application/x-gzip)
2010-06-10 07:17 EDT, Alexander Todorov
no flags Details

  None (edit)
Description Alexander Todorov 2010-06-10 07:05:22 EDT
Description of problem:

Installation proceeds halfway and then shows error message that it can't install a particular package (vim or man-pages, doesn't matter). tty1 says:

/mnt/sysimage/var/lib/rpm: No such file or directory
/mnt/sysimage/var/lib/rpm: No such file or directory

This happens when the ks.cfg file contains --fsprofile largefile:

$ cat ks.cfg 
install
lang en_US.UTF-8
keyboard us
network --device eth0 --bootproto dhcp
rootpw --plaintext redhat
authconfig --useshadow
selinux --enforcing
timezone America/New_York
bootloader --location=mbr
clearpart --all --initlabel

part /boot --asprimary --fstype="ext4" --size=200 --label=BOOT --ondisk=vda
part swap --fstype="swap" --recommended --label=SWAP --ondisk=vda
part raid.01 --grow --size=2048 --ondisk=vda
part raid.02 --grow --size=2048 --ondisk=vdb
raid / --device=0 --fstype="ext4" --level=RAID1 raid.01 raid.02 --fsprofile largefile

graphical

%packages
@Base
@Core
%end

Version-Release number of selected component (if applicable):
anaconda-13.21.50-2.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Create a KVM domU with 0603.1 snapshot, with 2 disks
2. Mine are: vda: 20G, vdb: 10G
3. Boot with 'linux method=http://... ks=http://...'
4. Use the above ks. Note the / partition and --fsprofile option.
  
Actual results:
Installation proceeds halfway, installs around 200 packages from the base groups and then shows a message that package can't be installed. The only option is to exit the installer.

Expected results:
Installation will finish and the created filesystem will match configuration in /etc/mke2fs.conf 

Additional info:
This also happens with LVM.
Comment 1 Alexander Todorov 2010-06-10 07:17:52 EDT
Created attachment 422868 [details]
tarball of all logs from stage2

program.log says:
ERROR   : mdadm: largest drive (/dev/vda2) exceeds size (10484636K) by more than 1%

what does this mean?
Comment 2 Martin Banas 2010-06-10 07:41:21 EDT
Hi Alex,

I also found this problem on PPC64, but it seems it's correct behaviour.

For example if you create 200MB filesystem with --fsprofile largefile, inode_ratio is 1048576, and so the maximum number of inodes is 200.

Max Inodes = (FS Size x 1024 x 1024) / inode_ratio

I think you reached max count of inodes for the filesystem (which was about 8000).
Comment 3 Martin Banas 2010-06-10 07:43:30 EDT
Correction: about 10000 inodes.
Comment 4 Alexander Todorov 2010-06-10 08:05:19 EDT
This all sounds very possible. I'd like to hear from anaconda guys if there's a way to detect this and show a proper error message or improve logging probably. For example the number of inodes vs the number of all files installed on the system.
Comment 5 Chris Lumens 2010-06-10 10:49:00 EDT
Unlikely.  This happens so far down in the stack that we're never going to hear about it.  What's going to happen is that some write will fail way down in the kernel, which will get transmitted up a layer to whatever was doing the write, handled and reconverted into some other error, passed up another layer, ..., handled by anaconda as some generic error message.  The loss of information is just going to be too great.
Comment 6 Dave Johansen 2013-12-13 11:18:24 EST
Could a check at least be made on the root partition to output a warning/error about the number of inodes being small so that when this happens it would be easier to debug/diagnose?
Comment 7 David Lehman 2013-12-13 12:31:41 EST
(In reply to Dave Johansen from comment #6)
> Could a check at least be made on the root partition to output a
> warning/error about the number of inodes being small so that when this
> happens it would be easier to debug/diagnose?

No, this is not at all practical. We don't need to know the various profiles, nor do we need to know so much about them that we can warn in advance if their use is ill-advised. This is advanced functionality, and expects that the user do the required research before using it.
Comment 8 Dave Johansen 2014-01-06 12:02:17 EST
> (In reply to David Lehman from comment #7)
> No, this is not at all practical. We don't need to know the various profiles,
> nor do we need to know so much about them that we can warn in advance if their
> use is ill-advised. This is advanced functionality, and expects that the user do
> the required research before using it.

I agree. Knowledge of the specific profiles and other such issue is impractical, but couldn't some simple checks for things like the number of inodes or available disk space be done? Right now, it fails part way through the install with no indication as to what the problem is and a simple warning before hand or a meaningful error message when it happened would be very helpful to diagnose what the problem really is.

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