Re: [gentoo-user] Program shutting down - where is its status held?
On Friday, 5 April 2024 16:21:15 BST Michael Orlitzky wrote:
> Personally, I would try to figure out why boinc doesn't want to stop
> when you tell it to stop.
Actually, it does; all its daughter process do stop straight away. It's just
that it doesn't report completion when it should.
> But barring that, you could add pre- and post-stop hooks that will let you
> know that the daemon is stopping.
>
> For example, in /etc/conf.d/boinc, you could put
>
> stop_pre(){
> touch /run/stopping-boinc
> }
> stop_post(){
> rm -f /run/stopping-boinc
> }
>
> or something like that. (I haven't tested, but the idea is sound.)
> Then, if that file exists, boinc is stopping.
Outstanding! I'll try that. Thank you Michael.
As to the primary problem, I think the BOINC team aren't entirely in tune with
the Linux way of doing things - though I could be wrong, of course. They're
university boffins, after all... :)
--
Regards,
Peter.
[gentoo-user] Optimus GPU switching
Hello again fellow gentooers, I wanted to ask a pretty stupid question, what tool should I use for switching GPUs on my optimus laptop? I know bumblebee, but that isn't updated anymore. Thanks! -- May the Force be with you, Vít Smolík.
Re: [gentoo-user] Program shutting down - where is its status held?
On Fri, 2024-04-05 at 16:09 +0100, Peter Humphrey wrote:
> On Thursday, 4 April 2024 10:12:23 BST I wrote:
>
> > Some of my machines run BOINC, which I want to stop while doing my sync &
> > update. For some reason, '/etc/init.d/boinc stop' often takes exactly 60s to
> > complete instead of its normal 6-10s.
> >
> > I'd like my update script to detect this condition, but I can't see how.
> > I've tried grepping /bin/ps output, and I've tried checking for existence
> > of a BOINC pid file, but those both tell me that BOINC is "running" while
> > it's in the process of shutting down.
> >
> > Is there somewhere in /proc where this shutting-down status is held?
>
> Let me ask a different way: does start-stop-daemon keep the current,
> transient
> status of the daemon it's operating on anywhere other than in its own
> variables, and thus accessible for inspection?
>
>
Not really. All start-stop-daemon is doing is sending SIGTERM/SIGKILL
signals to the boinc process:
stop() {
local stop_timeout="SIGTERM/60/SIGTERM/30/SIGKILL/30"
env_check || return 1
ebegin "Stopping ${RC_SVCNAME}"
start-stop-daemon --stop --quiet --progress \
--retry ${stop_timeout} \
--pidfile "${BOINC_PIDFILE}"
eend $?
}
The "stop_timeout" thing says that a SIGTERM will be tried first, and
if that doesn't work, a second SIGTERM will be sent after 60s. If
*that* doesn't work, then finally a SIGKILL will be sent after an
additional 30s.
Personally, I would try to figure out why boinc doesn't want to stop
when you tell it to stop. But barring that, you could add pre- and
post-stop hooks that will let you know that the daemon is stopping.
For example, in /etc/conf.d/boinc, you could put
stop_pre(){
touch /run/stopping-boinc
}
stop_post(){
rm -f /run/stopping-boinc
}
or something like that. (I haven't tested, but the idea is sound.)
Then, if that file exists, boinc is stopping.
Re: [gentoo-user] Program shutting down - where is its status held?
On Thursday, 4 April 2024 10:12:23 BST I wrote: > Some of my machines run BOINC, which I want to stop while doing my sync & > update. For some reason, '/etc/init.d/boinc stop' often takes exactly 60s to > complete instead of its normal 6-10s. > > I'd like my update script to detect this condition, but I can't see how. > I've tried grepping /bin/ps output, and I've tried checking for existence > of a BOINC pid file, but those both tell me that BOINC is "running" while > it's in the process of shutting down. > > Is there somewhere in /proc where this shutting-down status is held? Let me ask a different way: does start-stop-daemon keep the current, transient status of the daemon it's operating on anywhere other than in its own variables, and thus accessible for inspection? I have tried reading the code, but I'm not familiar with the Linux way of organising programs, and it's far too long since I did anything even remotely similar. -- Regards, Peter.
Re: [gentoo-user] Resizing boot partition while dual-booting
Hello everyone, Thanks for your help! I managed to get the EFI partition to my liking by installing Windows first, but before starting the install, I created my EFI partition manually by running these commands: 1. diskpart 2. list disk 3. sel disk 0 4. create partition efi size=1000 5. format quick fs=fat32 label=System Then i continued as normal and Windows used my 1GB EFI partition. st 3. 4. 2024 v 18:22 odesílatel Waldo Lemmer napsal: > Hi Vit > > I presume you plan to have a single boot partition that will contain your > bootloader, kernel and initramfs. There are actually two kinds of boot > partitions that are commonly used together: > 1. The EFI system partition (ESP) contains Linux and Windows's > bootloaders. It's formatted as FAT. > 2. The extended boot (XBOOTLDR) partition contains kernels, initramfs's > and microcode. It's formatted as anything the bootloader supports (GRUB > supports FAT, ext4 and more). > > If you have a single boot partition, you're actually just combining the > above two. If you want to create more room, you can split it: > 1. Shrink your Linux partition to create space for the extended boot > partition. You can GParted from another system or bootable USB. > 2. Create and format the extended boot partition. > 3. Modify /etc/fstab so the ESP gets mounted at /efi and the XBOOTLDR gets > mounted at /boot. > 4. Mount these two partitions. > 5. If this is an existing install, move the kernel, initramfs and > microcode from /efi to /boot. Otherwise, install the bootloader and the > kernel. > 6. Re-configure your bootloader (e.g. `grub-mkconfig -o > /efi/grub/grub.cfg`). > > Now the large kernel and initramfs files don't take up space on the ESP > that's being shared with Windows. > > Alternatively, just resize the ESP. However, that breaks Windows's > bootloader since the starting point of the C:\ partition moved, so you need > to fix it from a Windows setup USB using bootrec. I can't help you with > that. > > Waldo > > On Wed, Apr 3, 2024 at 5:38 PM Vít Smolík wrote: > >> Do you store your initramfs on the 100mb partition? Or do you stire it >> somewhere else? >> >> May the Force be with you, >> Vít Smolík. >> >> Dne st 3. 4. 2024 17:35 uživatel Alexis Praga >> napsal: >> >>> Hi Vit, >>> >>> I have a dual boot with a 100Mb EFI partition. It works fine, except >>> there isn’t enough place for both old and new kernels for upgrading. So I >>> moved the old kernel from /boot into a safe directory before upgrading. >>> Maybe not the best strategy but I didn’t dare resize it. >>> >>> Alexis >>> >>> On Wednesday, April 3rd, 2024 at 17:10, Vít Smolík < >>> vit.smol...@gmail.com> wrote: >>> >>> Hello fellow Gentooers, >>> >>> I want to dual-boot Gentoo and M$ Windows on my computer, but windows >>> only created a 100MB EFI partition. Is it necessary to resize it so my boot >>> files will fit? If so - how to resize it so I don't mess up my Windows EFI >>> files? >>> >>> -- >>> May the Force be with you, >>> Vít Smolík. >>> >>> >>> >>> -- May the Force be with you, Vít Smolík.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On Friday, 5 April 2024 07:34:01 BST Paul Sopka wrote: > On 05.04.24 08:31, Paul Sopka wrote: > > On 05.04.24 00:55, Michael wrote: > >> Your toolchain is now correct. Can you show the output of: > >> > >> equery u media-libs/libjpeg-turbo > >> > >> and > >> > >> emerge --info media-libs/libjpeg-turbo > >> > >> However, it could be this is a bug, you can check here for reports: > >> > >> https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%2Flibjpeg-turb > >> o > >> > >> > >> If this is the only package you're getting a problem with, you can run: > >> > >> emerge --resume --skipfirst > >> > >> to complete your migration to profile 23.0, then try again to emerge > >> libjpeg- > >> turbo on its own. > > Also one or two weeks ago I successfully emerged with emptytree after > migrating to profile 23.0. OK, for some reason (packages which require 32bit binary compatibility, or you setting some specific USE flag for a package in portage) the media-libs/ libjpeg-turbo had been built also with abi_x86_32. Now it seems your USE flags and corresponding build time dependencies have changed. Can you get it to build with: ABI_X86="64 -32 -x32" emerge -1aDv media-libs/libjpeg-turbo Check what flags you have set for packages in your /etc/portage/package.use to make them consistent. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On 05.04.24 08:31, Paul Sopka wrote: On 05.04.24 00:55, Michael wrote: Your toolchain is now correct. Can you show the output of: equery u media-libs/libjpeg-turbo and emerge --info media-libs/libjpeg-turbo However, it could be this is a bug, you can check here for reports: https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%2Flibjpeg-turbo If this is the only package you're getting a problem with, you can run: emerge --resume --skipfirst to complete your migration to profile 23.0, then try again to emerge libjpeg- turbo on its own. Also one or two weeks ago I successfully emerged with emptytree after migrating to profile 23.0.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On 05.04.24 00:55, Michael wrote: Your toolchain is now correct. Can you show the output of: equery u media-libs/libjpeg-turbo and emerge --info media-libs/libjpeg-turbo However, it could be this is a bug, you can check here for reports: https://bugs.gentoo.org/buglist.cgi?quicksearch=media-libs%2Flibjpeg-turbo If this is the only package you're getting a problem with, you can run: emerge --resume --skipfirst to complete your migration to profile 23.0, then try again to emerge libjpeg- turbo on its own. Unfortunately I have this issue with many packages. I can confirm it with media-libs/libjpeg-turbo: * Found these USE flags for media-libs/libjpeg-turbo-3.0.2: U I + + abi_x86_32 : 32-bit (x86) libraries - - java : Add support for Java - - static-libs : Build static versions of dynamic libraries as well and dev-util/vulkan-headers as well as sci-libs/netcdf: * Found these USE flags for sci-libs/netcdf-4.9.2-r1: U I - - blosc : Allow using blosc compression via dev-libs/c-blosc + + bzip2 : Enable bzip2 compression support + - dap : Support for remote data access with the built-in OPeNDAP client - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally - - examples : Install examples, usually source code - - hdf : Build with HDF4 read capability(sci-libs/hdf, sci-libs/hdf5 and sys-libs/zlib required). + - hdf5 : Add support for the Hierarchical Data Format v5 - - mpi : Add MPI (Message Passing Interface) layer to the apps that support it - - szip : Use the szip compression library - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) + + zstd : Enable support for ZSTD compression My emerge --info media-libs/libjpeg-turbo: Portage 3.0.63 (python 3.11.8-final-0, default/linux/amd64/23.0, gcc-13, glibc-2.39-r2, 6.8.2-gentoo x86_64) = System Settings = System uname: Linux-6.8.2-gentoo-x86_64-13th_Gen_Intel-R-_Core-TM-_i5-13600KF-with-glibc2.39 KiB Mem: 32699852 total, 27956992 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Thu, 04 Apr 2024 18:19:20 + Head commit of repository gentoo: 45b6803c7d0c2f6e0bbb7247385e9a3095dc172b Timestamp of repository guru: Thu, 04 Apr 2024 17:48:38 + Head commit of repository guru: ae5669fdb3157526d19cdfab0661a2719f00170b Timestamp of repository steam-overlay: Thu, 04 Apr 2024 01:22:27 + Head commit of repository steam-overlay: aca6eb772e0d5474b6d44072998af0082f36d08a Timestamp of repository wayland-desktop: Thu, 04 Apr 2024 01:22:35 + Head commit of repository wayland-desktop: 559692d775352c785aecfec52d940f20f5c9b800 sh dash 0.5.12 ld GNU ld (Gentoo 2.42 p3) 2.42.0 app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.2_p26::gentoo dev-build/autoconf: 2.13-r8::gentoo, 2.72-r1::gentoo dev-build/automake: 1.16.5-r2::gentoo dev-build/cmake: 3.29.0::gentoo dev-build/libtool: 2.4.7-r4::gentoo dev-build/make: 4.4.1-r1::gentoo dev-build/meson: 1.4.0-r1::gentoo dev-java/java-config: 2.3.3-r1::gentoo dev-lang/perl: 5.38.2-r2::gentoo dev-lang/python: 3.11.8_p1::gentoo, 3.12.2_p1::gentoo dev-lang/rust-bin: 1.76.0::gentoo sys-apps/baselayout: 2.15::gentoo sys-apps/openrc: 0.53.1::gentoo sys-apps/sandbox: 2.38::gentoo sys-devel/binutils: 2.42-r1::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/clang: 17.0.6::gentoo, 18.1.2::gentoo sys-devel/gcc: 13.2.1_p20240210::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/lld: 17.0.6::gentoo sys-devel/llvm: 17.0.6::gentoo, 18.1.2::gentoo sys-kernel/linux-headers: 6.8-r1::gentoo (virtual/os-headers) sys-libs/glibc: 2.39-r2::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo.git priority: -1000 volatile: False guru location: /var/db/repos/guru sync-type: git sync-uri: https://github.com/gentoo-mirror/guru.git masters: gentoo volatile: False steam-overlay location: /var/db/repos/steam-overlay sync-type: git sync-uri: https://github.com/gentoo-mirror/steam-overlay.git masters: gentoo volatile: False wayland-desktop location: /var/db/repos/wayland-desktop sync-type: git sync-uri: https://github.com/gentoo-mirror/wayland-desktop.git masters: gentoo volatile: False crossdev location: /var/db/repos/crossdev masters: gentoo priority: 10 volatile: False Binary Repositories: gentoobinhost priority: 1 sync-uri:
