Re: [gentoo-user] Grub: for the love of almighty Zardoz the magniicent....
Got the motherboard running, the motherboard was IGNORING the "UEFI only" BIOS setting, it was attempting to boot my system in BIOS mode, I found that I had to efibootmgr and tell the stupid BIOS what is what... why the BIOS doesn't scan the first two directories under /EFI for *.efi and list them, then allow the user to select the default is byond me... I mean it would be much much too easy to do it that way. =\ The magic smoke had left my previous motherboard, literally a component was burned off the board, so couldn't put it back in service even if it could have been booted. The temporary build actually looks pretty nice. It has an absolutely absurd amount of RGB on it... hmm, I wonder how many of you good ppl have a similarly burned component that you haven't detected for some reason... If your build is more than ~2 years old, I suggest a close visual inspection of all components... The RGB on the ram does cause a serious heat issue when I have 4 sticks stacked up on the threadripper, but on this temporary build I'm only using two sticks and it looks very nice. -- The vaccine is a LIE. #TheHonklerIsReal Powers are not rights.
Re: [gentoo-user] arpwatch changed syntax?
>hi. > > >background: --- > >previously, i used to run it by this: > >> arpwatch -i enp7s0 -m cave...@domain.com -s /usr/sbin/sendmail > >but now, after some update, apparently this doesn't work any more. > >what seems to have changed is: > >* "-m" is replaced by "-w" or "-W". * "-s" doesn't specify sendmail >path, but is rather only a flag to suppress "reports sent by email". > >if i update the command into: > >> arpwatch -i enp7s0 -w cave...@domain.com No answers to your questions below, but you could try PATH=/usr/sbin:$PATH arpwatch -i enp7s0 -w cave...@domain.com and see if that solves your problem. DaveF > >then, it runs normally, but, it fails to send emails, with this error: > >> execl: sendmail: No such file or directory > >`whereis sendmail`: > >> sendmail: /usr/sbin/sendmail /usr/lib/sendmail /usr/lib64/sendmail >/usr/share/man/man1/sendmail.1.bz2 > > >questions: -- > >Q1: what happened that caused this syntax change? e.g. is it an update >from upstream? or is it a totally new app written by other devs? or am i >hallucinating (pretty sure it used to work tho)? > >Q2: is there any better tool to monitor arps and to email me when >interesting things happen? > >thanks a lot for your time. > >rgrds, cm. > >
[gentoo-user] arpwatch changed syntax?
hi. background: --- previously, i used to run it by this: > arpwatch -i enp7s0 -m cave...@domain.com -s /usr/sbin/sendmail but now, after some update, apparently this doesn't work any more. what seems to have changed is: * "-m" is replaced by "-w" or "-W". * "-s" doesn't specify sendmail path, but is rather only a flag to suppress "reports sent by email". if i update the command into: > arpwatch -i enp7s0 -w cave...@domain.com then, it runs normally, but, it fails to send emails, with this error: > execl: sendmail: No such file or directory `whereis sendmail`: > sendmail: /usr/sbin/sendmail /usr/lib/sendmail /usr/lib64/sendmail /usr/share/man/man1/sendmail.1.bz2 questions: -- Q1: what happened that caused this syntax change? e.g. is it an update from upstream? or is it a totally new app written by other devs? or am i hallucinating (pretty sure it used to work tho)? Q2: is there any better tool to monitor arps and to email me when interesting things happen? thanks a lot for your time. rgrds, cm.
[gentoo-user] snd broken?
After upgrading my pi64, I get this: aplay: device_list:274: no soundcards found... This page implies that the kernel needs to be patched: https://bbs.archlinux.org/viewtopic.php?id=254406 Can anyone confirm this, and will I be able to upgrade to something standard soon?
Re: [gentoo-user] Gentoo chroot with old glibc
Am Mittwoch, 1. Juli 2020, 03:30:59 CEST schrieb Thomas Mueller: > > > That's what I did: I found a 2017 stage3 with a still older glibc and > > > managed to upgrade to a 2020 gentoo while masking the last glibc > > > versions. That was tricky because I had to git-checkout intermediate > > > versions of the portage tree in order to deal with the EAPI changes but > > > I have a working chroot now. Thanks. > > > > That's the easy way to do it, yes. > > > > The hard way is to treat this as a cross-compilation problem and bootstrap > > your own stages from scratch. Instructions would be a bit longer... > > > > Andreas K. Hüttel > > I have looked through crossdev. Is that what it would take to cross-compile > and bootstrap stages from scratch? > > Could that be done from (instead of an old glibc) musl, uClibc, or FreeBSD > or NetBSD? It could be done from anywhere to anywhere in principle. (Like, building an old-glibc x86 stage on an arm64 machine...) This is how I bootstrapped the first riscv stages. (Yes I know we need newer ones...) But I don't claim it was a straightforward process. Took some time. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Upgrade to rsync-3.2.0-r1 results in "didn't get server startup line"
Hi Steve,
On 2020-06-30 20:35, Steve Freeman wrote:
> I have a local gentoo repo mirror that has been running well for
> years. It is essentially the same setup as described at
> https://wiki.gentoo.org/wiki/Local_Mirror except that it runs on a
> non-default port.
I sadly cannot reproduce this on my systems with a similar setup. Could
you attach the full rsyncd.conf file? Perhaps there's also custom
settings in /etc/conf.d/rsyncd.
> rsync: didn't get server startup line
> [Receiver] _exit_cleanup(code=5, file=main.c, line=1777): entered
> rsync error: error starting client-server protocol (code 5) at main.c(1777)
> [Receiver=3.2.0]
> [Receiver] _exit_cleanup(code=5, file=main.c, line=1777): about to call
> exit(5)
I've had a look in the code, and that particular message is only
triggered in one place:
if (!read_line_old(f_in, line, sizeof line, 0)) {
rprintf(FERROR, "rsync: didn't get server startup line\n");
return -1;
}
read_line_old is described thusly:
/* Read a line of up to bufsiz-1 characters into buf. Strips
* the (required) trailing newline and all carriage returns.
* Returns 1 for success; 0 for I/O error or truncation. */
int read_line_old(int fd, char *buf, size_t bufsiz, int eof_ok)
> Running rsync as a non-daemon appears to work fine regardless of
> server/client versions; it's only rsyncd that fails.
>
> With no useful logs or output, I'm finding this impossible to
> diagnose. Does anyone have any ideas?
I have no concrete ideas, but given that read_line_old seems to fail,
maybe it's helpful checking out actual network traffic with wireshark or
tcpdump. You could compare traffic between the working and the broken
version. A simple capture filter of 'port 5873' should be enough.
Since there really doesn't seem to be any better debug functionality
(there's --debug, but it didn't really add anything for me), perhaps you
could also build rsync with debug symbols and throw gdb at it.
Finally, have you tried accessing the rsync endpoint manually without
invoking 'emerge --sync'? Does the following also raise an error?
rsync --port 5873 10.10.10.10::
If not, perhaps try syncing a single file manually.
I also see that version 3.2.1 is in the tree now, could be worth a shot
too.
--
Wolf
Re: [gentoo-user] Grub: for the love of almighty Zardoz the magniicent....
On Wednesday, 1 July 2020 09:15:10 BST Neil Bothwick wrote: > On Wed, 1 Jul 2020 01:40:54 + (UTC), Alan Grimes wrote: > > I RMA'd my normal mobo as previously discussed. > > I went to grab my previous motherboard and it turns out that it had > > actually released a goodly chunk of it's Magic Smoke (tm) while I > > hadn't been looking. So I went down to the Quickie Mart and grabbed a > > motherboard that was still compatible with the rusty old 1800x... The > > error was Unable to load "/grub/i386-pc/normal.mod" Some short explanation of what Live image you're trying to boot with and at least your partitioning scheme might help. The GRUB error is indicative of GRUB not finding the partition in which the normal.mod module is stored. > > I had to buy some > > more USB sticks (my optical drive seems functional but will not boot > > the machine...) Why not? There should be no difference between a LiveCD and a LiveUSB. If anything booting off a USB on some MoBos could be more troublesome. Have you looked into this problem to find out if there was some MoBo setting you had to change (physical jumper/switch/cable, or firmware)? > > and used gparted to get into the partition, . > > =((( All my .mod files were in x86_64-efi > > > > >>> AND IT WAS WORKING ON THE OTHER MOTHERBOARD!!! <<< > > > > =~ > > Dear beloved Zardoz, what have I done to deserve your wrath??? > > Is the replacement motherboard UEFI and is t set that way in the firmware > menus? > > I think Zardoz would ask why you are subjecting yourself to GRUB when you > have much simpler options with UEFI hardware. Assuming this is a UEFI MoBo you can boot any kernel images on disk directly, as long as you can point the UEFI firmware to them. Have a look here: https://wiki.gentoo.org/wiki/EFI_stub_kernel and perhaps here: https://wiki.gentoo.org/wiki/Efibootmgr signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] old kernel on Gentoo
Gerrit: > On Sun, 21 Jun 2020 10:31:08 + > Raffaele BELARDI wrote: > > > What about the rest of the system, in particular GCC and the C > > libraries? Do you manage to build the 3.x kernel with up to date > > system or do you need to ''freeze'' some packages? > > 3.2 required an older gcc for me. I think 5.x and 6.x worked fine (if > memory serves me well). As gcc comes slotted, it is not too hard to > have them all installed in parallel. For the compilers, perhaps theese can help: https://archives.gentoo.org/gentoo-user/message/46d881b86ea66bf9b537374f4451d31c https://archives.gentoo.org/gentoo-user/message/da77b9598e34e7be3b76c74027b40efe Regards, /Karl Hammar
Re: [gentoo-user] Grub: for the love of almighty Zardoz the magniicent....
On Wed, 1 Jul 2020 01:40:54 + (UTC), Alan Grimes wrote: > I RMA'd my normal mobo as previously discussed. > I went to grab my previous motherboard and it turns out that it had > actually released a goodly chunk of it's Magic Smoke (tm) while I > hadn't been looking. So I went down to the Quickie Mart and grabbed a > motherboard that was still compatible with the rusty old 1800x... The > error was Unable to load "/grub/i386-pc/normal.mod" I had to buy some > more USB sticks (my optical drive seems functional but will not boot > the machine...) and used gparted to get into the partition, . > =((( All my .mod files were in x86_64-efi > >>> AND IT WAS WORKING ON THE OTHER MOTHERBOARD!!! <<< > =~ > Dear beloved Zardoz, what have I done to deserve your wrath??? Is the replacement motherboard UEFI and is t set that way in the firmware menus? I think Zardoz would ask why you are subjecting yourself to GRUB when you have much simpler options with UEFI hardware. -- Neil Bothwick I backed up my hard drive and ran into a bus. pgpNG2Rel4K3M.pgp Description: OpenPGP digital signature
Re: [gentoo-user] old kernel on Gentoo
On Sun, 21 Jun 2020 10:31:08 + Raffaele BELARDI wrote: > What about the rest of the system, in particular GCC and the C > libraries? Do you manage to build the 3.x kernel with up to date > system or do you need to ''freeze'' some packages? 3.2 required an older gcc for me. I think 5.x and 6.x worked fine (if memory serves me well). As gcc comes slotted, it is not too hard to have them all installed in parallel. cu Gerrit
