I guess you're referring to this: "The use of emerge-webrsync is recommended for those who are behind restrictive firewalls (because it uses HTTP/FTP protocols for downloading the snapshot) and saves network bandwidth. Readers who have no network or bandwidth restrictions can happily skip down to the next section."
Indeed that was a sub-theme of my question (although I oversaw that "emerge-" was indeed part of the command): could that have an impact on my problem? I'm not behind a firewall and have no bandwidth restrictions (DSL). It's a bad state when you start having to do things which are nominally not relevant, because you don't have anything else to lose (but time). That's called "grasping at straws" > Gesendet: Dienstag, 14. Januar 2020 um 16:47 Uhr > Von: "Peter Humphrey" <pe...@prh.myzen.co.uk> > An: gentoo-user@lists.gentoo.org > Betreff: Re: [gentoo-user] .tmp-unverified-download-quarantine > > On Tuesday, 14 January 2020 11:07:34 GMT n952162 wrote: > > On 2020-01-14 11:10, Peter Humphrey wrote: > --->8 > > >> This is a fresh install from a minimal cd image. I'm starting out with > > >> mkfs. I've tried that 3 times, twice using a stage 3 from 2020/01/08 > > >> and once using a stage 3 from 2020/01/12. > > > > > > Er...you aren't running out of disk space, are you (either physical space > > > or inodes)? Don't forget /tmp and /var/tmp. And what result did 'emerge > > > --sync' return? Specifically, did you see a 'Sync completed' message? > > > Have you watched /usr/bin/top status lines while syncing? > > > > > > And have you actually tried emerge-webrsync? > > > > 'emerge --sync' gave me status 1 and before that, the error about the > > manifest: > > I didn't see a manifest error before; perhaps I overlooked it. > > > Number of files: 158,236 (reg: 131,524, dir: 26,712) > > Number of created files: 158,235 (reg: 131,524, dir: 26,711) > > Number of deleted files: 0 > > Number of regular files transferred: 131,524 > > Total file size: 208.96M bytes > > Total transferred file size: 208.96M bytes > > Literal data: 208.96M bytes > > Matched data: 0 bytes > > File list size: 3.90M > > File list generation time: 0.001 seconds > > File list transfer time: 0.000 seconds > > Total bytes sent: 2.71M > > Total bytes received: 218.79M > > > > sent 2.71M bytes received 218.79M bytes 56.02K bytes/sec > > HOW long?! 56KB/s shows something going badly wrong. > > > total size is 208.96M speedup is 0.94 > > I've never seen a speedup less than 1 before. > > > * Manifest timestamp: 2020-01-12 18:38:55 UTC > > * Valid OpenPGP signature found: > > * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D > > * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 > > * - timestamp: 2020-01-12 18:38:55 UTC > > * Verifying /var/db/repos/gentoo/.tmp-unverified-download-quarantine > > ...!!! Manifest v> > > Manifest mismatch for media-plugins/Manifest.gz > > __size__: expected: 48363, have: 48349 > > That would indeed leave the tree safely in quarantine. > > > Inodes? That's an interesting thought. Not sure how I'd check that ... > > I'll redirect the output into a file next time. > > > > What would I look for in the top(1) status lines (the lines at the top > > before the process table?)? > > I'd want to see how much memory and swap were consumed and available; the > processor load may offer you a clue too. > > > With emerge-webrsync do you mean webrsync or is there some additional > > facility? > > According to the Wiki* the first thing you do after chrooting into the new > system is to issue the command 'emerge-webrsync'. I suggest you try it. > > > * > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Installing_an_ebuild_repository_snapshot_from_the_web > > -- > Regards, > Peter. > > > > >
