Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie
- Date: Mon, 10 Apr 2017 11:27:00 +0000
- From: GiaThnYgeia <GiaThnYgeia@xxxxxxxxxxxxxxx>
- Subject: Re: Old 32bit PC 650kRam less VidMem 1024x768 will not run on Stretch ok on Jessie
> * From Linux 4.8, several changes have been made in the kernel
> configuration to 'harden' the system, i.e. to mitigate security bugs.
> Some changes may cause legitimate applications to fail, and can be
> reverted by run-time configuration:
> - On 64-bit PCs (amd64), the old 'virtual syscall' interface is
> disabled. This breaks (e)glibc 2.13 and earlier. To re-enable it,
> set the kernel parameter: vsyscall=emulate
> - On most architectures, the /dev/mem device can no longer be used to
> access devices that also have a kernel driver. This breaks dosemu
> and some old user-space graphics drivers. To allow this, set the
> kernel parameter: iomem=relaxed
> - The kernel log is no longer readable by unprivileged users. To
> allow this, set the sysctl: kernel.dmesg_restrict=0
> > -- Ben Hutchings <ben@xxxxxxxxxxxxxxx> Sat, 29 Oct 2016 02:05:32 +0100
> 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
>> 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 relates 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
> 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
> problems 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