Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On Thursday, 4 April 2024 21:32:37 BST Paul Sopka wrote: > On 04.04.24 00:44, Michael wrote: > > No, this is not normal. I wonder if your make.conf settings are correct. > > Start with some safe CFLAGS as suggested here: > > > > https://wiki.gentoo.org/wiki/Safe_CFLAGS > > > > Then use the package 'app-portage/cpuid2cpuflags' to set the correct CPU > > flags: > > > > https://wiki.gentoo.org/wiki/CPU_FLAGS_* > > > > At this point you should be able to use gcc with no further problems. You > > can try to optimise your settings further by taking a look at suggestions > > here: > > > > https://wiki.gentoo.org/wiki/GCC_optimization > > A little correction, even though the "-march=" change removed the > warning gcc threw, it unfortunately didn't solve the issue. I just > recompiled dev-lang/nasm, and after that recompiled libjpeg-turbo, and I > have the same hang on "Detecting C compiler ABI info" again. 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. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On 04.04.24 00:44, Michael wrote: No, this is not normal. I wonder if your make.conf settings are correct. Start with some safe CFLAGS as suggested here: https://wiki.gentoo.org/wiki/Safe_CFLAGS Then use the package 'app-portage/cpuid2cpuflags' to set the correct CPU flags: https://wiki.gentoo.org/wiki/CPU_FLAGS_* At this point you should be able to use gcc with no further problems. You can try to optimise your settings further by taking a look at suggestions here: https://wiki.gentoo.org/wiki/GCC_optimization A little correction, even though the "-march=" change removed the warning gcc threw, it unfortunately didn't solve the issue. I just recompiled dev-lang/nasm, and after that recompiled libjpeg-turbo, and I have the same hang on "Detecting C compiler ABI info" again. Good night Nanderty
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On 04.04.24 00:44, Michael wrote: No, this is not normal. I wonder if your make.conf settings are correct. Start with some safe CFLAGS as suggested here: https://wiki.gentoo.org/wiki/Safe_CFLAGS Then use the package 'app-portage/cpuid2cpuflags' to set the correct CPU flags: https://wiki.gentoo.org/wiki/CPU_FLAGS_* At this point you should be able to use gcc with no further problems. You can try to optimise your settings further by taking a look at suggestions here: https://wiki.gentoo.org/wiki/GCC_optimization Thank you for pointing into the right direction. After changing -march=raptorlake to -march=alderlake on an i5-13600KS and running the following three times: In case you haven't done it yet, if you rebuild the toolchain things should hopefully self-correct on your system: emerge --sync emerge -1av sys-devel/binutils emerge -1av --nodeps sys-devel/gcc Use 'gcc-config -l' to check you are using the correct gcc version. emerge -1av sys-libs/glibc emerge -1av dev-build/libtool env-update && source /etc/profile I don't get the hang at "-- Detecting C compiler ABI info" anymore. It now hangs later on "-- Looking for a ASM_NASM compiler". My CPU_FLAGS_* are correct, I checked them with app-portage/cpuid2cpuflags to make sure they are up to date and they were. Do you have any idea for this? Thank you Nanderty
[gentoo-user] Problem when going to install refind and using musl/llvm profile
Hi all,
I'm attempting to set up a new machine. I want to try out the musl/llvm
combo, profile 70, but am having troubles with the refind boot manager.
When I attempt to emerge refind, I get, during the "pretend phase":
* ERROR: sys-boot/refind-0.14.0.2-r1::gentoo failed (pretend phase):
* objcopy (objcopy) does not support EFI target
and a bit further down:
* The specific snippet of code:
* LANG=C LC_ALL=C "${OBJCOPY}" --help | grep -q '\|| die "${OBJCOPY} (objcopy) does not support EFI target"
Has anyone gone down the road of musl/llvm/refind and seen this? I don't
see anything under bugs.gentoo.org.
Any thoughts on how to fix this would be appreciated,
Andrew
[gentoo-user] Program shutting down - where is its status held?
Hello list, 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? -- Regards, Peter.
Re: [gentoo-user] CONFIG_BLK_DEBUG_FS on kernel 6.8.1 considered a Bad Thing.
On Thu, 4 Apr 2024 at 09:07, Alan Mackenzie wrote: > > [*] Block layer debugging information in debugfs > > .. When I disabled this and rebuilt the kernel, my /boot mounted without > problem. > > -- > I have CONFIG_BLK_DEBUG_FS=y with no problems (6.8.2 downloaded directly from kernel.org) Jorge Almeida
[gentoo-user] CONFIG_BLK_DEBUG_FS on kernel 6.8.1 considered a Bad Thing.
Hello, Gentoo. A heads-up for kernel 6.8: I'm playing with kernel 6.8.1 (direct from Linux). When I first booted it, it failed to mount my /boot partition with this error message in dmesg: [5.645341] FAT-fs (nvme0n1p2): bogus number of reserved sectors [5.645345] FAT-fs (nvme0n1p2): Can't find a valid FAT filesystem .. On diffing the 6.7 and 6.8 .config files, I found a new pertinent item [*] Block layer debugging information in debugfs .. When I disabled this and rebuilt the kernel, my /boot mounted without problem. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Soft scrolling on framebuffer consoles - with GPM handling - version of the patch for kernel 6.8.1 onwards.
Hello, Peter.
On Mon, Mar 11, 2024 at 10:47:43 +, Peter Humphrey wrote:
> On Wednesday, 24 January 2024 12:20:29 GMT Alan Mackenzie wrote:
> > Hello, Gentoo.
> > On Wed, Jan 24, 2024 at 10:00:37 +, Alan Mackenzie wrote:
> > [ ]
> > Please note the corrected subject line. This version of the soft
> > scrolling patch is for kernel 6.6.13, or thereabouts.
> It works well here, Alan, up to kernel version 6.7.9, but one of the 15 or so
> new kernel parameters (since 6.7.8) seems to cause it to fail.
> I've attached the reject file, /usr/src/linux-6.8.0-gentoo/drivers/tty/vt/
> vt.c.rej.
Thanks!
I've had a look at this, now. The 6.6.13 patch appears to work on 6.7.x
(I tested it on 6.7.10 this morning).
For 6.8.1, a new patch is needed, see below. Remember, to apply it, you
need smething like:
$ patch -p1 < 6.8.1-GPS.20240402.diff
.. Have fun!
> --
> Regards,
> Peter.
diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
index 8967c3a0d916..f40ebbfb87de 100644
--- a/drivers/tty/vt/selection.c
+++ b/drivers/tty/vt/selection.c
@@ -217,7 +217,8 @@ static int vc_selection_store_chars(struct vc_data *vc,
bool unicode)
unless non-space at end of line. */
if (obp != bp) {
bp = obp;
- *bp++ = '\r';
+ if ((i + 2) < vc_sel.end) /* Don't add \r to
the last line. */
+ *bp++ = '\r';
}
obp = bp;
}
@@ -263,6 +264,11 @@ static int vc_do_selection(struct vc_data *vc, unsigned
short mode, int ps,
new_sel_start = rounddown(ps, vc->vc_size_row);
new_sel_end = rounddown(pe, vc->vc_size_row) +
vc->vc_size_row - 2;
+ while ((new_sel_end > pe)
+ && (is_space_on_vt (sel_pos (new_sel_end, unicode
+ new_sel_end -= 2;
+ if (!((new_sel_end) % vc->vc_size_row))
+ new_sel_end += 2;
break;
case TIOCL_SELPOINTER:
highlight_pointer(pe);
diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 38a765eadbe2..dd012e99e797 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -134,6 +134,11 @@ const struct consw *conswitchp;
#define DEFAULT_BELL_DURATION (HZ/8)
#define DEFAULT_CURSOR_BLINK_MS200
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+static unsigned int console_soft_scrollback_size =
+ 1024 * CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_SIZE;
+#endif
+
struct vc vc_cons [MAX_NR_CONSOLES];
EXPORT_SYMBOL(vc_cons);
@@ -289,8 +294,31 @@ static inline bool con_should_update(const struct vc_data
*vc)
static inline unsigned short *screenpos(const struct vc_data *vc, int offset,
bool viewed)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK
+ unsigned long softback_pos, scrolled_expanse;
+
+ if (vc->vc_softback_curr == vc->vc_origin) /* Should never happen! */
+ return (unsigned short *)(vc->vc_origin + offset);
+ else {
+ if (vc->vc_softback_in >= vc->vc_softback_curr)
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr;
+ else
+ scrolled_expanse = vc->vc_softback_in -
vc->vc_softback_curr
+ + vc->vc_softback_end - vc->vc_softback_buf;
+ if (offset >= scrolled_expanse)
+ return (unsigned short *)(vc->vc_origin
+ + (offset -
scrolled_expanse));
+ else {
+ softback_pos = vc->vc_softback_curr + offset;
+ if (softback_pos >= vc->vc_softback_end)
+ softback_pos -= vc->vc_softback_end
+ - vc->vc_softback_buf;
+ }
+ }
+ return (unsigned short *)softback_pos;
+#else
unsigned short *p;
-
+
if (!viewed)
p = (unsigned short *)(vc->vc_origin + offset);
else if (!vc->vc_sw->con_screen_pos)
@@ -298,6 +326,7 @@ static inline unsigned short *screenpos(const struct
vc_data *vc, int offset,
else
p = vc->vc_sw->con_screen_pos(vc, offset);
return p;
+#endif
}
/* Called from the keyboard irq path.. */
@@ -319,107 +348,111 @@ void schedule_console_callback(void)
* Code to manage unicode-based screen buffers
*/
-/*
- * Our screen buffer is preceded by an array of line pointers so that
- * scrolling only implies some pointer shuffling.
- */
+#define vc_uniscr_buf_end(vc) (vc->vc_uniscr_buf + vc->vc_uniscr_char_size)
-static u32 **vc_uniscr_alloc(unsigned int cols, unsigned int rows)
+static int vc_uniscr_alloc(struct vc_data *vc, unsigned int cols, unsigned int
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
On Thursday, 4 April 2024 05:55:20 BST Markus Gustafsson wrote: > Hi again, > > I tried to catch the error again and while doing so I realized you guys are of course correct: sddm usually starts on tty 2. I don't know why I got it into my head that it would start on tty 8. Anyway, when I finally got it to reproduce (took a few restarts) I didn't get a blinking cursor on tty 2, the monitor just goes to sleep (kind of like it does when it has no signal). Switching to tty 1 showed me the init log and let me log on so I could run the commands suggested earlier in this thread: > > $ ps aux | grep sddm > > root 2253 0.0 0.0 142408 14248 ?Ssl 06:26 0:00 > > /usr/bin/sddm root 2300 0.2 0.2 1653332 89588 ? Ssl 06:26 > > 0:00 /usr/bin/X -nolisten tcp -background none -seat seat0 vt2 -auth > > /run/sddm/xauth_UanezA -noreset -displayfd 16 root 2358 0.0 0.0 > > 61872 14024 ?S06:26 0:00 /usr/libexec/sddm-helper --socket > > /tmp/sddm-auth-49123ec6-075d-4982-860d-ea1de56059ca --id 2 --start > > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV --user sddm --greeter > > sddm 2359 0.0 0.4 1557540 135804 ? Sl 06:26 0:00 > > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV sddm 2365 0.0 > > 0.0 4320 1892 ?S06:26 0:00 dbus-launch --autolaunch > > d3bb17ba0dc5f70ad177e3f764fe168e --binary-syntax --close-stderr sddm > > 2366 0.0 0.0 4620 224 ?Ss 06:26 0:00 > > /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 > > --session All of the above looks healthy to me. > > $ rc-service sddm status > > * rc-service: service `sddm' does not exist > > This is what the command yields for a successful startup as well though. Should 'sddm' perhaps be 'display-manager' in the command above? Yes, the sddm DM is started by the 'display-manager' OpenRC service from the 'default' runlevel: ~ $ rc-update -s -v | grep display display-manager | default display-manager-setup | > Anyway: > > rc-status > > Runlevel: default > > > > sysklogd [ > > started ] dhcpcd > > [ started ] dbus > > [ started ] netmount > >[ started ] chronyd > > [ started ] cupsd > > [ started ] switcheroo-control > > [ started ] display-manager > >[ started ] numlock > > [ started ] local > > [ started > > ]> > > Dynamic Runlevel: hotplugged > > Dynamic Runlevel: needed/wanted > > > > display-manager-setup [ > > started ] avahi-daemon > > [ started ]> > > Dynamic Runlevel: manual > > This is also what it looks like for a successful startup. Yes, nothing wrong with the above. > And finally from /var/log/sddm.log: > > [06:26:03.740] (II) DAEMON: Initializing... > > [06:26:03.743] (II) DAEMON: Starting... > > [06:26:03.743] (II) DAEMON: Logind interface found > > [06:26:03.743] (II) DAEMON: Adding new display... > > [06:26:03.744] (II) DAEMON: Loaded empty theme configuration > > [06:26:03.744] (II) DAEMON: Xauthority path: "/run/sddm/xauth_UanezA" > > [06:26:03.744] (II) DAEMON: Using VT 2 > > [06:26:03.744] (II) DAEMON: Display server starting... > > [06:26:03.744] (II) DAEMON: Writing cookie to "/run/sddm/xauth_UanezA" > > [06:26:03.744] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background > > none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA -noreset -displayfd 16 > > [06:26:04.993] (II) DAEMON: Setting default cursor > > [06:26:05.010] (II) DAEMON: Running display setup script > > "/usr/share/sddm/scripts/Xsetup" [06:26:05.012] (II) DAEMON: Display > > server started. > > [06:26:05.012] (II) DAEMON: Socket server starting... > > [06:26:05.012] (II) DAEMON: Socket server started. > > [06:26:05.012] (II) DAEMON: Loaded empty theme configuration > > [06:26:05.012] (II) DAEMON: Greeter starting... > > [06:26:05.022] (II) HELPER: [PAM] Starting... > > [06:26:05.022] (II) HELPER: [PAM] Authenticating... > > [06:26:05.022] (II) HELPER: [PAM] returning. > > [06:26:05.142] (II) HELPER: Writing cookie to "/tmp/xauth_hBdSRs" > > [06:26:05.142] (II) HELPER: Starting X11 session: "" > > "/usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV" [06:26:05.152] (II) > > DAEMON: Greeter session started successfully > > [06:26:05.208] (II) DAEMON: Message
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Stefan. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 15:23:02 +, stefan1 wrote: > On 2024-04-01 15:12, Alan Mackenzie wrote: > > Hello, Gentoo. > > I'm trying to do > > # emerge -a @preserved-rebuild > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > > It shows me 5 packages to be merged, among them being > > [ebuild R] dev-lang/spidermonkey-78.15.0 [78.15.0] > > .. When I answer the "are you sure?" prompt with Yes, spidermonkey > > fails > > to build with this error message: > Emerging (1 of 5) dev-lang/spidermonkey-78.15.0::localrepo > > !!! Fetched file: firefox-78.15.0esr.source.tar.xz VERIFY FAILED! > > !!! Reason: Insufficient data for checksum verification > > !!! Got: > > !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 > > SHA512 WHIRLPOOL > > * Fetch failed for 'dev-lang/spidermonkey-78.15.0', Log file: > > * '/var/tmp/portage/dev-lang/spidermonkey-78.15.0/temp/build.log' > > It would appear that the sources are no longer available at Firefox, > > and > > I no longer have a copy in /usr/portage/distfiles. > > Why is portage trying to build this obsolete version? I surely will > > just > > unmerge it as soon as my system is back in order. > > Most importantly, how can I free up my system so that I can proceed > > with > > the pending profile update? I appear to be stuck. I hope I won't have > > to reinstall gentoo. > For old distfiles, NeddySeagoon hosts them publicly accessible. > This is the closest I found to your version: > https://bloodnoc.org/~roy/olde-distfiles/spidermonkey-78-patches-04.tar.xz Thanks! In the end I didn't need to download any files. > -- > Linux-gentoo-x86_64-Intel-R-_Core-TM-_i5-7400_CPU_@_3.00GHz > COMMON_FLAGS="-O3 -pipe -march=native -fno-stack-protector > -ftree-vectorize -ffast-math -funswitch-loops -fuse-linker-plugin -flto > -fdevirtualize-at-ltrans -fno-plt -fno-semantic-interposition > -falign-functions=64 -fgraphite-identity -floop-nest-optimize" > USE="-* git verify-sig rsync-verify man alsa X grub ssl ipv6 lto > libressl olde-gentoo asm native-symlinks threads jit jumbo-build minimal > strip system-man" > INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd > /usr/lib/modules-load.d /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus > /lib/udev /usr/share/icons /usr/share/applications > /usr/share/gtk-3.0/emoji" -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Arsen. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 17:48:18 +0200, Arsen Arsenović wrote: > Hi Alan, > Alan Mackenzie writes: > > Hello, Gentoo. > > I'm trying to do > > # emerge -a @preserved-rebuild > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > > It shows me 5 packages to be merged, among them being > > [ebuild R] dev-lang/spidermonkey-78.15.0 [78.15.0] > > .. When I answer the "are you sure?" prompt with Yes, spidermonkey fails > > to build with this error message: > Emerging (1 of 5) dev-lang/spidermonkey-78.15.0::localrepo > > !!! Fetched file: firefox-78.15.0esr.source.tar.xz VERIFY FAILED! > > !!! Reason: Insufficient data for checksum verification > > !!! Got: > > !!! Expected: BLAKE2B BLAKE2S MD5 RMD160 SHA1 SHA256 SHA3_256 SHA3_512 > > SHA512 WHIRLPOOL > > * Fetch failed for 'dev-lang/spidermonkey-78.15.0', Log file: > > * '/var/tmp/portage/dev-lang/spidermonkey-78.15.0/temp/build.log' > > It would appear that the sources are no longer available at Firefox, and > > I no longer have a copy in /usr/portage/distfiles. > > Why is portage trying to build this obsolete version? I surely will just > > unmerge it as soon as my system is back in order. > Because it currently is installed and depends on a preserved lib. I was confused about that. It didn't appear to be present and functional. > > Most importantly, how can I free up my system so that I can proceed with > > the pending profile update? I appear to be stuck. I hope I won't have > > to reinstall gentoo. > You can just go ahead with it. Odds are Spidermonkey will be updated, > or at least rebuilt, when you do that. I've got rid of it with energe --unmerge. My @preserved-rebuild now works again. So it's time to go for the 23.0 profile. Thanks! > -- > Arsen Arsenović -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Michael. Sorry it's taken me so long to reply. Just after I first posted, I updated myrsystem,2with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 16:38:57 +0100, Michael wrote: > On Monday, 1 April 2024 16:12:51 BST Alan Mackenzie wrote: > > Hello, Gentoo. > > > > I'm trying to do > > > > # emerge -a @preserved-rebuild > > > > .. For this purpose, I created a temporary repository, filling it with > > ancient ebuilds recovered from /var/db/pkg. > I may be missing something, but why are you doing this? My @preserved-rebuild had been broken for months. It needed sorting out before migrating to the new profile. > Why don't you run @world update first, which will bring your system to a > stable state, before you proceed with anything else, e.g. migrating to > profile > 23.0? @world updates didn't resolve the problem with @p-r. But Jack's suggestion has worked for me. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] My emerge @preserved-rebuild is wedged. Help, please!
Hello, Jack. Sorry it's taken me so long to reply. Just after I first posted, I updated my system, with which libssl-1.1.1w got unmerged. So my qmail stopped working. I've now reinstalled and configured it. On Mon, Apr 01, 2024 at 11:25:38 -0400, Jack wrote: >If you are just going to unmerge it anyway, why not do so before >emerging @preserved-rebuild? Possibly because it didn't occur to me that --unmerge would work on a package that wasn't properly installed. However, after unmerging it (and two ancient versions of php), @preserved-rebuild worked. :-). So I'm back in action. Thanks very much! -- Alan Mackenzie (Nuremberg, Germany).
