Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie
Felix Miata:
> GiaThnYgeia composed on 2017-04-09 15:16 (UTC):
>
>> Felix Miata composed:
>
>>> IOW, it is suggested that iomem=relaxed may need to be included on
>>> kernel cmdline for the old user-space xserver-xorg-video-savage driver
>>> to work with your gfxchip in Stretch.
>
>> Thank you for the help in answering the puzzle, but how is a
>> semi-i-literate person able to translate this into a command/procedure
>> that will achieve such a thing? IOW, I am clueless at this point of
>> what a kernel cmdline is. I suspect it is a parameter in some file that
>> builds up the kernel during boot ... but where is it and how do I add
>> this command/parameter in it?
>
> "kernel cmdline" is also known as "Kernel Command-Line". This is the
> group of parameters that are provided to the kernel and init system by
> the bootloader as a component of using its menu. See
> ‘GRUB_CMDLINE_LINUX’ and following on
> https://www.gnu.org/software/grub/manual/html_node/Simple-configuration.html
>
> for more detail as pertains to the bootloader Stretch normally installs.
Would this be IT?
sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet iomem=relaxed"
sudo update-grub
As there is no term iomem in any debian installation I searched on the
net to find where and how does it relate to the kcl nor are any explicit
instructions on the link you send me. I appreciate your help but
imagine how much help would that be to one having such a machine and
making the mistake to break the system to the almost stable Debian.
Advice? Do not ever change much in your system withour having a
functional live system you can boot and find instructions to help solve
your broken system! In this case we have a system with a 2.4Ghz Celeron
not being supported by Debian9 .... let us not beat around the bush
about it!
> The cmdline last applied can be view by 'cat /proc/cmdline'.
>
> Alternatively, the cmdline last applied before Xorg was started can be
> found by viewing the first several lines of Xorg.0.log.
>
> What goes onto the cmdline can be configured either by
>
> 1-reconfiguring the bootloader after a successful boot (usually via
> changes to /etc/default/grub, then having grub write a new
> /boot/grub/grub.cfg file with grub-mkconfig), or
>
> 2-while the bootloader is showing its menu after POST has completed, to
> make a change applicable to the boot about to be started only (usually
> by hitting the "e" key while the menu is onscreen".
>
> #2 is what I was suggesting you first try to see if iomem=relaxed can
> solve the problem you have using your ProSavage8 S3 Graphics gfxchip. If
> it works then you should apply method #1.
"If it works"
This is the key term here, unless you are an experienced
developer/programmer Debian or Linux is not for you! To the vast
majority of people using a) browser 60% b) wordprocessor/office 15% c)
multimedia software 20% d) some pluginnplay software 4% e) misc. 1%
linux is virtually useless/dangerous!
If 32bit systems are no longer supported it should be stated with bold
headlines. The fact that somewhere in the fine print there is an alert
that "some" hardware may cause the upgrade from 8 to 9 will break your
system, that actually takes "some knowledge" to interpret as such, is
unacceptable.
I understand that this is debian-testing but for the past month we are
under the impression this is stable any minute now after 2 years of testing.
My understanding from reading this about iomem=relaxed is that such
issues will not be addressed before it becomes stable. Also by adding
this parameter into the kernel you are being "relaxed" about many other
things which exclude you from the "hardening" experience of the upgraded
system. So by solving one bottleneck and getting a system to be
functional you may be under the illusion you are sharing the security
and stability issues with everyone else, which is now false. It is
false because simply your stretch is not what everyone else is running.
And I see that people with much more recent 64bit hardware have had
problem recently, like when linux4.8 went to 4.9.
I now understand better why people are so hesitant in sticking with
Debian 6 or 7 even if it will no longer be supported except major
security issues.
------------------------------------
Come to think about it, if there was a single package in a live system
or part of the installer that read your hardware in advance and told you
this and this piece of hardware which you have is not supported by this
Debian release you are about to install/upgrade. DO NOT UPGRADE or do
so on your own risk of locating firmware to make it run.
IOW block and prohibit someone like me from making a fatal mistake of
breaking an otherwise functional system. It sounds more honest. The
system has been tested in this database of hardware combinations and
works. Anything else is "experimental".
--
"The most violent element in society is ignorance" rEG
"Who died and made you the superuser?" Brooklinux
Reply to: