Bug#410596: [Fwd: (process:number) INFO: kbd-mode: setting console mode to Unicode (UTF-8)]
Steve Langasek wrote:
On Sun, Feb 18, 2007 at 08:18:45PM +0100, Pablo Ripolles wrote:
I haven't looked at the low-memory mode menu in quite some time. Do you
have the option at this point to mount swap space? That's the only way
you're going to get enough virtual memory to be able to continue the
install
of etch;
when i boot using the option "priority=low" i have access to a reduced
menu. to have access to the augmented menu where the disk options are,
i need to execute first "Detect and mount CD-ROM" and second "Load
installer components from CD". in the former entry i have the option to
exclude a number of unnecessary modules from being loaded which i do.
Which modules have you loaded at this point?
as i said, i had tried all possibilities, i excluded all the unnecessary
modules. in fact, to "Detect and mount the CD-ROM" (stage in which d-i
allows to un/select all the unnecessary kernel modules) there are no
necessary modules, it doesn't need a module to detect and mount the CD
successfully. therefore i did tried the lightest possible configuration
too.
Probably a lot more of these
are "unnecessary" then you would think -- to minimize your memory
consumption (which is the point of having a low-memory mode after all), you
should select *only* those installer components that are needed to get you
to the next stage, i.e., mounting swap space.
the next stage (the one which extends the main menu options, i.e.
letting "Detect disks" and "Partition disks" appear) must be "Load
installer components from CD". i have no direct access to the mounting
swap space menu entries from the basic-reduced-initial main menu. i
need to "Load installer components from CD" first to gain access to
them! *that's the problem*.
So you definitely shouldn't be loading network drivers at this point, but
instead wait until swap is loaded for that.
yes, i know that! i've been trying to go as direct as possible to the
mounting swap space menu entries.
Then, once swap is activated,
you can go back to the list of installer components for a second pass.
well, the thing is that i cannot opt to select the main installer
components, that's the point! if i want to access the mounting swap
space menu entries, then, first of all, i need to "Load installer
components from CD", however d-i loads *all* main components at once!
and i think that's what eats all the memory up! not the kernel modules
(which i can actually avoid loading them, remember above).
after this second stage, i've gained access to the mounting swap space
menu entries and d-i is in the state of _minimum_ possible memory
configuration! now, when i execute the "Detect disks" menu entry, i get
the same error as reported in the subject of this thread.
there's certainly no way that the installer's memory requirements
on alpha are going to be lowered for etch.
i see it this way. it's true that 64MB of memory is nowadays very
little. i understand that every new version has got higher requirements
than previous ones (3.1 worked great!) . but:
-given the fact that it's said that 64MB is enough, then it should be
enough.
See above for the contortions that are implied by lowmem mode. It may still
be enough, if you're willing to work for it.
-given the fact that alpha is an almost extinguished architecture and
that it is (quite!) difficult to get working memory upgrades for those
machines, then the lower the memory requirements the better. i could
agree with your statement for the i386 architecture...
64MB is a small amount of memory for anything on i386 today; but alpha has
always required *more* memory than i386 to do the same task, because of the
larger pointer sizes contributing to larger object sizes and greater memory
usage. It is plainly unrealistic for the memory requirements for the
installer on alpha to ever be less than they are on i386.
i know this! i guess i didn't make my self clear. my point of view was
that *assuming* that we still want old alphas to work and to be used
with debian, then the restrictions we should accept for the basic
installation are the stronger ones i.e. the bottleneck, which in this
case are the ones imposed by the alphas (higher memory requirements for
the same task compared to i386).
And I'm the only developer actively working on the Debian installer for
alpha,
i didn't know that, and perhaps i wouldn't mind to contribute if you
would help me a bit... just to get started...
and lowmem mode isn't a use case of direct importance to me.
i understand that.
(My
alpha has 384MB of real memory; I can't imagine trying to do anything useful
with 64MB in an alpha running etch.)
well, that depends a lot on what you consider to be useful.
Even if I were inclined to put a lot
of effort into improving lowmem on alpha, it's unlikely that many of the
necessary changes would be suitable for inclusion in etch due to the
timeline.
is it that difficult? i mean, i think that it should be a question of
just providing direct access to the mounting swap space menu entries
from the basic-reduced-initial main menu. just before to "Load
installer components from CD" so that the memory is not yet consumed by
unnecessary installer components. i also think that was the original
intended installation flow.
To the extent that Debian helps make old, low-end hardware useful, I'm proud
of Debian and happy for our users; but I'm not going to strain my back
trying to turn back the hands of time.
i understand that though, specially if it is so hard... perhaps it is
not that hard (above considerations), perhaps it could be fixed for next
release (4.0r1).
-given the fact that the warning of the "low memory mode" advices the
administrator to allocate swap space as soon as possible, then doing it
so at the very first opportunity should be possible.
If you can't get to the point of activating swap space even with the further
hints above, please reply back and I'll see if we can't get this documented
in the alpha install manual for etch.
well, as you see it is impossible with 64MB and this d-i flow. however
i think it is a matter of design/order of events...
Thanks,
Thank you!
Reply to: