| View previous topic :: View next topic |
| Author |
Message |
grot
n00b
Joined: 17 Dec 2014
Posts: 33
|
 Posted: Wed Dec 17, 2014 4:00 pm Post subject: |
 |
|
I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
| truekaiser wrote: | | saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
...
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.
|
To play Natural Selection 2 and Crusader Kings 2, the common "no-audio" fix is to override the ini and use the alsa driver entirely instead of pulse. In my experience, this "fix" does not interfere with any other steam games that I have tried, although I would say my experience with linux games is pretty limited. Ofc, I might be misinterpreting what the command does, I'm still pretty new to this stuff. The command to run is
| Code: | | SDL_AUDIODRIVER=alsa steam |
Although, it does seem to me that the group that benefits the most from systemd and family are gamers... which is kind of sad considering Red Hat is pushing it. |
|
| Back to top |
|
 |
arnvidr
l33t
Joined: 19 Aug 2004
Posts: 629
Location: Oslo, Norway
|
| Posted: Thu Dec 18, 2014 7:35 am Post subject: |
|
|
What does systemd do for games? And why is a fix needed to play games without pulseaudio? I have never encountered a problem, with steam or otherwise.
_________________
|
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Thu Dec 18, 2014 9:06 am Post subject: |
|
|
Nothing and pulseaudio isn't needed for games (yet...)
I have a number of steam games and all work without systemd. I do have pulse only due to per-app mixing and my lazyness to re-install OSS4 (really is quite good) but I am holding out due to Skype (hopefully the web-client that uses WebRCT so no plugins needed will be released soon )
I can't think of any benefit systemd could bring to gamers. Only a slight advantage to game producers bringing their servers to Linux as in they only have to target one init system for daemon management HOWEVER almost all online games already provide a Linux server binary and all the publishers do was go 'sod it, we will just provide the binary and let the distro's sort it'
Works for bf4, CSS, CSGO, UTx ...
Now considering the performance issue with systemd esp around the logging, why on earth would a gamer choose systemd? I even launch games directly from SLiM for increased performance and I am an openbox user so my WM is already light
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Dec 20, 2014 4:07 pm Post subject: |
|
|
| Naib wrote: | | I even launch games directly from SLiM for increased performance and I am an openbox user so my WM is already light |
That sounds cool; would be good to see a write-up. |
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Sat Dec 20, 2014 6:11 pm Post subject: |
|
|
| grot wrote: | I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
| truekaiser wrote: | | saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
...
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.
|
To play Natural Selection 2 and Crusader Kings 2, the common "no-audio" fix is to override the ini and use the alsa driver entirely instead of pulse. In my experience, this "fix" does not interfere with any other steam games that I have tried, although I would say my experience with linux games is pretty limited. Ofc, I might be misinterpreting what the command does, I'm still pretty new to this stuff. The command to run is
| Code: | | SDL_AUDIODRIVER=alsa steam |
Although, it does seem to me that the group that benefits the most from systemd and family are gamers... which is kind of sad considering Red Hat is pushing it. |
I use pulse only, not systemD. And yes i tried that, did not work for my games on steam so yes i am stuck using pulseaudio if i want audio in my games. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Sat Dec 20, 2014 6:57 pm Post subject: |
|
|
| truekaiser wrote: | | grot wrote: | I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
| truekaiser wrote: | | saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
...
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.
|
To play Natural Selection 2 and Crusader Kings 2, the common "no-audio" fix is to override the ini and use the alsa driver entirely instead of pulse. In my experience, this "fix" does not interfere with any other steam games that I have tried, although I would say my experience with linux games is pretty limited. Ofc, I might be misinterpreting what the command does, I'm still pretty new to this stuff. The command to run is
| Code: | | SDL_AUDIODRIVER=alsa steam |
Although, it does seem to me that the group that benefits the most from systemd and family are gamers... which is kind of sad considering Red Hat is pushing it. |
I use pulse only, not systemD. And yes i tried that, did not work for my games on steam so yes i am stuck using pulseaudio if i want audio in my games. |
I'm curious as to why your system specifically is required to use pulse... like I said, I don't have pulse installed at all, yet the sound in all of my steam games (roughly 20) works fine (without any SDL_AUDIODRIVER line either).
Have you tried removing pulse from your system completely? It wouldn't be the first time that pulse has been known to screw up sound that works otherwise and, circling back a couple pages when you declared that _I_ don't know what I'm talking about just because your system is broken, is part of the reason why I argue that shims are the WRONG approach because they WILL break. |
|
| Back to top |
|
|
lotuskip
n00b
Joined: 24 Aug 2014
Posts: 14
|
| Posted: Sun Dec 28, 2014 10:55 am Post subject: message passing as the fundamental operation of the OS |
|
|
Here is an interesting quote from way back (1999!):
| Linus Torvalds wrote: | | message passing as the fundamental operation of the OS is just an excercise in computer science masturbation. It may feel good, but you don't actually get anything DONE. |
I'm forced to conclude that Lennart and his cabal are wankers (from a purely technical point of view, no slander intended). |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Sun Dec 28, 2014 11:13 am Post subject: |
|
|
Well there is no need to be so crude on the topic
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
truekaiser
l33t
Joined: 05 Mar 2004
Posts: 804
|
| Posted: Sun Dec 28, 2014 8:21 pm Post subject: |
|
|
| saellaven wrote: | | truekaiser wrote: | | grot wrote: | I'd like to thank posters such as steveL, anon-e-moose, and depontius (sp?) among many others for their incredible research and posts on these issues. This is the only place where I've been able to find good, factual arguments against the use of systemd, and I do raise your points in other places online. There are enough valid concerns that right now I'm trying out a dbus-free system.
| truekaiser wrote: | | saellaven wrote: |
and yet, I use steam without pulse or systemd without any problems...
|
And i think i can dismiss you right here.
...
I on the other did state i have to use pulse(because i like sound in my games) even though i hate using it.
|
To play Natural Selection 2 and Crusader Kings 2, the common "no-audio" fix is to override the ini and use the alsa driver entirely instead of pulse. In my experience, this "fix" does not interfere with any other steam games that I have tried, although I would say my experience with linux games is pretty limited. Ofc, I might be misinterpreting what the command does, I'm still pretty new to this stuff. The command to run is
| Code: | | SDL_AUDIODRIVER=alsa steam |
Although, it does seem to me that the group that benefits the most from systemd and family are gamers... which is kind of sad considering Red Hat is pushing it. |
I use pulse only, not systemD. And yes i tried that, did not work for my games on steam so yes i am stuck using pulseaudio if i want audio in my games. |
I'm curious as to why your system specifically is required to use pulse... like I said, I don't have pulse installed at all, yet the sound in all of my steam games (roughly 20) works fine (without any SDL_AUDIODRIVER line either).
Have you tried removing pulse from your system completely? It wouldn't be the first time that pulse has been known to screw up sound that works otherwise and, circling back a couple pages when you declared that _I_ don't know what I'm talking about just because your system is broken, is part of the reason why I argue that shims are the WRONG approach because they WILL break. |
Working as i actually get sound. Working as it doesn't matter how badly, or at all( *looks at zsnes, higan, any source engine based game as on hand examples) they even BOTHER to follow alsa documentation and just try to exclusively grab the audio device that i still get sound from it an other programs at the same time. Which has happened to me on pure alsa no matter the dmix config.
tweaking is fine, it just has to be a one time thing. For what I play and what i do using a pure alsa config would result in me tweaking it every time I changed what i want to do at the time. do I want to play a game? tweak the user's .asound config so I get sound and HOPE the game followed alsa documentation and doesn't blindly grab the audio device which removes audio from other programs or segfaults(hexchat did that to me for example once) them. Do I want to play music while I practice and improve my pitiful writing skills? Change the .asound file again to what the music player likes.
Pure alsa has not 'just worked' for me since I had to replace my old workhorse soundblaster audigy 2, and that is because THAT card was one of the last on the market with hardware muxing.
Don't get me wrong, I don't like LP. I hate what he is doing and what he is trying to do. and init system should stay an init system and a slow message bus should not be put into the kernel to gain speed that it can gain by improving it's code. But lets not cut off our nose to spite our face here.
On the one hand people complain that the sound system is stuck in the 90's. Then on the other you rally against a program that, while bad in the past, has improved under different hands which brings it nearly on par with windows. Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset. |
|
| Back to top |
|
|
grot
n00b
Joined: 17 Dec 2014
Posts: 33
|
| Posted: Sun Dec 28, 2014 9:17 pm Post subject: |
|
|
| truekaiser wrote: | | Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset. |
Sorry, kaiser, but you're doing that weird thing that some people do which is to take valid criticisms as personal attacks; you're assuming we're holding a personal grudge since some people here feel consistently let down by what LP has produced.
I've never had a major issue with alsa or pulse. Although pulse will mute itself 10% of the time when I press play, and in some cases disabling pulse just works. But I don't want to get too deep into alsa config files just yet. Overall I think I'm happy with pulse... It's saving me work - I think...
From my amateur position, though, for whatever reason, pulse is simply not the complete package it set out to be, and to say an incomplete package will get you out of the 90s is folly. Besides that, who doesn't love the 90s? |
|
| Back to top |
|
|
grot
n00b
Joined: 17 Dec 2014
Posts: 33
|
| Posted: Sun Dec 28, 2014 9:22 pm Post subject: Re: message passing as the fundamental operation of the OS |
|
|
| lotuskip wrote: | Here is an interesting quote from way back (1999!):
| Linus Torvalds wrote: | | message passing as the fundamental operation of the OS is just an excercise in computer science masturbation. It may feel good, but you don't actually get anything DONE. |
I'm forced to conclude that Lennart and his cabal are wankers (from a purely technical point of view, no slander intended). |
Like the other guy said - crude. But I loved the quote. Slowly learning about this message bus stuff. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Dec 28, 2014 9:51 pm Post subject: |
|
|
| grot wrote: | | ..to say an incomplete package will get you out of the 90s is folly. Besides that, who doesn't love the 90s? |
LMAO. Brilliant! ;-)
Yup all the interesting stuff being rediscovered, and labelled innovation, was done back then, when it comes to IPC, realtime scheduling and threading. The one that makes me laugh the most is seeing people argue aio is no good, and then advocating the "Java approach" which effectively relies on aio, as well as its literature (Goetz) reiterating what was written up in the 90s (Butenhof, though you need Gallmeister too.)
Personally I find it much easier to read the clearer specifications, without all the "modern" hand-waving and advocacy.
Not knocking Goetz mind; it's very useful reinforcement material. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Mon Dec 29, 2014 2:20 am Post subject: |
|
|
| truekaiser wrote: |
Working as i actually get sound. Working as it doesn't matter how badly, or at all( *looks at zsnes, higan, any source engine based game as on hand examples) they even BOTHER to follow alsa documentation and just try to exclusively grab the audio device that i still get sound from it an other programs at the same time. Which has happened to me on pure alsa no matter the dmix config.
tweaking is fine, it just has to be a one time thing. For what I play and what i do using a pure alsa config would result in me tweaking it every time I changed what i want to do at the time. do I want to play a game? tweak the user's .asound config so I get sound and HOPE the game followed alsa documentation and doesn't blindly grab the audio device which removes audio from other programs or segfaults(hexchat did that to me for example once) them. Do I want to play music while I practice and improve my pitiful writing skills? Change the .asound file again to what the music player likes.
Pure alsa has not 'just worked' for me since I had to replace my old workhorse soundblaster audigy 2, and that is because THAT card was one of the last on the market with hardware muxing. |
I miss my old hardware based sound cards too...
and I'm not a big fan of ALSA, it definitely has its issues... for the last couple major kernel releases, I'm lacking stereo sound due to some changes in the hda_intel driver that I haven't had a chance to debug. One of these days, I want to get around to trying OSS4 (my biggest concern is just being dependent on another out of tree driver), as my experience with OSS was that it always just worked (again, might have been having hardware with real mixers then).
| Quote: |
Don't get me wrong, I don't like LP. I hate what he is doing and what he is trying to do. and init system should stay an init system and a slow message bus should not be put into the kernel to gain speed that it can gain by improving it's code. But lets not cut off our nose to spite our face here.
On the one hand people complain that the sound system is stuck in the 90's. Then on the other you rally against a program that, while bad in the past, has improved under different hands which brings it nearly on par with windows. Simply because of the person who started it, who then abandoned it when he saw something shiny. I think you need to look in the mirror to see who is keeping the linux audio system in the 90's mindset. |
Clearly I believe there are problems in the Linux sound stack... but I don't believe pulseaudio solves those problems, it just adds more complexity and broken thinking to them. That Lennart was involved in pulseaudio isn't a valid reason to not use pulseaudio, pulseaudio itself is why I don't want to use pulseaudio. Ditto for systemd. That Lennart was involved in both projects (and several others that I also don't use) is not an indictment of those projects, though I would argue that the many flaws of those projects ARE an indictment of the key person they all share, in that Lennart's ego is always in the way of him achieving quality work.
The proper solution, is to fix the broken design with a better design (and that may just be OSS4, I haven't played with it enough to say so)... not to create more shims and hackery on top of what is already there, or things just continue to become more precarious. I'm not against progress at all... but it has to be at least as stable and robust as what it is replacing, and pulseaudio, systemd, etc simply are not.
Finally, again since you refused to acknowledge it after insulting my personal integrity and knowledge, at this time steam games do NOT rely on pulseaudio or shims emulating it... that your system "needs" pulseaudio for sound to work is an issue with your system. You could apologize for being wrong and attacking me over your error, though I don't expect you to. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6065
Location: Removed by Neddy
|
| Posted: Mon Dec 29, 2014 7:32 am Post subject: |
|
|
There is no need to feign butthurt. Steam ships with libpulse so if you are using the steam runtime (which is advisable) and since steam also uses SDL it will by default use pulse.
You.can override that with SDL_AUDIODRIVER=alsa
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 29, 2014 12:19 pm Post subject: |
|
|
There is no need for language like that either; this isn't OTW. It's perfectly possible to demur from someone's statements without personalising the whole thing with off-colour nonsense like "feigning butthurt."
Clearly steam does not require pulse, but will work with it if it's running. Which seems reasonable, as does SDL defaulting to it given the current fedora-lite userland. |
|
| Back to top |
|
|
mrbassie
l33t
Joined: 31 May 2013
Posts: 821
Location: Go past the sign for cope, right at the sign for seethe. If you see the target you've missed it.
|
| Posted: Mon Dec 29, 2014 7:01 pm Post subject: |
|
|
Do you guys think SteamOS will wind up switching to systemd?
On the surface it would appear an obvious yes, given that it's debian based. On the other hand, I imagine Valve chose Debian rather than a different or descendant distro due to Debian's well earned reputation for stability. From what I've read systemd is nowhere near stable yet and considering they keep adding new fangled wheels-with-right-angles to it whenever they get bored (it no longer being a unicycle) I can't see how it will be for many years. |
|
| Back to top |
|
|
Navar
Guru
Joined: 20 Aug 2012
Posts: 355
Location: usa
|
| Posted: Sat Jan 03, 2015 3:55 am Post subject: |
|
|
| mrbassie wrote: | Do you guys think SteamOS will wind up switching to systemd?
On the surface it would appear an obvious yes, given that it's debian based. On the other hand, I imagine Valve chose Debian rather than a different or descendant distro due to Debian's well earned reputation for stability. |
Eh, people pick Debian, etc. as much of a use case of environment they're familiar with for years as much as anything else (and Gentoo is pretty much there too). That is in large part why Debian, RedHat, etc. ever became the major distros over time. They added (perceived) ease, they came with package managers (which didn't exist), etc. In the same vein, it's amazing Slackware is still going, but for partially the same reasons and kudos to them.
Anyway, if I had to wager, I'd say with a 90% prediction interval that the corporate folk of Valve picked Debian because they were: a) particularly familiar with it w.r.t. to Linux exposure, b) don't want to re-invent wheels and bike shed past their goal particularly w.r.t. costs. They will not care about systemd being running as their MCP since their end game is something else entirely, much like chrome OS (front side 'views' versus back end details). Even if it causes them issues, my understanding is they could always just default back to the prior init systems and freeze at Debian 7 'wheezy' or whatever it is that added the Borg vote. Worst case they might have to fix some broken script functionality if they attempt anything too exotic. |
|
| Back to top |
|
|
gwr
Apprentice
Joined: 19 Nov 2014
Posts: 194
|
| Posted: Wed Jan 07, 2015 3:17 pm Post subject: |
|
|
| saellaven wrote: |
I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.
|
I apologize for rewinding this thread a bit, but I'd really like some additional context around what WilliamH did in relation to saellaven's earlier post above. I have seen allusions to this elsewhere, and I have bits and pieces of ideas. I'd appreciate a technical explanation, if possible, but I understand that politics are tied up in this, too. I'm not looking to bash anyone, just curious about what I should know about it. |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Wed Jan 07, 2015 3:29 pm Post subject: |
|
|
| gwr wrote: | | saellaven wrote: |
I again reiterate my story that I didn't care one whit about systemd until WilliamH abused his power to intentionally cripple the systems of people NOT using systemd because of systemd's shortsighted and arrogant self-imposed technical limitations. Break your system all you want and I don't care, but break my system and I have a problem.
|
I apologize for rewinding this thread a bit, but I'd really like some additional context around what WilliamH did in relation to saellaven's earlier post above. I have seen allusions to this elsewhere, and I have bits and pieces of ideas. I'd appreciate a technical explanation, if possible, but I understand that politics are tied up in this, too. I'm not looking to bash anyone, just curious about what I should know about it. |
short, short version (you can dig through past threads for a more detailed version if you want)...
WilliamH is lead of OpenRC and is also on the systemd herd. Immediately upon being elected to the Council, he asked the Council to break booting with a separately mounted /usr in OpenRC (where it has always worked) unless people use an initramfs*, largely because systemd upstream decided that they no longer wanted to support a separate /usr. SteveL developed a patch set for OpenRC to ensure it could continue to boot a separate /usr no matter what and has supported those patches since. WilliamH was made aware of them, rejected them without explanation, and then went on to not only continue to push the Council to mandate the breakage of OpenRC, but also refused to disclose the information that the patches existed to his fellow Council members before ultimately having the vote forced. In rubber stamping his proposal, the Council, on their part, assumed good faith from one of their fellow Council members and, apparently, did no independent research or thought into the situation, including the fact that the initramfs "solution" makes systems more fragile, prone to breakage and has continued to cause problems for people attempting their solution ever since.
The patches still exist, are still supported by SteveL, myself and others, and yet WilliamH still continues to abuse his authority as lead of OpenRC in refusing to accept them. The only reasonable explanation is that WilliamH is intentionally holding OpenRC back out of
1) wanting to cripple it to favor systemd (since systemd is technologically inferior in this regard, he wants to bring others down to its level because its proponents are so vocal that it's the best thing ever)
2) pettiness because he doesn't like SteveL on a personal level (which is not a technical reason to reject the very simple patch)
or 3) simple incompetence.
* introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Wed Jan 07, 2015 5:05 pm Post subject: |
|
|
| saellaven wrote: |
* introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade |
Can you develop a little about it? Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs.
I did not follow various things before SystemD became such a hot topic, notably the separate `/usr' debacle _because_ of using an initramfs. (Booting from either ZFS on dm-crypt LUKS or LVM2 on top of dm-crypt LUKS require such a thing.)
Well then, I am talking about the project on my sig... because I do know that the officially supported tools (genkernel and dracut) are... massive with udev, bash, and part of coreutils/util-linux bundled. Quite the hammer from a lightweight tool solely depending on busybox/mdev (with extra package for additional functionality.)
(I won't be surprised when SystemD itself would be included...)
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1845
|
| Posted: Wed Jan 07, 2015 5:06 pm Post subject: |
|
|
| Interesting...thanks for the summary. I've sort of only half followed that /usr situation. I've never had a separate /usr partition, however I also don't use an initramfs and absolutely would never want to. I'd be in flames if I got burned by that one. Seriously screwed. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Jan 07, 2015 7:59 pm Post subject: |
|
|
| saellaven wrote: | | introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade |
| tclover wrote: | | Can you develop a little about it? |
Consider that you're using some disk tool in initramfs. Now that tool is upgraded on your main machine (ie the rootfs.) Your initramfs is using older software.
Now we hope that's not an issue, but sometimes it is, or might be. I'd rather not have to worry about it.
Similarly we were told on the list not to worry about building an initramfs since they're small, and quick to build. At the same time we were told that an "initramfs is the new root", so you can do all your recovery from there. Personally I'd rather not have to think about what to build in, but just use the rootfs, since I configure my kernel to start the rootfs without modules, when I install. (It's the first thing I have to do before I can really start emerging anything, and is a milestone in the install process, ime. I also build in my fixed ethernet so I don't have to worry about bring-up order for eth0.)
Obviously if you need module setup, or network etc, to start the rootfs in the first place then you need an initramfs. However this is no different to the situation before: you always needed an initrd if you had eg root on raid, encrypted or lvm (but not /usr, at least for lvm.)
The point is that if you didn't need an initrd before, you don't need an initramfs now either. Only that was obfuscated, or lied about if we're being accurate.
| Quote: | | Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs. |
Well I've always just done exactly the same with init=/bin/bash from grub and my rootfs.
But no-one's knocking anyone else's use-case here. We're just annoyed at inaccurate information being used to justify dropping support for ours.
| Quote: | | I did not follow various things before SystemD became such a hot topic, notably the separate `/usr' debacle _because_ of using an initramfs. (Booting from either ZFS on dm-crypt LUKS or LVM2 on top of dm-crypt LUKS require such a thing.) |
Exactly: you'd have needed an initrd in the days before all this came up. An initramfs is exactly the same thing, from the kernel's pov, just using a different underlying ramfs "technology". (Yes I'm aware it's always there: I just don't need it.)
Last edited by steveL on Wed Jan 07, 2015 8:05 pm; edited 1 time in total |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Wed Jan 07, 2015 8:04 pm Post subject: |
|
|
| tclover wrote: | | saellaven wrote: |
* introducing a higher likelihood for random package upgrades causing boot failure unless you rebuild your initramfs after every package upgrade |
Can you develop a little about it? Just asking because I do _not_ have any of those crippling issues using an initramfs, quite the opposite... after several breakages of my system for various reasons (mainly risky experiments), bringing back a functional system was only possible thanks to a minimal shell available in the initramfs.
I did not follow various things before SystemD became such a hot topic, notably the separate `/usr' debacle _because_ of using an initramfs. (Booting from either ZFS on dm-crypt LUKS or LVM2 on top of dm-crypt LUKS require such a thing.)
Well then, I am talking about the project on my sig... because I do know that the officially supported tools (genkernel and dracut) are... massive with udev, bash, and part of coreutils/util-linux bundled. Quite the hammer from a lightweight tool solely depending on busybox/mdev (with extra package for additional functionality.)
(I won't be surprised when SystemD itself would be included...) |
if a backwards incompatible change happens on disk after a key utility gets upgraded (say, LVM or ext4 or whatever, it does happen, though infrequently) but the initramfs doesn't get updated, you could find yourself with a foo-2.xx format on disk with a foo-1.xx utility in your initramfs that can't read the disk, leaving you with a system that cannot boot without major intervention. You may also find you have problems with out of kernel-tree modules and all kinds of other goodies.
Thus, you have to rebuild your initramfs after every update of ANYTHING in it just in case, or else you can find yourself with a non-working system even if everyone on the system itself is fine. Now, keep in mind that every time you do that, you're potentially booting with an untested initramfs that could break anyway, so you need to keep multiple initramfs and matching kernels around. Instead of making things more robust, it makes things far more fragile.
Me?
I avoid the initramfs completely, so my system is always booting with what is installed on the system currently. I also keep my current and last known working kernel around (as well as an initramfs kernel just in case WilliamH intentionally breaks OpenRC because he doesn't like a separate /usr or whatever), plus I keep a second minimal Gentoo installation handy so that I can boot to that as a repair tool if needed (it's more or less equivalent to something like sysrescuecd, where I have all of the tools I would need to fix my system in the event of catastrophic breakage installed).
By intentionally keeping the most fragile part of boot out of my boot process, my system is far more likely to boot than not. That said, if you require a bluetooth keyboard or something else (like your LUKS setup) that requires a fully functional system already running just to boot up, you're stuck with an initramfs. That said, the initramfs is completely unnecessary for boot with a separate /usr, it's just a problem because WilliamH solely decided to make it a problem and then decided to abuse his position on the Council to make it a distribution-wide problem unless you use SteveL's patches. |
|
| Back to top |
|
|
tclover
Guru
Joined: 10 Apr 2011
Posts: 516
|
| Posted: Wed Jan 07, 2015 9:59 pm Post subject: |
|
|
| steveL wrote: | Consider that you're using some disk tool in initramfs. Now that tool is upgraded on your main machine (ie the rootfs.) Your initramfs is using older software.
Now we hope that's not an issue, but sometimes it is, or might be. I'd rather not have to worry about it.
Similarly we were told on the list not to worry about building an initramfs since they're small, and quick to build. At the same time we were told that an "initramfs is the new root", so you can do all your recovery from there. Personally I'd rather not have to think about what to build in, but just use the rootfs, since I configure my kernel to start the rootfs without modules, when I install. (It's the first thing I have to do before I can really start emerging anything, and is a milestone in the install process, ime. I also build in my fixed ethernet so I don't have to worry about bring-up order for eth0.)
|
There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage. However, the worries you don't want to think of are no different to other sensible updates (such as OpenRC when a major update hit the tree that require care that can render a system unbootable.) Such updates are worrisome, and there is no way to avoid them. I guess trying to avoid useless hassles is a sane stance.
But, I've been using an initramfs since 2011... and I did not bump into that system update which require rebuilding the initramfs. I can only think of 3 reasons, actually a sole reason, (ZFS/LUKS/LVM2 use cases): _metadata/header/format_ change. However, those come rarely enough (compared to OpenRC major update for example) to not burden the use of an initramfs. With a good tool, it's like: kernel update... an additional command is executed to build an initramfs. Period. Easy as that.
So, I don't see the prejudice of using an initramfs as being an worrisome burden.
| steveL wrote: |
Well I've always just done exactly the same with init=/bin/bash from grub and my rootfs.
But no-one's knocking anyone else's use-case here. We're just annoyed at inaccurate information being used to justify dropping support for ours.
|
This is a little short sighted example... Let me put another easy breakage that shows the short comings of this.
I've just broken a hardware a few months ago, a hardware that did not survive half a dozen of kernel panics (my fault as usual.) And I did not have any other machine with Linux. I had to resend the hardware knowing I would never get is back again. What should have I done to get my data (LVM2 & ZFS on LUKS) without any other hardware around with Linux? Moreover, I was living in a new city shortly after moving, so I did not know anybody with a Nix OS. You know what? My initramfs saved my arse, well my data (again.) Booted (with a hardware having W7) from a pendrive with kernel+initramfs=minimal shell available, so I could copy my data to another disk.
Sorry to say this, but `init=/bin/bash' is just... no apropos of ths kind of issues. And, I did have a few hard ones... in the past.
I completely second on the last sentence. Moronic with that.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/ |
|
| Back to top |
|
|
saellaven
l33t
Joined: 23 Jul 2006
Posts: 654
|
| Posted: Thu Jan 08, 2015 12:36 am Post subject: |
|
|
| tclover wrote: |
There are valid reasons... but I don't see a _valid_ to reject an initramfs as de facto (inflexible like) stance. I do understand why those who did _not_ need an initramfs took such an opposition to such matter/sabotage. However, the worries you don't want to think of are no different to other sensible updates (such as OpenRC when a major update hit the tree that require care that can render a system unbootable.) Such updates are worrisome, and there is no way to avoid them. I guess trying to avoid useless hassles is a sane stance. |
For people that want or need an initramfs, more power to them... none of us oppose it in that case. We object to being forced to use one for political reasons (as the technical justifications were entirely phony)
| Quote: |
But, I've been using an initramfs since 2011... and I did not bump into that system update which require rebuilding the initramfs. I can only think of 3 reasons, actually a sole reason, (ZFS/LUKS/LVM2 use cases): _metadata/header/format_ change. However, those come rarely enough (compared to OpenRC major update for example) to not burden the use of an initramfs. With a good tool, it's like: kernel update... an additional command is executed to build an initramfs. Period. Easy as that. |
Since the mandate for an initramfs, people have had a near endless number of issues with systems that wouldn't boot because of it. It's either luck or diligence in rebuilding your initramfs that you didn't get bit, as I know for certain there was at least one upgrade in there about 3 years ago that broke backwards compatibility and caused grief (I want to say to lvm2 or e2fsprogs, but I don't remember for sure).
| Quote: |
This is a little short sighted example... Let me put another easy breakage that shows the short comings of this.
I've just broken a hardware a few months ago, a hardware that did not survive half a dozen of kernel panics (my fault as usual.) And I did not have any other machine with Linux. I had to resend the hardware knowing I would never get is back again. What should have I done to get my data (LVM2 & ZFS on LUKS) without any other hardware around with Linux? Moreover, I was living in a new city shortly after moving, so I did not know anybody with a Nix OS. You know what? My initramfs saved my arse, well my data (again.) Booted (with a hardware having W7) from a pendrive with kernel+initramfs=minimal shell available, so I could copy my data to another disk.
Sorry to say this, but `init=/bin/bash' is just... no apropos of ths kind of issues. And, I did have a few hard ones... in the past.
|
Hence why I have another system setup to repair things if something goes wrong. That system is updated about once a month when everything installed is in a known working condition. Worst case scenario for me, is that lilo (I never cared for grub) gets broken, in which case, I bust out an actual sysrescuecd disc (hasn't happened in about a decade or so).
But, at the end of the day, we're expected to know our system and our needs, tailoring them as needed. Things like mandating an initramfs stems precisely from the arrogance and ignorance that someone else knows what is best for everyone and tries to force it on us (ie, the 'one true way'). |
|
| 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
|
|
Kernel & Hardware
