https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847154 > * 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 <b...@decadent.org.uk> Sat, 29 Oct 2016 02:05:32 +0100 > > $
GiaThnYgeia: > 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 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 > 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 > 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
