| View previous topic :: View next topic |
| Author |
Message |
Aiken
Apprentice
Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia
|
 Posted: Thu Feb 27, 2014 2:37 am Post subject: |
 |
|
| miket wrote: |
Binary packages still include all the installation-time testing. |
Does not matter, source or binary udev will install even without the kernel support it wants.
You can argue about building on a build server even if kernel features are missing and I won't argue. I have 2 build servers. For cases like this I would like to see a way to mark build servers vs live servers so 1 can build what it wants and the other can refuse to install if it does not have the support. Another way would be do the kernel check before the install then abort with a way of overriding the abort for a build machine.
One thing I object to is something like udev (source or binary) installing on a live system when the wanted/needed kernel features are missing which is what udev does. Not everyone is a professional admin. Not every one is going to remember if they do to the upgrade a few months after the news item.
_________________
Beware the grue. |
|
| Back to top |
|
 |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Thu Feb 27, 2014 10:45 am Post subject: |
|
|
There have been other ebuilds that refused to even build when certain things weren't in the kernel.
One has to wonder why it wouldn't be done with the new udev ebuild.
Pre-notification via news or even as a post install note is all well and good
BUT it should check for kernel options and if they are needed to work properly
the build should stop at that point if they aren't there and put out a message.
Anything else is just poor dev skills IMO.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Thu Feb 27, 2014 10:58 am Post subject: |
|
|
| Anon-E-moose wrote: | There have been other ebuilds that refused to even build when certain things weren't in the kernel.
One has to wonder why it wouldn't be done with the new udev ebuild.
Pre-notification via news or even as a post install note is all well and good
BUT it should check for kernel options and if they are needed to work properly
the build should stop at that point if they aren't there and put out a message.
Anything else is just poor dev skills IMO. |
Kernel modules and anything using /usr/src/linux for building should in fact be fatal. If you have seen something else be fatal, then those have been bugs where developer forgot to add ~ to CONFIG_CHECK="" that
implies it's an userspace utility that can be binary packaged to an secondary host.
Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 01, 2014 4:47 am Post subject: |
|
|
| I agree with Aiken; a pkg_pre_install (or w/e it's called) check would be a good idea. |
|
| Back to top |
|
|
geki
Advocate
Joined: 13 May 2004
Posts: 2387
Location: Germania
|
| Posted: Sat Mar 01, 2014 8:55 am Post subject: |
|
|
| ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. 
now, how do we do for the binary install? see libreoffice pkg_pretend (starting at line 260) is there any way to link to line 260?!
the only two things left are proper kernel config checking via eclass or whatever.
like check-reqs eclass where you can set an environment variable to skip the checking.
the other more problematic thing is to check any kernel for the required features.
what about kernels to be compiled? needs to be hooked into kernel eclass or kernel itself?!
looks like fun; like that gentoo option which is already there.
if I had some spare time to waste ...
_________________
hear hear |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sat Mar 01, 2014 3:31 pm Post subject: |
|
|
The first part of the code you link to does the opposite of what you intend to do, see this line which checks if it is _not_ a binary merge; that block thus only runs on non-binary merges. The other line checks if a particular package is present.
There is indeed nothing with a binary merge that prevents you from checking the kernel options from the host; given that pkg_pretend is run, as well as that the eclass functions are available to be used. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 01, 2014 5:41 pm Post subject: |
|
|
| geki wrote: | | ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. :o |
Ouch, that is embarrassing.
ISTR pkg_pretend is also run before compilation, which could be on the build-machine, not the runtime host. If not then go for it. |
|
| Back to top |
|
|
broken_chaos
Guru
Joined: 18 Jan 2006
Posts: 370
Location: Ontario, Canada
|
| Posted: Sat Mar 01, 2014 7:16 pm Post subject: |
|
|
The number of times that a udev upgrade has radically changed system config or config file locations is somewhat alarming. While upgrading core packages always carries some amount of risk, udev's had the potential to break a system during an upgrade roughly a half-dozen times over the past few years. And has actually broken a few of my systems on a couple occasions -- luckily I knew it had a substantial chance of happening, and I made sure I was physically present to fix it.
If only upstream and the ebuild would attempt to not rock the boat so much. Looks like I'll have to exclusively use eudev if I want any hope of consistent configuration and installed file locations, while not losing things like bluetooth entirely. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Mar 01, 2014 10:36 pm Post subject: |
|
|
| broken_chaos wrote: | | The number of times that a udev upgrade has radically changed system config or config file locations is somewhat alarming. |
That's very true. The recent 80-net-* rename doesn't seem to serve any functional purpose that I can see, apart from making upgrades trickier for people who don't use the "recommended" unpredictable and crap new scheme.
| Quote: | | While upgrading core packages always carries some amount of risk, udev's had the potential to break a system during an upgrade roughly a half-dozen times over the past few years. And has actually broken a few of my systems on a couple occasions -- luckily I knew it had a substantial chance of happening, and I made sure I was physically present to fix it. |
It's one thing to say you need to keep abreast of things in Gentoo; it's quite another to use that as justification for constant change in the name of "innovation". The latter looks more and more like an unstable, immature project/development-team who wouldn't know an ABI guarantee if it smacked them in the faces, let alone what "don't break your consumer" means. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Mar 02, 2014 12:12 am Post subject: |
|
|
| I wonder if those kernel needs came from the new "let's do network config" mantra from systemd... Something they might found useful in systemd (still wonder why they don't let it do the coffee instead of all those craps), looks like they are going to pollute udev too with useless thing. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 02, 2014 12:27 am Post subject: |
|
|
| broken_chaos wrote: | | The number of times that a udev upgrade has radically changed system config or config file locations is somewhat alarming. While upgrading core packages always carries some amount of risk, udev's had the potential to break a system during an upgrade roughly a half-dozen times over the past few years. And has actually broken a few of my systems on a couple occasions -- luckily I knew it had a substantial chance of happening, and I made sure I was physically present to fix it. |
The direct consumers of udev are the maintainers of the udev packages in the various distros; the breakage of user systems lies on how the maintainers approach the upgrade, here the maintainer is given two sane options for the default. One is to automatically do an appropriate upgrade the consumers to the new naming, the other is to keep the old naming in place. The way breakage can be introduced here is to do an inappropriate upgrade without fixing up the network tools to use the new interface name, leading to breakage. Many maintainers will pick a sane default, because they don't want to break the user's install; the only way for a potential breakage to directly affect the user is if the user uses udev straight from upstream or chooses to override the maintainer's default without considering what that override accomplishes.
Granted, the locations of the files is a bit harder for a maintainer to account for; as not changing them involves patching and sometimes less support, sometimes other packages expect things to be in specific places too. However, changing those locations rarely leads to breakage; it mostly does when they are moved between / <--> /usr on systems that have these on different partitions. (Note: I however haven't looked at the details of the news item for the last upgrade of this week; given that I still need to go through that, feel free to explain how it can break)
| broken_chaos wrote: | | If only upstream and the ebuild would attempt to not rock the boat so much. Looks like I'll have to exclusively use eudev if I want any hope of consistent configuration and installed file locations, while not losing things like bluetooth entirely. |
For upgrading users the ebuild had a file in place on your system, which you needed to explicitly remove to obtain the new naming; without preparation at all, I wasn't affected by the udev upgrade and had the old naming continue for a quite long while. Weeks to months later whilst updating my system further I decided to make the switch by removing the file after hearing about it so much; besides that, to make sure to follow new standards to prepare for the moment they would eventually drop the old naming... |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Mar 02, 2014 1:12 am Post subject: |
|
|
| TomWij wrote: | (Note: I however haven't looked at the details of the news item for the last upgrade of this week; given that I still need to go through that, feel free to explain how it can break)
|
Well, i'm not quiet sure i understand the note, but if i get it right, the file presence to block new naming scheme has change its path.
You can easy guess the breakage now : new udev, user use /etc/udev/whateverfilenameitwas to not let udev use new naming scheme, reboot : new naming scheme : system broken. If the system is a distant server : user is really in deep shit.
One could argue : blahblah user didn't read the news... But news for breakage aren't well output, for this kind of thing i still don't get why portage just not stop the emerge and output critical news to user emerging a package querying a "validate me to continue" kind of action. Glad the news exist ! This should cover most users from falling into it ; but you cannot expect a user reading a news telling him to do "that" to re-read another news because "that" doesn't work anymore, as "that" has been rename "this" for no reason ; anyone could expect "that" to not change every 2 days no ?
As of today, it's even worst for ewarn & their friends as they aren't output on screen anymore because --jobs>1
Note also i didn't know if i'm right or not as i have drop udev, but this is what i understand from the news (that indeed could had been clearer : the only clear part really is to suggest using the kernel param to block the new naming scheme). The So, to clarify, you can override the new .rules file or the .link file in /etc part is the worst as it seem to contradict what has been told just upper. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 02, 2014 1:39 am Post subject: |
|
|
| krinn wrote: | | TomWij wrote: | (Note: I however haven't looked at the details of the news item for the last upgrade of this week; given that I still need to go through that, feel free to explain how it can break)
|
Well, i'm not quiet sure i understand the note, but if i get it right, the file presence to block new naming scheme has change its path.
You can easy guess the breakage now : new udev, user use /etc/udev/whateverfilenameitwas to not let udev use new naming scheme, reboot : new naming scheme : system broken. If the system is a distant server : user is really in deep shit. |
And Gentoo doesn't move it ... I suppose? Imo it should move it to keep things like they were before. *eyes ssuominen*
| krinn wrote: | | One could argue : blahblah user didn't read the news... But news for breakage aren't well output, for this kind of thing i still don't get why portage just not stop the emerge and output critical news to user emerging a package querying a "validate me to continue" kind of action. |
The package manager specification doesn't document such action; which makes this not possible without first going through a set of polictics, as well awaiting EAPI 6 to be finished and implemented.
| krinn wrote: | Glad the news exist ! This should cover most users from falling into it ; but you cannot expect a user reading a news telling him to do "that" to re-read another news because "that" doesn't work anymore, as "that" has been rename "this" for no reason ; anyone could expect "that" to not change every 2 days no ?
As of today, it's even worst for ewarn & their friends as they aren't output on screen anymore because --jobs>1 |
Those are repeated after all emerges are done at the end of the ouptut; other than that, `elogv` can be used to read those again if needed.
| krinn wrote: | | Note also i didn't know if i'm right or not as i have drop udev, but this is what i understand from the news (that indeed could had been clearer : the only clear part really is to suggest using the kernel param to block the new naming scheme). The So, to clarify, you can override the new .rules file or the .link file in /etc part is the worst as it seem to contradict what has been told just upper. |
The news item has been revised as well as had quite some eyes on the gentoo-dev mailing list; it should be true, given user should be able to override things like that in a meta distribution that provides them choice. |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Sun Mar 02, 2014 2:08 am Post subject: |
|
|
| krinn wrote: | | You can easy guess the breakage now |
I think that's what they are aiming for. 
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Sun Mar 02, 2014 10:24 am Post subject: |
|
|
| geki wrote: | | ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. |
That example doesn't work in reallife, for eg. there is nothing udev is using from /usr/src/linux, so building udev shouldn't require the directory to even exist
The devmanual isn't always up-to-date or accurate, plus it even says "this is an unrealistic testcase..."
It was merely to demonstrate the use of pkg_pretend, not any kernel configure checking
For sure, that page could be improved with a reallife example, patches to devmanual are welcome |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 02, 2014 10:41 am Post subject: |
|
|
| ssuominen wrote: | | geki wrote: | | ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. |
That example doesn't work in reallife, for eg. there is nothing udev is using from /usr/src/linux, so building udev shouldn't require the directory to even exist
The devmanual isn't always up-to-date or accurate, plus it even says "this is an unrealistic testcase..."
It was merely to demonstrate the use of pkg_pretend, not any kernel configure checking
For sure, that page could be improved with a reallife example, patches to devmanual are welcome |
You can however check its presence with the various linux_config*_exists functions from linux-info.eclass; furthermore, it is or should also be possible to check /proc/config.gz as a fallback and thus be able to inform the user about it if it is present. Requirement is a different story; but even if you take that into consideration, then udev is a device manager for the Linux kernel thus it kind of requires it. Whether the configs are present is however configurable by the user, that's why we can check for their existence... |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Sun Mar 02, 2014 10:48 am Post subject: |
|
|
| TomWij wrote: | | ssuominen wrote: | | geki wrote: | | ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. |
That example doesn't work in reallife, for eg. there is nothing udev is using from /usr/src/linux, so building udev shouldn't require the directory to even exist
The devmanual isn't always up-to-date or accurate, plus it even says "this is an unrealistic testcase..."
It was merely to demonstrate the use of pkg_pretend, not any kernel configure checking
For sure, that page could be improved with a reallife example, patches to devmanual are welcome |
You can however check its presence with the various linux_config*_exists functions from linux-info.eclass; furthermore, it is or should also be possible to check /proc/config.gz as a fallback and thus be able to inform the user about it if it is present. Requirement is a different story; but even if you take that into consideration, then udev is a device manager for the Linux kernel thus it kind of requires it. Whether the configs are present is however configurable by the user, that's why we can check for their existence... |
There is no requirement for /proc/config* or /usr/src in udev since it's completely an userspace tool, adding such hard requirement would be wrong
I've sort of wished CONFIG_IKCONFIG_PROC=y would become the kernel default, or heck, even a forced feature that can't be disable, because otherwise there will be always someone disaling it (either by choice, or by accident using old .config)
There is even a /usr/src/linux/scripts/extract-ikconfig we could in theory package in a separate package and install from some ebuild, but even that doesn't work because /boot might not even be mounted
As in, there is no way to check kernel options from the install host, that wouldn't add unrequired dependency to udev (or any other userspace tool), which is why the linux-info.eclass was modified to support "~" as non-fatal check
I realize the topic here is "udev is doomed", but some people seem to act as if this behavior was somehow new for udev, to start requiring new kernel opts, as if it was somehow systemd related as I see some of the same people
from the 'anti-system' topics here -- but let me tell, IT IS NOT, udev has *always* been like this and breakaged if user hasn't followed the opts closely, in the past missing CONFIG_BLK_DEV_BSG=y, CONFIG_IDE=n, CONFIG_SYSFS_DEPRECATED_V2=n, and many others have breaked the boot in a similar fashion we are now seeing with eg. CONFIG_DEVTMPFS=n
This is where prebuilt distribution shipped kernels come into play, in binary distributions like Debian and Fedora, where the package maintainers act partly as admins. So, if people can't handle this aspect of maintaining the system,
maybe they shouldn't be using a meta-distribution, and pick a distribution instead. |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 02, 2014 10:59 am Post subject: |
|
|
| ssuominen wrote: | | TomWij wrote: | | ssuominen wrote: | | geki wrote: | | ssuominen wrote: | Unfortunately Gentoo's binpkgs don't have support for checking kernel opts from the host it's being installed on. Are you willing to donate a code that makes that possible? It's not that easy, involves quite
heavy coding to the package manager. |
looks not that difficult at first.
the manual has your case as the example. |
That example doesn't work in reallife, for eg. there is nothing udev is using from /usr/src/linux, so building udev shouldn't require the directory to even exist
The devmanual isn't always up-to-date or accurate, plus it even says "this is an unrealistic testcase..."
It was merely to demonstrate the use of pkg_pretend, not any kernel configure checking
For sure, that page could be improved with a reallife example, patches to devmanual are welcome |
You can however check its presence with the various linux_config*_exists functions from linux-info.eclass; furthermore, it is or should also be possible to check /proc/config.gz as a fallback and thus be able to inform the user about it if it is present. Requirement is a different story; but even if you take that into consideration, then udev is a device manager for the Linux kernel thus it kind of requires it. Whether the configs are present is however configurable by the user, that's why we can check for their existence... |
There is no requirement for /proc/config* or /usr/src in udev since it's completely an userspace tool, adding such hard requirement would be wrong |
An userspace tool that however requires configuration in there to be set in a particular way to properly function; that is a hard requirement, but as said it is a different story which doesn't necessarily mean a hard requirement in terms of a dependency or a fatal check on their presence.
| ssuominen wrote: | I've sort of wished CONFIG_IKCONFIG_PROC=y would become the kernel default, or heck, even a forced feature that can't be disable, because otherwise there will be always someone disaling it (either by choice, or by accident using old .config)
There is even a /usr/src/linux/scripts/extract-ikconfig we could in theory package in a separate package and install from some ebuild, but even that doesn't work because /boot might not even be mounted |
Exactly, whether or not it has been discussed; it is controversial.
| ssuominen wrote: | | As in, there is no way to check kernel options from the install host, |
Other packages seem to be able to do this just fine.
| ssuominen wrote: | | that wouldn't add unrequired dependency to udev (or any other userspace tool), which is why the linux-info.eclass was modified to support "~" as non-fatal check |
That misses the suggested point; we could have udev only do a fatal check when the configs are present and the option was found to be set different, giving a non-fatal warning otherwise.
The general case is that the .config file is available; so, you may very well check for it instead of having people announce udev's breakage. Not everyone has the time to read news before they do their next reboot; "I'll move my battery-less laptop around the house or to work when these updates are done; it's late now, suspend is broken so I'll just shutdown my computer to make it quiet; ...". That's not saying the news item is bad, it's actually quite good; however, the whole experience could be better (for the users that follow the supported /usr/src/linux approach or enable the fallback /proc/config.gz). |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Sun Mar 02, 2014 11:48 am Post subject: |
|
|
| TomWij wrote: |
| ssuominen wrote: | | As in, there is no way to check kernel options from the install host, |
Other packages seem to be able to do this just fine.
|
Right, just like udev does it, with non-fatal checks using CONFIG_CHECK="~foo" not CONFIG_CHECK="foo"
| TomWij wrote: |
| ssuominen wrote: | | that wouldn't add unrequired dependency to udev (or any other userspace tool), which is why the linux-info.eclass was modified to support "~" as non-fatal check |
That misses the suggested point; we could have udev only do a fatal check when the configs are present and the option was found to be set different, giving a non-fatal warning otherwise.
|
No, it doesn't. There is no way to match the running kernel (or the kernel that will be booted next) with /usr/src/linux/.config since it might be a old relic as the user might have brought in
prebuilt kernel together with prebuilt udev from the built host that has the correct opts |
|
| Back to top |
|
|
TomWij
Retired Dev
Joined: 04 Jul 2012
Posts: 1553
|
| Posted: Sun Mar 02, 2014 11:58 am Post subject: |
|
|
| We expect users to set /usr/src/linux to the directory they have built their running kernel from; similarly, installing x11-drivers/nvidia-drivers wouldn't work well if you are on a different kernel than the one from /usr/src/linux. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Sun Mar 02, 2014 12:04 pm Post subject: |
|
|
| TomWij wrote: | | We expect users to set /usr/src/linux to the directory they have built their running kernel from; similarly, installing x11-drivers/nvidia-drivers wouldn't work well if you are on a different kernel than the one from /usr/src/linux. |
You miss the point that udev is an userspace application, where as nvidia-drivers is a kernel module which during it's compile needs the kernel sources to be available, and configured in a certain way, where as userspace apps have no such requirement.
That's the whole difference between determining if CONFIG_CHECK="" should be set with ~ or, without it. |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sun Mar 02, 2014 12:23 pm Post subject: |
|
|
I'm surprise none of you see where it fail and then deduce a possible solve :
It fail because building udev needs some kernel config, and you cannot enforce them because the build host may not be the running host.
If you compare it to a similar case, it's just the same case as cross-compiling
And the solve "looks" easy :
Portage need a switch/option to specify if your host is a live host or a build helper host, like for cross-compilation case.
So you can make a :
USE="buildhost" emerge udev
And udev then doesn't even need to check the system if the kernel option exist but throw a message about what kernel options are need (a non stopper message of course).
USE="-buildhost" emerge udev
And udev then be allow to check and throw a stopper message until it is fix.
It is not different from checking current running kernel version match minimal kernel version to use, but it will even solve that, you might wish to build an udev with a kernel that isn't valid to make udev works, but that package might be just build for a system where its kernel is ready for it.
This problem is not limited to udev. The problem with choices is sometimes you cannot guess what choice the user has picked, just add an option to portage so user can hint about his choice (is it a live system or just a build host), and all devs could handle both case easy now they can see what choice is made. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sun Mar 02, 2014 12:30 pm Post subject: |
|
|
| ssuominen wrote: | | I've sort of wished CONFIG_IKCONFIG_PROC=y would become the kernel default, or heck, even a forced feature that can't be disable, because otherwise there will be always someone disaling it |
Please don't rely on this: For low ram systems, putting .config into the running kernel is a waste of ram which is good for nothing and even might simplify the job of attackers on hardened systems.
I do not see what is wrong with the current practice to spit a warning and expect the user to fix things if checks cannot be done reliably: If the user breaks the system he keeps the pieces; he should be sane enough to read and care about the warnings before booting after upgrading such a basic component as udev/initrc/systemd/glibc/gcc/kernel. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Mar 02, 2014 12:31 pm Post subject: |
|
|
krinn:
pkg_pre_inst still sounds better to me.
So does what mv said. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Sun Mar 02, 2014 12:38 pm Post subject: |
|
|
krinn,
| Code: | USE="-buildhost" emerge udev
And udev then be allow to check and throw a stopper message until it is fix. |
Err ... No. I know my kernel is setup wrong but I want to do my update before I build a new kernel version with the new options in it.
I build the kernel, reinstall my nvidia-drivers and reboot, even Xorg works.
What should USE="-buildhost" chek against?
/proc/config.gz ?
Thats from the running kernel and I don't have a /proc/config.gz anyway.
/usr/src/linux ?
That may not be the running kernel.
There is only so much Gentoo can do to protect users against themselves and none of the above is robust enough to be worth the effort.
Gentoo users need to know better.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
