View previous topic :: View next topic |
Author |
Message |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 6:26 am Post subject: [Solved] Safe to just abort an emerge operation? |
|
|
Hi,
I just started an emerge -e @world, and it will rebuild almost 1000 packets!
But I forgot to check that my machine is running in high power mode (don't know the correct term, but a setting in BIOS)
So my question, can I simply abort the emerge, reboot into BIOS and then restart? Or should one let emerge be once started?
Last edited by G3nt00 on Wed Apr 19, 2023 7:15 pm; edited 1 time in total |
|
Back to top |
|
 |
Juippisi Developer


Joined: 30 Sep 2005 Posts: 762 Location: /home
|
Posted: Sat Apr 15, 2023 6:37 am Post subject: |
|
|
Generally should be safe, but could be you've updated a library that then breaks its consumers, and/or you could've updated a kernel so remember to call the rest required to get it booted.
Check emerge's messages after hitting ctrl+c, and double-check what you managed to get installed before canceling. |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 6:53 am Post subject: |
|
|
Juippisi wrote: | Generally should be safe, but could be you've updated a library that then breaks its consumers, and/or you could've updated a kernel so remember to call the rest required to get it booted.
Check emerge's messages after hitting ctrl+c, and double-check what you managed to get installed before canceling. |
Hm. Agree, it feels a bit sketchy to abort, or reboot. It has already emerged 153 packets, so a lot to go through. What should I look for in the emerge messages? Apart from a bunch from "acct-group" & "acct-user", I had these messages
Code: |
* Messages for package net-libs/libpsl-0.21.2:
* "icu" and "idn" USE flags are enabled. Using "idn".
* Messages for package media-plugins/grilo-plugins-0.3.15:
* Ignoring USE=gnome-online-accounts USE does not contain flickr or lua
* Messages for package app-office/libreoffice-7.4.4.2:
* If you plan to use Base application you must enable USE base.
* Messages for package acct-group/plugdev-0-r1:
* Group plugdev already exists
* Messages for package sys-apps/baselayout-2.13-r1:
* After updating /etc/profile, please run
* env-update && . /etc/profile
* Please run env-update then log out and back in to
* update your path. |
If it would fail to boot, what should I do then? Boot a live-iso, chroot and then run emerge @world? Could be good to know before-hand as this is my main machine... |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 8:40 am Post subject: |
|
|
Anyone? Is there a recovery, or should I just start it up again and let it take it's time? Somehow this sounds like the best bet, right? |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 8:48 am Post subject: |
|
|
OUCH...
Tried restarting, but this is all... far from the ~1000 packets I'd say... help please, can this be saved?
Code: |
emerge -e @world
Calculating dependencies... done!
Dependency resolution took 2.21 s.
!!! The ebuild selected to satisfy "net-misc/networkmanager" has unmet requirements.
- net-misc/networkmanager-1.42.2::gentoo USE="bluetooth concheck gtk-doc introspection modemmanager nss policykit ppp systemd tools wext -audit -connection-sharing -debug -dhclient -dhcpcd (-elogind) -gnutls -iptables -iwd -libedit -lto -nftables -ofono -ovs -psl -resolvconf (-selinux) -syslog -teamd -test -vala -wifi" ABI_X86="(64) -32 (-x32)"
The following REQUIRED_USE flag constraints are unsatisfied:
wext? ( wifi )
The above constraints are a subset of the following complete expression:
bluetooth? ( modemmanager ) connection-sharing? ( any-of ( iptables nftables ) ) gtk-doc? ( introspection ) iwd? ( wifi ) vala? ( introspection ) wext? ( wifi ) exactly-one-of ( gnutls nss ) at-most-one-of ( elogind systemd ) at-most-one-of ( dhclient dhcpcd ) at-most-one-of ( syslog systemd )
(dependency required by "dev-qt/qtnetwork-5.15.8-r1::gentoo[networkmanager]" [ebuild])
(dependency required by "dev-qt/qtdeclarative-5.15.8-r2::gentoo" [ebuild])
(dependency required by "dev-qt/qtwayland-5.15.8-r3::gentoo" [ebuild])
(dependency required by "dev-qt/qtgui-5.15.8-r4::gentoo[wayland]" [ebuild])
(dependency required by "dev-qt/qtwidgets-5.15.8-r4::gentoo[gtk]" [ebuild])
(dependency required by "app-crypt/pinentry-1.2.1-r1::gentoo[qt5]" [ebuild])
(dependency required by "app-crypt/gnupg-2.2.41::gentoo" [ebuild])
(dependency required by "gnome-base/gnome-keyring-42.1-r1::gentoo" [ebuild])
(dependency required by "sys-auth/pambase-20220214::gentoo[gnome-keyring]" [ebuild])
(dependency required by "sys-libs/pam-1.5.2-r3::gentoo" [ebuild])
(dependency required by "sys-libs/libcap-2.66::gentoo[pam]" [ebuild])
(dependency required by "sys-apps/systemd-252.7::gentoo" [ebuild])
(dependency required by "app-crypt/p11-kit-0.24.1-r1::gentoo[systemd]" [ebuild])
(dependency required by "app-crypt/gcr-3.41.1-r2::gentoo" [ebuild]) |
Edit: Seems the above dependency was the cause for the list to be so short. After enabling USE="wifi" again, list seemed as before (992 packets)... Will let it be for now and hope for the best |
|
Back to top |
|
 |
Goverp Advocate


Joined: 07 Mar 2007 Posts: 2216
|
Posted: Sat Apr 15, 2023 10:16 am Post subject: |
|
|
Generally
Code: | emerge foo
while !done
emerge --resume
if error
emerge --resume --skip-first
end |
or
Code: | emerge --keep-going foo |
I prefer the former, with the while loop implemented in wetware (i.e. I stop and look at the output if there are problems).
If you're concerned that your system might break, take a decent backup. That's a general statement, not specific to emerge.
It's rare for breaking emerge to leave your system dead. You might get broken graphics UI or other complex environments, but the command line is almost always available. _________________ Greybeard |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 10:37 am Post subject: |
|
|
Goverp wrote: |
It's rare for breaking emerge to leave your system dead. You might get broken graphics UI or other complex environments, but the command line is almost always available. |
This is reassuring to hear, thanks. I do understand Gentoo is quite robust (I learnt before it is not considered a distro, so what is the correct term?).
I just restarted from the top, hopefully that'll do it too, but will keep these commands for when they may be needed next, thanks!  |
|
Back to top |
|
 |
Hu Administrator

Joined: 06 Mar 2007 Posts: 23185
|
Posted: Sat Apr 15, 2023 3:57 pm Post subject: |
|
|
My biggest concern with interrupting emerge would be if the interruption occurred while Portage was installing a package, leaving the package half-installed. I believe I once had a scenario where, through no fault of Portage, an install of glibc died halfway through. I don't recall now why, but it was clear to me that the cause was not something the Gentoo maintainers could have foreseen or guarded against, so I never reported it. Cleaning that up was somewhat involved, but I did manage to repair the system with half an hour of work and without resorting to restoring from a backup.
The crude way to guard against damage when interrupting is to watch the emerge messages and only abort when the package is compiling, not installing. A slightly more invasive way that would work well enough, and be a bit safer, would be to temporarily and deliberately break a program that the build will need, such as gcc, then wait for the build to fail when it next tries to use gcc. Portage will not use gcc during the sensitive installation phase, so you can expect that when the build breaks, it will do so at a safe stage. An easy way to do this would be to mount --bind /dev/null /usr/bin/gcc.
When restarting afterward, consider telling emerge to resume, so that you do not need to do again all the things it did before you interrupted it. |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sat Apr 15, 2023 6:47 pm Post subject: |
|
|
Hu wrote: | My biggest concern with interrupting emerge would be if the interruption occurred while Portage was installing a package, leaving the package half-installed. I believe I once had a scenario where, through no fault of Portage, an install of glibc died halfway through. I don't recall now why, but it was clear to me that the cause was not something the Gentoo maintainers could have foreseen or guarded against, so I never reported it. Cleaning that up was somewhat involved, but I did manage to repair the system with half an hour of work and without resorting to restoring from a backup.
The crude way to guard against damage when interrupting is to watch the emerge messages and only abort when the package is compiling, not installing. A slightly more invasive way that would work well enough, and be a bit safer, would be to temporarily and deliberately break a program that the build will need, such as gcc, then wait for the build to fail when it next tries to use gcc. Portage will not use gcc during the sensitive installation phase, so you can expect that when the build breaks, it will do so at a safe stage. An easy way to do this would be to mount --bind /dev/null /usr/bin/gcc.
When restarting afterward, consider telling emerge to resume, so that you do not need to do again all the things it did before you interrupted it. |
Broken glibc sounds bad... I hope mine will play nice, it has been compiling the whole day more or less, @869 of 992. I am expecting a very snappy system after all this... LibreOffice was ridiculously fast compared to what it is on my same hardware using Fedora, Debian/Ubuntu or what-not.
I will if I can help it not abort portage again, but things do happen, so never know. But good advice to do it during compiling, I think I did that actually  |
|
Back to top |
|
 |
Goverp Advocate


Joined: 07 Mar 2007 Posts: 2216
|
Posted: Sun Apr 16, 2023 7:52 am Post subject: |
|
|
I've noticed that sometimes portage appears not to notice the abort signal. That's when it's running several jobs; maybe one or more are at a stage where stopping would be bad (presumably during the install step). In presume it has noticed, it just hasn't reached a safe point to react.
You can issue a second abort and it will then stop, but I guess for exactly the reasons above, that's not a good idea! Instead, just wait until portage reaches the end of what it's currently doing, and then stops. _________________ Greybeard |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Sun Apr 16, 2023 8:05 am Post subject: |
|
|
Goverp wrote: | I've noticed that sometimes portage appears not to notice the abort signal. That's when it's running several jobs; maybe one or more are at a stage where stopping would be bad (presumably during the install step). In presume it has noticed, it just hasn't reached a safe point to react.
You can issue a second abort and it will then stop, but I guess for exactly the reasons above, that's not a good idea! Instead, just wait until portage reaches the end of what it's currently doing, and then stops. |
You are right of course. If aborting all it's threads should get a signal to abort. The sudden break is probably quite bad. |
|
Back to top |
|
 |
G3nt00 Guru

Joined: 09 Apr 2023 Posts: 337
|
Posted: Wed Apr 19, 2023 7:15 pm Post subject: |
|
|
I will mark this thread as Solved. Conclusion: It was a really bad idea to abort portage and it will not happen intentionally on my system again. |
|
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
|
|