[gentoo-user] Grub: for the love of almighty Zardoz the magniicent....
https://omsi.edu/calendar/zardoz 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??? I need to have a run of brass plaques fabricated with the inscription "If it can fail then the design is wrong" and mail them to each of the penguins that cause me this much heartburn. I have no idea where even to begin fixing this mess...
[gentoo-user] Upgrade to rsync-3.2.0-r1 results in "didn't get server startup line"
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. After upgrading to net-misc/rsync-3.2.0-r1 (from rsync-3.1.3), I can no longer emerge --sync from my clients. I receive messages such as: # emerge --sync >>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'... >>> Starting rsync with rsync://10.10.10.10:5873/gentoo-portage... >>> Checking server timestamp ... opening tcp connection to 10.10.10.10 port 5873 Connected to 10.10.10.10 msg checking charset: UTF-8 sending daemon args: --server --sender -lWtprze.iLsfxCIv --timeout=180 --safe-links --inplace . gentoo-portage/metadata/timestamp.chk (8 args) 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) The rsyncd server shows a successful connection in the logs, and it even logs "rsync allowed access on module gentoo-portage". I've tried turning up the verbosity on both the server and client, but it doesn't really change much. Googlies such as "rsync didn't get server startup line" have turned up nothing useful at all. The rsync 3.2.0 changelog didn't help me either ( https://download.samba.org/pub/rsync/NEWS#3.2.0 ), but I suspect there must be a clue here. If I roll the server version back to rsync-3.1.3, it performs normally. Upgrading the server again to rsync-3.2.0-r1 causes it to break again. Client version appears to be irrelevant. 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? Thanks, Steve Freeman
Re: [gentoo-user] Gentoo chroot with old glibc
> > 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? Tom
Re: [gentoo-user] Gentoo chroot with old glibc
On June 30, 2020 1:26:48 AM PDT, "Andreas K. Huettel" wrote: >> 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... The medium way to do it is to use portage's ability to install packages to a different root directory. Which still has its caveats and challenges but generally avoids EAPI mismatches. LMP
Re: [gentoo-user] old kernel on Gentoo
On Sun, Jun 21, 2020, at 5:31 AM, Raffaele BELARDI wrote: > > -Original Message- > > From: james > > Sent: Thursday, June 18, 2020 21:36 > > To: gentoo-user@lists.gentoo.org > > Subject: Re: [gentoo-user] old kernel on Gentoo > > > > On 6/17/20 12:52 PM, Raffaele BELARDI wrote: > > > Hello, > > > > > > I might need to build and run an old 3.x kernel on a Desktop PC for > > > some very specific tests. Would Gentoo be a good solution? > > > > > > I see that currently gentoo-sources only includes 4.x and 5.x sources. > > > > > > Thanks, > > > > > > raffaele > > > > > > > I use a 3.18.40 kernel, currently, on one of my AMD systems. It has > > thousands of source build packages, not only from portage but many others. > > > > 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? > If you don't care about age of the userland most tools are actually very backwards compatible and should work on a 3.x kernel. You will need to try it, but I expect the modern @system set of packages would work just fine. If you do need an old userland what I might try to do is grab an old Debian/Ubuntu CD. You could then use Portage Prefix to build the older tools you need with a more contemporary userland. Again, the bigger issue will be old releases falling out of tree.
Re: [gentoo-user] upstream broke cups network printing...
On Tuesday, 30 June 2020 04:51:03 BST Alan Grimes wrote: > I was sitting smug and happy thinking I could print from either of my > computers to the laserjet printer downstairs. So therefore when I need > to RMA my mobo and need to print out the forms, it doesn't work. > > The sack of crap seems to think it can connect to the printer using: > > Connection: > dnssd://HP%20Color%20LaserJet%20Pro%20M453-4%20%5B804AC2%5D._ipp._tcp.local/ > ?uuid=beff9c81-55ea-548f-5867-4d44f4da191e You must have enabled DNSSD (DNS Service Discovery) on your systems, whereby DNS packets are sent/received for the purpose of scanning your LAN and discovering various network services, including network printers, media servers, torrents, etc. DNSSD is also known as zeroconf and from what I understand was derived from Apple's Rendezvous/Bonjour. The Linux equivalent is Avahi (for server) and nss-mdns (for clients), but systemd had to re-engineer everything into its own stack as 'systemd- resolved', which uses the MSWindows preferred LLMNR. This is all great if you trust the devices in your LAN not to spoof names and intercept your communications, or if LAN side network services pop-up and down all the time and you want to have them autoconfigured for use by your LAN clients. > Why in god's name does CPUS think that would work, ofcourse I'm going to > get: in my error log > > E [29/Jun/2020:18:39:40 -0400] [CGI] Unable to resolve > \"dnssd://HP%20Color%20LaserJet%20Pro%20M453-4%20%5B804AC2%5D._ipp._tcp.loca > l/?uuid=beff9c81-55ea-548f-5867-4d44f4da191e|HP Color LaserJet Pro> > > > Naturally, there is no other way to configure this crap with the web > interface, there are some on-line manpages but they're written in > moonspeak. =( You do not need network services autoconfiguration, which is is what the dnssd:// URI is trying to achieve, unless printers are added and removed in your LAN on a regular basis with different IP addresses, different client PCs and devices are connected and disconnected all the time and you expect them all to discover network services automatically. In your case, cups is trying to do what you have specified, by enabling of failing to disable a particular USE flag. If you emerged net-print/cups and net-print/cups-filters with USE="zeroconf" enabled you'll get what you got. If you disable it you will arrive at a client-printer combo where you have to manually configure the connection and driver, at least on the client side. Since this is an HP printer, I think you'll need the hplip driver, so check you have this emerged: https://wiki.gentoo.org/wiki/HPLIP Finally, configure your clients to use the printer: https://wiki.gentoo.org/wiki/Printing TL;DR: Stop the cupsd service on your PC. Open and edit "/etc/cups/ printers.conf" file, changing the DeviceURI: DeviceURI ipp://12.345.678.9/ipp/print Where '12.345.678.9' is the statically configured IP address of your printer on your LAN, the '.../ipp/' and '.../print' may or may not be needed - try and see what you get. Restart you cupsd and try to print. Others who use this printer may chime in with specifics. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] old kernel on Gentoo
> I might need to build and run an old 3.x kernel on a Desktop PC for some > very specific tests. Would Gentoo be a good solution? I see that currently > gentoo-sources only includes 4.x and 5.x sources. Should work but you need to make sure your glibc supports the kernel. Minimum for 2.30 and 2.31 is kernel 3.2.0; if you want to go further, you need an old glibc too (see separate thread, this becomes more work). -- 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] Gentoo chroot with old glibc
> 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 dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
[gentoo-user] upstream broke cups network printing...
I was sitting smug and happy thinking I could print from either of my computers to the laserjet printer downstairs. So therefore when I need to RMA my mobo and need to print out the forms, it doesn't work. The sack of crap seems to think it can connect to the printer using: Connection: dnssd://HP%20Color%20LaserJet%20Pro%20M453-4%20%5B804AC2%5D._ipp._tcp.local/?uuid=beff9c81-55ea-548f-5867-4d44f4da191e Why in god's name does CPUS think that would work, ofcourse I'm going to get: in my error log E [29/Jun/2020:18:39:40 -0400] [CGI] Unable to resolve \"dnssd://HP%20Color%20LaserJet%20Pro%20M453-4%20%5B804AC2%5D._ipp._tcp.local/?uuid=beff9c81-55ea-548f-5867-4d44f4da191e|HP Color LaserJet Pro> Naturally, there is no other way to configure this crap with the web interface, there are some on-line manpages but they're written in moonspeak. =( -- The vaccine is a LIE. #TheHonklerIsReal Powers are not rights.
