Mailinglist Archive: opensuse-bugs (7967 mails)

< Previous Next >
[Bug 239630] Documented 256MB not sufficient for install, requires 384MB.
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 21 Feb 2007 19:47:57 -0700 (MST)
  • Message-id: <20070222024757.4C00325C887@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=239630





------- Comment #19 from webclark@xxxxxxxxxxxxxxxx 2007-02-21 19:47 MST -------
Warning, this is long. But I think/hope I make some good points. I will try
to convey difficulties I see with the current situation and explain how I
believe it can be fairly easily addressed. Please forgive me if I come across
as being excited... I am! I am anxious for Linux to be usable by "normal"
people, and I feel that there is a very thin barrier, the main barrier being an
assumption by Linux people that the user knows how Linux works on the inside,
and that if they don't, too bad, they better go learn. I believe the concepts
you need to convey are are easy and the functionality you need to provide is
minimal.

What does do a "minimal installation without add-ons first" mean? That I can
do anything I want with the base, just don't do any add-ons? Or should I also
just accept the default to minimize changes (which generate logs)? Or should I
cut down the package list to minimize what is installed? And will this work
with 256MB? You specify 512MB, but I feel that 256MB is a magic number because
Linux does not run too bad in 256MB for a single user, and I have 6 machines
with that constraint. But can I install? People's old windows machines are
becoming less and less functional, and they balk at pouring money into a new
machine and XP or Vista. They just need reason to hope that it is going to
work and not be a hassle. This is a real opportunity for Linux.

Having read the "Installation with Little Memory" guidance on the wiki, these
are written for someone who is familiar with the Linux and/or Suse boot
process. This is probably obvious to the author, but not to your average user.
This is good for one set of users who wants to know, but not most who want to
get it installed. I am no dummy, and have been using and installing various
version of UNIX, SunOS, and Linux for 30 years. I can understand almost
anything, but I don't know the implementation details of the linux boot process
(although I am learning). And everyone does not WANT to understand, or have
time to understand.

>>>>> But before it is made more usable, there is something more important, whether you do anything about helping people with low memory or not:

[1] Enable the installer to monitor space or detect when it runs out of memory
BEFORE it malfunctions. Put up a message and stop, even if very ungracefully.
Rule number one is to not continue working in a corrupted state. Currently you
get corrupted during package selection and continue, partitioning and continue,
etc. Stuff I put in disappears, and I just keep recirculating in the menus
hoping it will stick and I can get an install. Sometimes I can! If I get
through, what confidence do I have that it worked right? What about if I have
enough memory that I have no apparent problems? Can I trust that there are no
hidden problems that are going to cause unexplained problems to chase later?
Something that fell off of the end of the shell variable assignment on a
boundary that happened to not cause a problem? What if it appears to work and
I load all my data on but something is not right? I need to have 100%
confidence that *IF* I get through the install smoothly, that it worked
correctly, as I specified.

As for dealing with low memory:

[2] You indicate that one can do the add-ons later. I was not sure if there
were trade offs between doing it up front vs. later, and I was not aware that
selecting it used a substantial amount more memory. A list of 10,000 50
character package names would only take 512K of memory. It is not that simple?
I do not have visibility into your implementation details. Inform me of the
constraints and provide functionality or information to deal with them.
Explain/define up-front on a screen, or in the installation instructions, the
behaviors which result in the minimum RAM being used during install. It is
only fair to leave out stuff that can be delayed until later with reasonable
ease and without consequence. For example, you have a great integration of md
and lvm. I expect that if it is possible at all that it would be much more
difficult to set up my mirrored partitions and logical volumes later.

A question I have after reading all of your comments above is whether minimum
memory requirements are achieved with minimum package installation or minimum
deviation from the default install! This could be a critical point. It would
only take a couple sentences to convey what is needed.

Regarding the "reduced memory" advise, does the text mode installer provide the
full/same functionality as the graphical? I should not have to take the time
to experiment. Please just tell me what the tradeoffs are so I can choose the
correct direction without trial and error. This is yes/no and perhaps a short
list of generalizations to tell me how it is different.

I don't know what a linuxrc parameter is. Can you tell me in a sentence or two
what to do rather than refering me to a generalized writeup on a Linux
subsystem? "When it says this, type any of the following separated by a
space". Addition of this single sentence would have made the wiki
"Installation with Little Memory" write up much more useful, useful for
anybody!

Or better yet, you could add a screen up front with buttons and text boxes to
toggle these things for the user. You don't want to have the installation
dominated by this memory stuff, but I am sure you could identify 2-3 key
options to present or communicate that would get the user 95% of the possible
benefit. I am guessing that these are parameters on the boot process... Yet
some look like parameters for YAST, and so could be set in the first screen.
Perhaps others could do a "reboot" to set them as the user specifies?

With regard to the specific linuxrc recommendations, what does adding swap do
for me in a practical sense (Yes, I understand the concept AND implementation
of paging in extreme detail, but I DON'T understand how this relates to YOUR
installation scripts!). Does this completely eliminate memory concerns? End
of problem, especially if I can swap on a flash drive (Although older PCs do
not have a USB interface). But will this wear out a flash drive in one
install? If an installation would result in more than a new hundred write
cycles perhaps this would be an appropriate warning. We are not dumb, we just
don't want to read the source for the installer to understand how to install!

Finally, I understand that the user's behavior affects the memory needed. But
you could present a small number of concrete examples at key points in the
continuum (NOTE TO an uninvolved reader: The statements below are NOT correct,
they are examples of the KIND of statements or options that might be
provided!!!!)

* Two memory requirements in each of the examples below are given with/without
logging enabled. A log enables Suse to debug problems should they occur. If
you disable logging and encounter problems, it will be impossible to help you.

* If you accept the xyz default and go with a single partition it will install
with xxx/yyy MB. You can then add and remove packages later using YAST.

* If you pick the "Minimum Package Set" button you will be able to install with
the minimum amount of RAM (currently 192/yyyMB). Adding additional packages
later using YAST will work identically to the installer and result in an
indistinguishable installation".

* Performing a complex partitioning scheme requires more memory during
installation. For example a system with 4 disks, 8 partitions on each,
mirroring and setting up LVM would require an incremental 64/yyyMB over a
simple single disk/single partition installation. This means for example that
you should expect to be able to do an install with 256/yyyMB of memory if you
select the minimal package set yet have a very complex partitioning scheme.

* Every menu action results in more memory being needed due to logging. Your
mileage will vary as your actions vary. (This gives the user a reference
point, and tells him how to minimize requirements.)

[ ] Check box to disable all logging to eliminate memory size dependence on
navigation and browsing during installation.

* "512MB should be sufficient for all installations, although excessive menu
navigation during package selection or partitioning could require more memory."

I also question if the default should be with logging enabled. Problems are
presumably rare, and of those cases it is probably rare to send the logs to
someone who can read them. Normally logging is disabled, and people are
instructed to enable it in case of problems. In this case, the very act of
logging appears to be causing the system to not be functional. This is not
good.

---
I personally am left with the question as to whether I can trust the result if
I put in 384MB and it seems to work, or 256MB and select less packages and it
seems to work. And I don't know if I should de-select packages to minimize the
number or just run with the default to minimize changes.

I wish I could make more concrete suggestions instead of beating around the
bush, but I don't know enough. I believe a few key additions to configure the
installer and a few simple statements of explanation would go a very long way
to enabling users to install Suse with the minimum of memory.

If you got this far, thank you for listening, and I hope this helps you to make
a better installer. If you can help me understand what to do in the short
term, that would be appreciated too. I know you are not tech support, perhaps
I can learn by listening to you through this thread.


--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

< Previous Next >