[gentoo-user] GRUB bootup ftom hibernation question
I was heading out earlier today, and ran "sudo /usr/sbin/hibernate". There was occasional thunder, and I did't want my UPS to run out if power got knocked out while I was away. Now for the LILO/GRUB differences on reboot... * LILO would automatically reboot to the kernel that it had been running at hibernation time. I wouldn't see the LILO menu at all. * GRUB, on the other hand, brings up the regular boot menu from hibernation, with default being the default. If the running kernel at hibernation is different enough from the kernel selected at bootup, I can imagine situations where "that does not end well". Is there any way to get GRUB to "remember" the previous kernel or menu selection it was running under, and automatically select it, when rebooting? Note that I'm using a manually edited grub.cfg. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Tue, 2021-07-27 at 21:58 +0100, Neil Bothwick wrote: > > I was thinking more along the lines of a USE flag, as suggested first by > Rich. Add a system-init flag to daemontools, defaulting to off, and have > the virtual depend on daemontools[system-init] and the problem goes away > with the only cost being the unnecessary requirement to rebuild > daemontools. > True, or it could be dropped from the virtual entirely by the same reasoning: no one is using daemontools on purpose in 2021 (the last release was in 2001). Thinking about it, we should probably just mask all of the DJB packages with a warning that "you are about to waste your time." The few remaining users could package.unmask them. I've been meaning to replace tinydns for a decade but the stupid servers just keep running effortlessly.
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Tue, 27 Jul 2021 16:32:04 -0400, Michael Orlitzky wrote: > > Instead of continually beating on portage on this list, which will > > achieve nothing more than a minor waste of electrons, you should be > > focussing on getting the ebuilds fixed so that portage is no longer > > given conflicting or incorrect information. > > In most cases this is good advice. The problem with djbdns/qmail is > that they are abandoned upstream, and kept alive in Gentoo only by a > patchwork of... well, patches. I was thinking more along the lines of a USE flag, as suggested first by Rich. Add a system-init flag to daemontools, defaulting to off, and have the virtual depend on daemontools[system-init] and the problem goes away with the only cost being the unnecessary requirement to rebuild daemontools. -- Neil Bothwick The word 'Windows' is a word out of an old dialect of the Apaches. It means: 'White man staring through glass-screen onto an hourglass...') pgpahRBbccqv9.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Tue, 2021-07-27 at 21:18 +0100, Neil Bothwick wrote: > > Instead of continually beating on portage on this list, which will > achieve nothing more than a minor waste of electrons, you should be > focussing on getting the ebuilds fixed so that portage is no longer given > conflicting or incorrect information. In most cases this is good advice. The problem with djbdns/qmail is that they are abandoned upstream, and kept alive in Gentoo only by a patchwork of... well, patches. It would not -- independently -- be too much work to fix either package to work without daemontools. But, since they are abandoned, there is nowhere to send the fixes. That would add yet another patch to both packages. Qmail is similar, but I know more about djbdns, so: for example, net-dns/djbdns already applies SEVENTEEN PATCHES. And many of them are quite large. When a new security issue is found and a new patch is created or an existing one changes, then all of a sudden we get conflicts. If we apply the new one first, then (say) patches two through five might apply cleanly, but patches six through eighteen will fail. Now we have to manually rebase thirteen patches? That just will not happen, which is why no one has fixed these two packages to work without daemontools yet. The cost of additional patching is too high. You should really just avoid both of them. This is an obscure problem because no one chooses either djbdns or qmail since 2005.
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
On Tue, 27 Jul 2021 20:02:07 +, Alan Mackenzie wrote: > I know I'm repeating myself, but I don't think an OS should ever delete > critical parts of itself unless explicitly requested by the user. > Perhaps not even then, but I wouldn't go that far. The fact that > portage does this means IMHO that something has gone wrong. Yes it has, but it is not portage. Portage is only doing what you have told it, remove superfluous packages. By including daemontools in @world you have told it, albeit unintentionally, that you want that init system, making openrc superfluous. What has gone wrong is that daemontools is considered an init system when you have not installed it as such, so the issue is with either the daemontools or the virtual. Since you like quotes, here's another - "computers do what you tell them to do, not what you ant them to do". This is a classic example of that, portage is simply demonstrating the principle of GIGO. Instead of continually beating on portage on this list, which will achieve nothing more than a minor waste of electrons, you should be focussing on getting the ebuilds fixed so that portage is no longer given conflicting or incorrect information. You shouldn't give computers conflicting instructions, looked what happened when they did that with the HAL 9000 :-/ -- Neil Bothwick "I heard Tasha Yar is the Enterprise's expert on Data entry." pgpJJPsxBKGry.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Hello, Rainer. On Tue, Jul 27, 2021 at 11:28:05 +0200, Dr Rainer Woitok wrote: > Alan, > On Monday, 2021-07-26 19:01:21 +, you wrote: > > ... > > The warning was not very explicit. An explicit warning would have said > > "--depclean is capable of removing critical system packages". As it > > happened I didn't ignore the warning. But some people might. > > You seem to see nothing wrong with an OS being one keypress away from > > destroying itself. I do. > You mentioned in an earlier post that you not only got this warning for > "openrc" but also for "nano". I remember that after my first Gentoo in- > stall ever, I explicitly emerged the packages "vim" (as an emergency > fallback) and -- more importantly -- "XEmacs" which were thus added to > "@world". Just as a matter of interest (I am an Emacs maintainer), are you still using XEmacs? > I then ran my very first "emerge --ask --depclean" and got that > warning about "nano". I do not remember the exact wording, but -- > honestly -- I was startled. Not very explicit? When "emerge" is > tell- ing me that removing "nano" might result in my system becoming > unusable? Or something to that effect? Being a Gentoo novice then, > I immediately replied "n", researched the webs, and then with a bit > more knowledge and conscience I rerun "emerge --ask --depclean" and > bravely typed "y". > You were startled, too, when reading that warning, so where exactly is > the problem? Had I wanted a third editor I'd have stuffed "nano" into > "@world", but I didn't. Since you want "openrc", you should. The problem is that the documentation doesn't warn about the potential loss of critical packages. Only runtime messages which could easily have scrolled off the screen. Heck, when I first ran --depclean, there were something like 220 packages to be removed. It would be very easy to have missed openrc. (Shameless plug) only my kernel patch which restores soft scroll enabled me to scroll back and see the warning. The other problem is that, as (I think) Scott Adams, the creator of Dilbert, has said, everybody is an idiot. Just not 24 hours a day. The very fact that --depclean can remove the active init system means it will catch somebody at a time when he is being an idiot. I know I'm repeating myself, but I don't think an OS should ever delete critical parts of itself unless explicitly requested by the user. Perhaps not even then, but I wouldn't go that far. The fact that portage does this means IMHO that something has gone wrong. Maybe portage is too complicated, and people aren't aware of the lack of safety catches. > And yes, some people tend to ignore warnings. In particular, if there > are just too many of them. Yes. I wonder just how many people really do read the "Waschzettel" which accompanies all pharmaceuticals in Germany? It takes some commitment and patience to do so, but might be very important. > I remember when back in the old days plenty of sources suggested to > put "alias rm='rm -i'" into one's profile. I always objected to > this, because you'd get so used to typing "y" to the plethora of > questions that you'd have an excellent chance to miss the one file > which would have been worth retaining. > So the most important rule when working with computers still is "Read > carefully, think carefully, then type carefully". More warnings, bigger > fonts or red colour simply don't cut it. Or are you skimming your "gcc" > compilation logs after doing your weekly Gentoo upgrade for every warn- > ing in order to then check the source code to see whether or not you > should do anything about it? I don't. OK. Respectfully, I think I disagree with you here. Who'd have thought it? Two Gentoo users disagreeing about something. ;-) > My two cents ... Much appreciated, thanks. > Sincerely, > Rainer -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: --depclean wants to remove openrc. Yikes!
Alan, On Monday, 2021-07-26 19:01:21 +, you wrote: > ... > The warning was not very explicit. An explicit warning would have said > "--depclean is capable of removing critical system packages". As it > happened I didn't ignore the warning. But some people might. > > You seem to see nothing wrong with an OS being one keypress away from > destroying itself. I do. You mentioned in an earlier post that you not only got this warning for "openrc" but also for "nano". I remember that after my first Gentoo in- stall ever, I explicitly emerged the packages "vim" (as an emergency fallback) and -- more importantly -- "XEmacs" which were thus added to "@world". I then ran my very first "emerge --ask --depclean" and got that warning about "nano". I do not remember the exact wording, but -- honestly -- I was startled. Not very explicit? When "emerge" is tell- ing me that removing "nano" might result in my system becoming unusable? Or something to that effect? Being a Gentoo novice then, I immediately replied "n", researched the webs, and then with a bit more knowledge and conscience I rerun "emerge --ask --depclean" and bravely typed "y". You were startled, too, when reading that warning, so where exactly is the problem? Had I wanted a third editor I'd have stuffed "nano" into "@world", but I didn't. Since you want "openrc", you should. And yes, some people tend to ignore warnings. In particular, if there are just too many of them. I remember when back in the old days plenty of sources suggested to put "alias rm='rm -i'" into one's profile. I always objected to this, because you'd get so used to typing "y" to the plethora of questions that you'd have an excellent chance to miss the one file which would have been worth retaining. So the most important rule when working with computers still is "Read carefully, think carefully, then type carefully". More warnings, bigger fonts or red colour simply don't cut it. Or are you skimming your "gcc" compilation logs after doing your weekly Gentoo upgrade for every warn- ing in order to then check the source code to see whether or not you should do anything about it? I don't. My two cents ... Sincerely, Rainer
