Bug 18403

What were the steps you took during the setup process? Knowing this will help us
recreate the problem.

Steps took were:
I selected install from cdrom-
chose generic mouse, monitor, and graphic card which was a rage pro with 4mgs ram.
I chose to install gnome only.
It then proceded with installing the software pack but failed at this point.
The partitians made were
/
/usr
/usr/home
/var
/swap
/local

I believe this should not cause a problem because those are the partitians I have
here with RH 6.2.

I hope this is sufficient-
Regards,
David

What are the sizes of the various partitions?

Okay-
/usr-2000
/usr/local-2000
/home-2000
/-80
/var-800
swap 125

I hope this helps too... it is an 8 gig hard drive...I only used 97% of the drive.

*** Bug 18614 has been marked as a duplicate of this bug. ***

*** Bug 18923 has been marked as a duplicate of this bug. ***

*** Bug 19343 has been marked as a duplicate of this bug. ***

In an effort to avoid taking too much effort to report this, allow me to provide this admittedly terse rendition (it was when I started):

With a storage partition layout more or less like the one recounted above, I had (apparently) the same problem.  Because I suspected the hard disk to be 
causing the problem, I tried a different use of the same layout, and it worked.  I didn't see anything reported suggesting the variation that I ended up 
trying:

                                       worked          error (two trials, error on same package!  So apparently reproducible?)
hda1              64M                                root
hda2              16M           (hdc2)        swap
hda3         ~750M               root            usr   <-- root and usr together worked; separate, not!
md0          1224M                var            var

If I go into more detail, I'll end up writing a book (I really hate composing email), but I should relate that I think my actual hardware scenerio and selected 
software (e.g. no G.U.I. stuff) is rather different from what's listed above, which is why I was struck by the fact that a similar problem occurred for me with 
nothing more than a similar storage layout.  One last item:  This was a N.F.S. install, which helped contribute to the number of imaginable culprits 
immensely!

P.S.  I realize that it's not exactly apropo at this juncture, but have you guys finally fixed the Kickstart stuff to use *existing* partition layouts correctly?  RHL 
6.2 would barf unless the install was allowed the privilege of *creating* the layout, with it's own limited intelligence, making it impossible to create 
multiboot systems without a lot of pain (contrarily, I can hardly wait (not) to bite deeply into the Win2K equivalent of Kickstart). Again, a N.F.S. install, if 
that matters.


Traceback (innermost last):
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/iw/progress_gui.py", line 20, in run
    rc = self.todo.doInstall ()
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1619, in doInstall
    self.createCdrom()
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1189, in createCdrom
    os.symlink(device, self.instPath + "/dev/" + cdname)
OSError: [Errno 28] No space left on device

Local variables in innermost frame:
device: hdd
list: ['hdd']
self: <todo.ToDo instance at 81bcdf0>
cdname: cdrom
count: 1

ToDo object:
(itodo
ToDo
p1
(dp2
S'method'
p3
(iimage
NfsInstallMethod
p4
(dp5
S'tree'
p6
S'/mnt/source/.'
sbsS'initlevel'
p7
I3
sS'progressWindow'
p8
(igui
ProgressWindow
(dp9
S'total'
p10
I262

In an effort to avoid taking too much effort to report this, allow me to provide this admittedly terse rendition (it was when I started):

With a storage partition layout more or less like the one recounted above, I had (apparently) the same problem.  Because I suspected the hard disk to be 
causing the problem, I tried a different use of the same layout, and it worked.  I didn't see anything reported suggesting the variation that I ended up 
trying:

                                       worked          error (two trials, error on same package!  So apparently reproducible?)
hda1              64M                                root
hda2              16M           (hdc2)        swap
hda3         ~750M               root            usr   <-- root and usr together worked; separate, not!
md0          1224M                var            var

If I go into more detail, I'll end up writing a book (I really hate composing email), but I should relate that I think my actual hardware scenerio and selected 
software (e.g. no G.U.I. stuff) is rather different from what's listed above, which is why I was struck by the fact that a similar problem occurred for me with 
nothing more than a similar storage layout.  One last item:  This was a N.F.S. install, which helped contribute to the number of imaginable culprits 
immensely!

P.S.  I realize that it's not exactly apropo at this juncture, but have you guys finally fixed the Kickstart stuff to use *existing* partition layouts correctly?  RHL 
6.2 would barf unless the install was allowed the privilege of *creating* the layout, with it's own limited intelligence, making it impossible to create 
multiboot systems without a lot of pain (contrarily, I can hardly wait (not) to bite deeply into the Win2K equivalent of Kickstart). Again, a N.F.S. install, if 
that matters.


Traceback (innermost last):
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/iw/progress_gui.py", line 20, in run
    rc = self.todo.doInstall ()
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1619, in doInstall
    self.createCdrom()
  File "/var/tmp/anaconda-7.0.1//usr/lib/anaconda/todo.py", line 1189, in createCdrom
    os.symlink(device, self.instPath + "/dev/" + cdname)
OSError: [Errno 28] No space left on device

Local variables in innermost frame:
device: hdd
list: ['hdd']
self: <todo.ToDo instance at 81bcdf0>
cdname: cdrom
count: 1

ToDo object:
(itodo
ToDo
p1
(dp2
S'method'
p3
(iimage
NfsInstallMethod
p4
(dp5
S'tree'
p6
S'/mnt/source/.'
sbsS'initlevel'
p7
I3
sS'progressWindow'
p8
(igui
ProgressWindow
(dp9
S'total'
p10
I262

Wow... interesting...I want to thank you for the input.  Could you explain how to set up the root and usr partition together.  I am not 
sure how you did this.  I thought they had to be seperate partitions.

Regards,
David

Sorry to have you write another email.  I definitely want to install this and get it working cause I love RedHat myself.

Yeah, so, so much for being short winded about all this.
 
I believe I should add that at one point I used the 'df' command to determine that none of the partitions were anywhere near capacity, even with these 
small sizes in comparison to what others have been using.

Furthermore, on one trial, I *did* move the partition layout to different cylinders, because of the suspected hard disk trouble, with root and usr still split, 
and again got the error.  On all other occassions, not splitting usr off of root works, but splitting it off doesn't.

Whoaa, uh, sorry, I just noticed your additional comment after my last one.

The simplest partition layout that you can use is a single partition mounted at the root of the file system.  This is analygous to the single C: drive 
arrangement of Microsoft products.  The linux file system software will allow you to sub-divide your system installation across a collection of different 
storage devices while retaining the semantics of a monolithic storage arrangement (whew!).  To wit, all you have to do is install onto a single partition 
and it should work (although I have yet to actually try this particular layout myself since there are so many reasons not to use it; great for experiments like 
this one, undesirable otherwise).

Specifically, as far as I can tell, the problem crops up when the usr folder is mounted on its own partition.  Separating out var doesn't cause the problem 
(as I remember), and so I'd guess you'd be safe pulling home out as well (your original layout was sub-divided rather profoundly, which, here, I'm 
assuming you consider a desirable objective).  usr/local may be another matter since it's above usr itself in the folder hierarchy.  But, of course, at that 
point, we're well and truly into the thick of an empirical research program...  Best not to exhaustively explore the problem space, eh?

Good luck.  I'll check back later to see what cooks...

O.K., so by now you've noticed I like the sound of my own keyboard...  I just looked over your comments again, and this time I really read them (I think) and 
believe I will remember them throught-out the rest of this missive.  Oh, and B.T.W., an important aside, since you're a self-proclaimed novice, none of my 
references to root mean the folder with the name "root", which is, of course, the home folder for the root account.

Specifically you said that you thought root and usr have to be separate, which is untrue, and so I wanted to mention in particular that sub-dividing the file 
systems storage layout is highly desirable in many cases, but definitely not required.  As I said above, about the only time I would use such a layout is to 
experiment.  In fact, up until recently when the size of the distribution began to seriously overwhelm the storeage resources on my systems, with every 
new distribution, the first install I would do was of *everything* to a single partition.

Everything, because it's simple to choose when you can't possibly know what to choose, because you can't tell if you need it, because you don't have 
access to the documentation until you install it, which, if you're with me, means everything you're unfamiliar with is "automatically selected" for you since 
you don't know what most of it is, and won't until you install it.  I'm sorry I headed this way to some degree ... wasn't planning on treating everyone to such 
a dose of detail, but the fact that you can install the software without the documentation (with RPM, post-install) is only nice.  Why RPM (or the installer for 
that matter) doesn't have a switch to allow installing the *documentation only* for a package is beyond me; I would make liberal use of it and save myself 
a *lot* of storage capacity in the process.  In whatever my allocation for usr is, no less!  (end of rant)

After booting up, type the command 'du -sm /*' (disk usage, summary in megabytes of all folders above the root folder).  This tells you how much storage 
is needed for each main folder in the system.  If you decide to sub-divide the file systems' storage allocations among more than one partition, the most 
challenging aspect of that then becomes, how much should a partition get?  This is quite likely a deterministic problem, but I assure you it's also quite 
non-trivial, incredibly important to get right, and underscores the current day limitations of approaches to computer system mass storage arrangements.  
Specifically, sub-divide as little as possible.  No sub-division is somewhat equivalent to the "all your eggs in one basket" syndrome, but the non-triviality 
of determining multiple storage allocations should give only the best cold feet about dividing everything up to a fair-thee-well.

Suffice to say that simple sub-divisions produce the greatest benefit.  Running an N.F.S. server?  Split usr off because it needs to be accessed across a
network and the rest of your files shouldn't be in the same boat.  Mail, news, and/or print server?  All of these make heavy use of var (in fact, var/spool) 
and each could conceivably demand a large allocation, so they don't become choked through normal use or abnormal abuse (spam, for instance).  So 
split var off (and maybe *not* usr), in order to protect your entire file system from being choked instead of just var.  Capice?

The real bear of this is, that a system installation is dependent on its storage arrangements and that means those decisions must be made prior to 
installation, instead of afterwards, at one's leisure.  And yet storage is also "just another peripheral" and, as such, deserves to have decisions about it 
made in conjunction with decisions regarding other system resouces, in order to believe that an intelligent and coherent approach was used in 
envisioning the system.  Decisions made in isolation rarely contribute well to the whole; decisions regarding the systems storage allocations made 
in the isolation of the installation phase, need to be made with the intelligence of knowing what the system is to be used for, not simply what will allow a 
certain selection of software to fit.

There's got to be a how-to that explains this at least as well as I, since I must'a larned it somewhere...



Rest is optional:

P.S.  God bless software RAID.  Now if I could just get var and home to share the same (software RAID) storage device, so I could have a *single* large 
allocation of non-read-only storage for both of them, and therefore reduce the number sub-division allocations required by one, storage allocation 
decisions would be that much easier and a step closer to trivial.

Specifically, separate folder hierarchies cannot be merged onto the same storage device.  The effect would be the reciprical (inverse?) of software 
RAID, and would prevent the possiblity that a surplus of storage that one folder is mounted on doesn't lie around fallow, while the next folder is straining to 
meet the storage expectations being applied to it

An analogy:

Trying to box the parts, not just put parts in boxes:

If you break "something big" up into pieces to ship it, you might place the pieces into separate boxes.  Some pieces will be too big for a box, others 
won't use the whole space available.  The boxes were most likely pre-made, but with a computer the "boxes" can be custom made, but only to a point, 
because, even here, real limitations exist (i.e. hard disk capacities).  The pieces of the "something" can only be arbitrary in size to a certain degree as 
well, because they're usually the main sub-components of the something (it's "parts", no less; not to be confused with disk partitions).  With computer 
systems, the "parts" are the folders.  Being able to put two "parts" into the same box could be a better choice than making two smaller boxes that fit the 
given "parts", especially ifthey're both being shipped in the same manner.  Fewer items might be easier to track in transit.

Say, I don't know how much of this you got, but I feel a whole lot better :-)

Haven't seen any feedback here, so now I'm wondering whether enough of the right things have been said.  Reflecting on what I've already posted 
regarding a "root only" storage layout, it seems to me that I've provided a lot of description, but little prescription.  So, another try:

Using 'fdisk' during the installation, you need to create two partitions only: One for the file system itself and another for swap.  The amount of swap you 
allocate should be at least the amount of core memory (R.A.M.) in your system.  The other partition should include all the remaining storage you intend to 
allocate to linux.  The very next step is to specify the mount points of the system.  In this case, there's only the root, so for the really big linux partition that 
you just created, specify the mount point as '/', and that's it for the DiskDruid step.  The rest is as it would be otherwise.

A mild digression:
The reason for the amount suggested for swap is that when a system crash occurs, the system will make a last ditch effort to provide an indication of 
what was going on when the system went down by writing the entire contents of core memory to the swap partition.  This is called a "core dump," and can 
very useful in conducting post-mortem diagnostics, but not if any of the core memory write didn't make it because, say, the swap partition was too small.

Please note that the swap size I mentioned I was using is much smaller than the memory of the system, so of course, I planning on *not* being able to 
conduct post-mortem diagnostics if my system dies.  The system I was setting up is intended to be a gateway router and an analysis of why it crashed 
will probably not be of value to me.  You're setting up what will principally be a personal workstation, and thus you *may* (conceivably) want to conduct 
post-mortem diagnostics if your system dies, so swap should be at least the size of core.  I say "may" because, that I know, it's pretty advanced stuff; I've 
never done it yet.

You may want to allocate a very large amount of swap compared to core memory, but the reasons for doing so require the same kind of technical 
understanding and analysis that choosing appropriate sizes for regular storgage partitions entail.  For example, a good motivation for choosing a very 
large swap is that core memory may be very small relative to the intended purpose of the system.  A web server with a small amount of memory may do 
better with a swap partition 3-4 times the size of core memory, especially if the processor is fast.  It's hard to say what's "right" because it's a system, 
and system analysis is inherently complex.

Also, when swap exceeds core memory, the system is rightly viewed as having the "amount of memory" that the swap represents:  With 32MB of core 
memory and a 128MB swap partition, the view is that the system is a 128MB system, with a 32MB "window" into that 128MB space.

*** Bug 19995 has been marked as a duplicate of this bug. ***

*** Bug 21225 has been marked as a duplicate of this bug. ***

The short answer is that you need to make the / partition at least 150 MB.  I
think the problem is that you are running out of inodes and it appears as if you
are out of space on the drive, but you really aren't out of space...you just
can't create any more files.  I'm looking into a better solution...

I think this has been fixed in internal builds because I am unable to reproduce
it.  Another developer informed me that this bug has been fixed after 7.0 was
released.  Brock, can you try to reproduce this bug as well?  Maybe you know
something I don't, but I wasn't able to reproduce.

This issue has been dealt with in later versions of our installer by popping up
a dialog box warning the user of the conditions that lead to this problem, and
allowing them to choose to continue ... it will occur if the user is trying to
setup a root filesystem with less than 250 Mb ... thanks for you report and your
efforts in documenting the problem, it is appreciated! :)

*** Bug 33669 has been marked as a duplicate of this bug. ***