Re: [gentoo-user] .tmp-unverified-download-quarantine
On 18/01/20 17:45, n952162 wrote: > What protocol doesn't use acknowledgements? > Why would an eavesdropper want to acknowledge ANYTHING? Isn't that the whole point? Cheers, Wol > > On 2020-01-18 14:50, Wols Lists wrote: >> On 16/01/20 21:01, james wrote: >>> On 1/13/20 3:24 AM, n952162 wrote: On 2020-01-12 16:48, james wrote: > I also install and re-install, as many of the gentoo systems get > "attacked" before I can� complete a secure install, or the hackers > just read much more than I do. > I guess I'm still popular, in very negative way. Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical way or do you mean really hacked over the internet? May I ask how, and how do you know?� What's involved in a secure install? >>> >>> Monitor your connection, with a system setup that the ethernet does not >>> responds to any sort of request. The system just collects and log. NO, >>> I'm not documenting how to do this, but various ways exist, documented >>> on the internet to make *most* ethernet interface to where they are >>> *one-direction* only. HOW you achieve this? There are a myriad of ways. >>> >>> Good Hunting and *never* tell anyone how *you* do this >>> >> If you're handy with an ethernet crimping tool, just cut the TX wires >> and put the interface into promiscuous mode ... >> >> Just be aware that - routers especially - can swap TX and RX so they >> could possibly get round that. >> >> Cheers, >> Wol >> >> > >
Re: [gentoo-user] .tmp-unverified-download-quarantine
What protocol doesn't use acknowledgements? On 2020-01-18 14:50, Wols Lists wrote: On 16/01/20 21:01, james wrote: On 1/13/20 3:24 AM, n952162 wrote: On 2020-01-12 16:48, james wrote: I also install and re-install, as many of the gentoo systems get "attacked" before I can� complete a secure install, or the hackers just read much more than I do. I guess I'm still popular, in very negative way. Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical way or do you mean really hacked over the internet? May I ask how, and how do you know?� What's involved in a secure install? Monitor your connection, with a system setup that the ethernet does not responds to any sort of request. The system just collects and log. NO, I'm not documenting how to do this, but various ways exist, documented on the internet to make *most* ethernet interface to where they are *one-direction* only. HOW you achieve this? There are a myriad of ways. Good Hunting and *never* tell anyone how *you* do this If you're handy with an ethernet crimping tool, just cut the TX wires and put the interface into promiscuous mode ... Just be aware that - routers especially - can swap TX and RX so they could possibly get round that. Cheers, Wol
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 16/01/20 21:01, james wrote: > On 1/13/20 3:24 AM, n952162 wrote: >> On 2020-01-12 16:48, james wrote: >>> I also install and re-install, as many of the gentoo systems get >>> "attacked" before I can� complete a secure install, or the hackers >>> just read much more than I do. >>> I guess I'm still popular, in very negative way. >> >> >> Hmmm.� Is that "attacked" to be interpreted in some sort of >> metaphorical >> way or do you mean really hacked over the internet? May I ask how, and >> how do you know?� What's involved in a secure install? > > > Monitor your connection, with a system setup that the ethernet does not > responds to any sort of request. The system just collects and log. NO, > I'm not documenting how to do this, but various ways exist, documented > on the internet to make *most* ethernet interface to where they are > *one-direction* only. HOW you achieve this? There are a myriad of ways. > > Good Hunting and *never* tell anyone how *you* do this > If you're handy with an ethernet crimping tool, just cut the TX wires and put the interface into promiscuous mode ... Just be aware that - routers especially - can swap TX and RX so they could possibly get round that. Cheers, Wol
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 1/13/20 3:24 AM, n952162 wrote: On 2020-01-12 16:48, james wrote: I also install and re-install, as many of the gentoo systems get "attacked" before I can� complete a secure install, or the hackers just read much more than I do. I guess I'm still popular, in very negative way. Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical way or do you mean really hacked over the internet? May I ask how, and how do you know?� What's involved in a secure install? Here is a good place *to start* self-education:: https://en.wikipedia.org/wiki/Unidirectional_network
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 1/13/20 3:24 AM, n952162 wrote: On 2020-01-12 16:48, james wrote: I also install and re-install, as many of the gentoo systems get "attacked" before I can� complete a secure install, or the hackers just read much more than I do. I guess I'm still popular, in very negative way. Hmmm.� Is that "attacked" to be interpreted in some sort of metaphorical way or do you mean really hacked over the internet? May I ask how, and how do you know?� What's involved in a secure install? Monitor your connection, with a system setup that the ethernet does not responds to any sort of request. The system just collects and log. NO, I'm not documenting how to do this, but various ways exist, documented on the internet to make *most* ethernet interface to where they are *one-direction* only. HOW you achieve this? There are a myriad of ways. Good Hunting and *never* tell anyone how *you* do this caveat emptor James
Fw: Re: Re: [gentoo-user] .tmp-unverified-download-quarantine
In what way is emerge sensitive to reduced bandwidth? > Gesendet: Donnerstag, 16. Januar 2020 um 11:48 Uhr > Von: "Peter Humphrey" > An: n952162 > Betreff: Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine > > On Thursday, 16 January 2020 07:28:19 GMT you wrote: > > > But it's not synced, and that's the point in the end. > > Well, it isn't far off. The tarball will have been made no earlier than the > previous day. > > > Now I don't know, if I run emerge --sync, will it corrupt the system > > I've just installed? > > I can't see how. The worst it can do is to repeat your original problem, and > you'll be no worse off except for the disk space used. If the --sync fails on > verification, the new portage tree will be left in quarantine; that's what the > verification step is for. > > I've reinstalled systems here recently more often than I can count, and I've > always gone on from emerge-webrsync without another --sync. When I have a > bootable system I do boot it, then finish the system build natively, as it > were. > > When all packages have been installed and configured, I do a --sync and an -e > @world, just to make sure everything fits together properly*. > > You will need to do something about that DSL link though, if it's still as bad > while running your new system. > > * Actually, I'm more paranoid than that: I do an emerge @system, then > recompile and reboot the kernel, then an -e @world minus what was installed by > @system. I've no doubt that all the experts would say it's pointless, but I > learned caution when I was leading the team that maintained the 15-mainframe > system at five control centres that runs the national grid in England and > Wales. That was 25 years ago, but some habits stick - and CPU cycles are > cheap. > > -- > Regards, > Peter. > > > >
Re: Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine
On Tuesday, 14 January 2020 18:36:23 GMT n952...@web.de wrote: > 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" Why don't you just try it? What could you lose? "When all else fails, read the instructions." -- Regards, Peter.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Tue, 14 Jan 2020 15:47:51 +, Peter Humphrey wrote: > > sent 2.71M bytes received 218.79M bytes 56.02K bytes/sec > > HOW long?! 56KB/s shows something going badly wrong. This sounds like it could be a network problem. Have you used mirrorselect? > > 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. I wondered if the file was truncated from some sort of network problem, until I checked my tree and saw that that file was 48349 bytes and portage was really happy. > > 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. I would definitely try emerge-webrsync as it downloads a consistent snapshot of the system. You say you have no network or bandwidth restrictions, but 56K/s says otherwise. -- Neil Bothwick ... but you can't expect to wield supreme executive power just because some watery tart threw a sword at you! pgpfCEVX63pZT.pgp Description: OpenPGP digital signature
Fw: Re: [gentoo-user] .tmp-unverified-download-quarantine
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" > 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. > > > > >
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.
Re: [gentoo-user] .tmp-unverified-download-quarantine
n952162 wrote: > On 2020-01-14 11:10, Peter Humphrey wrote: >> On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote: >>> On 2020-01-14 09:44, Neil Bothwick wrote: On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote: > It sounds to me like the repository is broken - having ownership > as root > seems to be slightly more entropy than portage and could have > happened > as a unintended consequence of some uncarefully completed operation. If the repository was broken, it would be affecting a lot more people than just you. Have you tried completely removing your portage tree and reinstating it with webrsync? >>> 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: > > > 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 > total size is 208.96M speedup is 0.94 > * 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 > > > 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?)? > > With emerge-webrsync do you mean webrsync or is there some additional > facility The df command will give you that info. This is a example just replace your device with the one I used. df -i /dev/sdb1 Hope that helps. Dale :-) :-)
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-14 11:10, Peter Humphrey wrote: On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote: On 2020-01-14 09:44, Neil Bothwick wrote: On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote: It sounds to me like the repository is broken - having ownership as root seems to be slightly more entropy than portage and could have happened as a unintended consequence of some uncarefully completed operation. If the repository was broken, it would be affecting a lot more people than just you. Have you tried completely removing your portage tree and reinstating it with webrsync? 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: 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 total size is 208.96M speedup is 0.94 * 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 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?)? With emerge-webrsync do you mean webrsync or is there some additional facility?
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Tuesday, 14 January 2020 09:37:24 GMT n952162 wrote: > On 2020-01-14 09:44, Neil Bothwick wrote: > > On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote: > >> It sounds to me like the repository is broken - having ownership as root > >> seems to be slightly more entropy than portage and could have happened > >> as a unintended consequence of some uncarefully completed operation. > > > > If the repository was broken, it would be affecting a lot more people > > than just you. > > > > Have you tried completely removing your portage tree and reinstating it > > with webrsync? > > 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? -- Regards, Peter.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Tue, 14 Jan 2020 10:37:24 +0100, n952162 wrote: > > Have you tried completely removing your portage tree and reinstating > > it with webrsync? > I've always used emerge --sync rather than webrsync because I always > like to use the smallest hammer possible. But if you say I should use > webrsync rather than emerge --sync, I have no other hint. It's certainly worth trying webrsync, if anything else, it's faster for a full tree. I prefer to use the largest hammer and let the tool do the work for me ;-) -- Neil Bothwick SCSI: System Can't See It pgpe3HoyJ1ZBz.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-14 09:44, Neil Bothwick wrote: On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote: It sounds to me like the repository is broken - having ownership as root seems to be slightly more entropy than portage and could have happened as a unintended consequence of some uncarefully completed operation. If the repository was broken, it would be affecting a lot more people than just you. Have you tried completely removing your portage tree and reinstating it with webrsync? 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. Thus, in answer to your question, yes, I've always removed the portage tree (and everything else). I've always used emerge --sync rather than webrsync because I always like to use the smallest hammer possible. But if you say I should use webrsync rather than emerge --sync, I have no other hint. Is this the proper list to be on? It's the Gentoo User list, which seems to fit.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Tue, 14 Jan 2020 09:04:13 +0100, n952162 wrote: > It sounds to me like the repository is broken - having ownership as root > seems to be slightly more entropy than portage and could have happened > as a unintended consequence of some uncarefully completed operation. If the repository was broken, it would be affecting a lot more people than just you. Have you tried completely removing your portage tree and reinstating it with webrsync? > Is this the proper list to be on? It's the Gentoo User list, which seems to fit. -- Neil Bothwick If ignorance is bliss, why aren't more people happy? pgp9NRm3ftzo4.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-14 00:16, Mick wrote: On Monday, 13 January 2020 22:40:14 GMT Neil Bothwick wrote: On Mon, 13 Jan 2020 11:15:31 +, Mick wrote: According to my emerge --info output I have sandbox, usersandbox and userpriv, all set. The owner of my portage directory and all files therein is root:root. Should the ownership be portage:portage? What is the default? As it happens, I switched a machine from rsync to git syncing last night, so started with a new tree. Everything is root:root. That implies that portage does not drop permissions for the sync, otherwise it wouldn't be able to write to the tree. And ps confirms that with an rsync sync, rsync is running as root. Thanks Neil, this this leaves me mildly confused as to what the gentoo-default ownership of portage tree is/should be. Until I hear differently I'll leave my old installations as portage:portage and the latest as root:root. It sounds to me like the repository is broken - having ownership as root seems to be slightly more entropy than portage and could have happened as a unintended consequence of some uncarefully completed operation. Is this the proper list to be on?
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-13 23:42, Neil Bothwick wrote: On Mon, 13 Jan 2020 12:37:11 +0100, n952162 wrote: The portage tree is sync'ed to the portage tree mirrors. A newer fs snapshot won't include the tree itself, but it will include the new default fs locations for the portage directory. Not sure what you mean ... you mean that the portage tree only comes in with the emerge --sync? A preliminary copy isn't in the stage3 tarball? That's correct. is this happening because I'm not using (the "optional") webrsync? It happens because the stage 3 doesn't contain a tree. The handbook tells you to run a sync after unpacking the stage 3 for that reason. webrsync is just another way of syncing, one that is more efficient than rsync when starting with an empty tree. I mean, am I getting these manifest/verification errors because I haven't used webrsync (apparently not). Which leaves me in a deadlocked situation. A fresh install, according to the instructions, on new hardware, fails. What should I do? Does anyone else have this problem?
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Monday, 13 January 2020 22:40:14 GMT Neil Bothwick wrote: > On Mon, 13 Jan 2020 11:15:31 +, Mick wrote: > > According to my emerge --info output I have sandbox, usersandbox and > > userpriv, all set. The owner of my portage directory and all files > > therein is root:root. Should the ownership be portage:portage? What > > is the default? > > As it happens, I switched a machine from rsync to git syncing last night, > so started with a new tree. Everything is root:root. That implies that > portage does not drop permissions for the sync, otherwise it wouldn't be > able to write to the tree. And ps confirms that with an rsync sync, rsync > is running as root. Thanks Neil, this this leaves me mildly confused as to what the gentoo-default ownership of portage tree is/should be. Until I hear differently I'll leave my old installations as portage:portage and the latest as root:root. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Mon, 13 Jan 2020 12:37:11 +0100, n952162 wrote: > >>> The portage tree is sync'ed to the portage tree mirrors. A newer fs > >>> snapshot won't include the tree itself, but it will include the new > >>> default fs locations for the portage directory. > >> > >> Not sure what you mean ... you mean that the portage tree only comes > >> in with the emerge --sync? > >> > >> A preliminary copy isn't in the stage3 tarball? > > That's correct. > > > > > is this happening because I'm not using (the "optional") webrsync? It happens because the stage 3 doesn't contain a tree. The handbook tells you to run a sync after unpacking the stage 3 for that reason. webrsync is just another way of syncing, one that is more efficient than rsync when starting with an empty tree. -- Neil Bothwick An expert is nothing more than an ordinary person away from home. pgp2UnffRphoW.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Mon, 13 Jan 2020 11:15:31 +, Mick wrote: > According to my emerge --info output I have sandbox, usersandbox and > userpriv, all set. The owner of my portage directory and all files > therein is root:root. Should the ownership be portage:portage? What > is the default? As it happens, I switched a machine from rsync to git syncing last night, so started with a new tree. Everything is root:root. That implies that portage does not drop permissions for the sync, otherwise it wouldn't be able to write to the tree. And ps confirms that with an rsync sync, rsync is running as root. -- Neil Bothwick Cross a tagline and a tribble? You get a full HD... pgpj5rS9b_SbZ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-13 11:48, Neil Bothwick wrote: On Mon, 13 Jan 2020 11:42:23 +0100, n952162 wrote: The portage tree is sync'ed to the portage tree mirrors. A newer fs snapshot won't include the tree itself, but it will include the new default fs locations for the portage directory. Not sure what you mean ... you mean that the portage tree only comes in with the emerge --sync? A preliminary copy isn't in the stage3 tarball? That's correct. is this happening because I'm not using (the "optional") webrsync?
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Monday, 13 January 2020 10:42:57 GMT Neil Bothwick wrote: > On Mon, 13 Jan 2020 10:17:06 +, Mick wrote: > > Right, I haven't changed them on this installation either and emerge > > FEATURES include > > > > '... userfetch userpriv usersandbox usersync'. > > > > With 'userpriv' portage is meant to drop privileges to the owner of the > > gentoo repo directory, but if the directory is owned by root to start > > with I am not clear how userpriv is meant to work. > > According to the make.conf man page, userpriv will > > "Allow portage to drop root privileges and compile packages as > portage:portage without a sandbox" According to my emerge --info output I have sandbox, usersandbox and userpriv, all set. The owner of my portage directory and all files therein is root:root. Should the ownership be portage:portage? What is the default? I haven't performed a full portage sync for a while now to confirm how long it takes here, but a re-sync over a slow ADSL takes ~20 minutes on a dual core ancient Intel, much less on my more modern PCs. More than 80% of this time is spent on verifying the signatures of the downloaded tmp sync file. I would think on a modern AMD Ryzen PC like the OP's it should take a fraction of the time. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Mon, 13 Jan 2020 11:42:23 +0100, n952162 wrote: > > The portage tree is sync'ed to the portage tree mirrors. A newer fs > > snapshot won't include the tree itself, but it will include the new > > default fs locations for the portage directory. > > > Not sure what you mean ... you mean that the portage tree only comes in > with the emerge --sync? > > A preliminary copy isn't in the stage3 tarball? That's correct. -- Neil Bothwick After all is said and done let there not be more said than done. pgpVAZBBYJ8wQ.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Mon, 13 Jan 2020 10:17:06 +, Mick wrote: > Right, I haven't changed them on this installation either and emerge > FEATURES include > > '... userfetch userpriv usersandbox usersync'. > > With 'userpriv' portage is meant to drop privileges to the owner of the > gentoo repo directory, but if the directory is owned by root to start > with I am not clear how userpriv is meant to work. According to the make.conf man page, userpriv will "Allow portage to drop root privileges and compile packages as portage:portage without a sandbox" -- Neil Bothwick Everything should be made as simple as possible, but no simpler. pgpcdM78losEY.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-13 11:17, Mick wrote: I just noticed that there's a new stag3, from 2020/01/12 instead of 2020/01/08 so - since this is a fresh install - I'm just going to start from there. The portage tree is sync'ed to the portage tree mirrors. A newer fs snapshot won't include the tree itself, but it will include the new default fs locations for the portage directory. Not sure what you mean ... you mean that the portage tree only comes in with the emerge --sync? A preliminary copy isn't in the stage3 tarball? I take it your gentoo portage tree is also owned by root:root in its default installation state? Oh, I see you're right - I unpacked it though by cut of the command in the handbook (with -p, I'm sure). Anyway, I used a different sync and timed it more carefully: 1 1/4 hours for the --sync. Completely from scatch. Completely - only lost+found and the tarball in the partition. Using the stage3 that's 4 days newer. I get the same result. The minimal CD hasn't changed since the 8th. Presumably lots of people have used it since then ... New hardware: AMD Ryzen 3 3200g, Asrock b450m mainboard.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Monday, 13 January 2020 08:34:01 GMT n952162 wrote: > On 2020-01-13 09:22, Mick wrote: > >>> Same result. But I didn't delete "the whole portage tree". What does > >>> that mean? > >>> > >>> rm -rf /var/db/repos? > >> > >> If you're using the new default location, I think it is > >> /var/db/repos/gentoo, but someone should confirm that. > > > > Yes, the new location for the portage ebuilds is: > > > > $ ls -la /var/db/repos/gentoo/.* > > > /var/db/repos/gentoo/.: > I just noticed that there's a new stag3, from 2020/01/12 instead of > 2020/01/08 so - since this is a fresh install - I'm just going to start > from there. The portage tree is sync'ed to the portage tree mirrors. A newer fs snapshot won't include the tree itself, but it will include the new default fs locations for the portage directory. > > This bug points to the tree owned by root:root instead of portage:portage, > > interestingly in my most recent installation the tree is owned by root as > > you can see above and I'm not getting this problem. > > > > https://bugs.gentoo.org/661834 > > I'm not exactly sure what you mean here ... did you do a chown -R or > will the ownership be different when my new stage3 is finally downloaded? I do not recall running a chown on this installation. Had I done this, in all likelihood I would have chown'ed it to portage:portage, as older installations of mine are set to. > I'm not keen on overriding the default configuration in a global way > like changing the ownwhip of all files. Right, I haven't changed them on this installation either and emerge FEATURES include '... userfetch userpriv usersandbox usersync'. With 'userpriv' portage is meant to drop privileges to the owner of the gentoo repo directory, but if the directory is owned by root to start with I am not clear how userpriv is meant to work. I take it your gentoo portage tree is also owned by root:root in its default installation state? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] .tmp-unverified-download-quarantine
Mick wrote: > On Sunday, 12 January 2020 23:32:16 GMT Neil Bothwick wrote: >> On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote: I had a similar issue with the .tmp-unverified-download-quarantine continually appearing, deleting it made no difference. In the end I deleted the whole portage tree and resynced, then the problem disappeared. This may or may not have a bearing on your profile issue, but it's worth fixing first. >>> I just finished running "emerge --sync" again, based on something I saw >>> on the internet - it did the whole thing again, takes about 2 hours. >> Two hours? How slow is your connection? > Assuming this is not the time it takes to run rsync (even on a dial-up > analogue modem connection?) I would guess the delay is caused by the > post-sync > tree verification. The .tmp-unverified-download-quarantine file is where the > sync is stored until the signature verification is performed. Even on a > really old dual-core laptop with low RAM the sync and verification only takes > around 20 minutes. > > I'm on DSL, fairly slow DSL but DSL is what they call it, and had a long re-sync time until a month or so ago. It started around the time the verification part started so I assumed it was that. Then it kept getting slower and slower. After a while, I decided to try something else. I found a different server to sync too. The first one was a little better but still slow. I tried another one and hit the jackpot. It was several times faster than the original one. This may not be your problem but it may be worth looking into. You can use mirrorselect to help you find a good server. Try a few and see what changes. For me at least, it pretty much maxes out my DSL. Obviously there is some things that take a while that is done on my end but if the download is slow due to a slow server, maybe you can find a faster one. I might add, I've always tried to get servers that are physically close by because they *should* be faster. I've found that not to be true in every case. As I said, this may not be your problem but it may be worth looking into at least. Just in case. Dale :-) :-)
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Mon, 13 Jan 2020 09:34:01 +0100, n952162 wrote: > >> If you're using the new default location, I think it is > >> /var/db/repos/gentoo, but someone should confirm that. > > Yes, the new location for the portage ebuilds is: > > > > $ ls -la /var/db/repos/gentoo/.* > > /var/db/repos/gentoo/.: > > > > I just noticed that there's a new stag3, from 2020/01/12 instead of > 2020/01/08 so - since this is a fresh install - I'm just going to start > from there. The stage3 doesn't include the portage tree, so that is unlikely to make a difference. Remove the portage tree and either download a snapshot or resync it. -- Neil Bothwick Top Oxymorons Number 43: Genuine imitation pgp3QUx10fnGs.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-13 09:22, Mick wrote: Same result. But I didn't delete "the whole portage tree". What does that mean? rm -rf /var/db/repos? If you're using the new default location, I think it is /var/db/repos/gentoo, but someone should confirm that. Yes, the new location for the portage ebuilds is: $ ls -la /var/db/repos/gentoo/.* /var/db/repos/gentoo/.: I just noticed that there's a new stag3, from 2020/01/12 instead of 2020/01/08 so - since this is a fresh install - I'm just going to start from there. total 1132 drwxr-xr-x 175 root root 4096 Jan 11 10:14 . drwxr-xr-x4 root root 4096 Jan 2 14:22 .. -rw-r--r--1 root root 1349 Jan 11 08:39 Manifest -rw-r--r--1 root root 29427 Jan 11 08:39 Manifest.files.gz drwxr-xr-x 124 root root 4096 Jan 11 10:07 acct-group drwxr-xr-x 109 root root 4096 Jan 11 10:07 acct-user drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-accessibility drwxr-xr-x 206 root root 4096 Jan 11 10:07 app-admin drwxr-xr-x6 root root 4096 Jan 2 12:06 app-antivirus drwxr-xr-x 100 root root 4096 Jan 11 10:07 app-arch drwxr-xr-x 63 root root 4096 Jan 11 10:07 app-backup drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-benchmarks drwxr-xr-x 52 root root 4096 Jan 11 10:07 app-cdr drwxr-xr-x 152 root root 4096 Jan 11 10:07 app-crypt drwxr-xr-x 313 root root 12288 Jan 11 10:07 app-dicts drwxr-xr-x 45 root root 4096 Jan 11 10:07 app-doc drwxr-xr-x 86 root root 4096 Jan 11 10:07 app-editors drwxr-xr-x 206 root root 4096 Jan 11 10:07 app-emacs drwxr-xr-x 126 root root 4096 Jan 11 10:07 app-emulation drwxr-xr-x 50 root root 4096 Jan 11 10:07 app-eselect drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-forensics drwxr-xr-x 125 root root 4096 Jan 11 10:07 app-i18n drwxr-xr-x 20 root root 4096 Jan 2 12:06 app-laptop drwxr-xr-x 73 root root 4096 Jan 2 12:06 app-leechcraft drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-metrics drwxr-xr-x 307 root root 12288 Jan 11 10:07 app-misc drwxr-xr-x 22 root root 4096 Jan 11 10:07 app-mobilephone drwxr-xr-x 55 root root 4096 Jan 11 10:07 app-office drwxr-xr-x 10 root root 4096 Jan 2 12:06 app-officeext drwxr-xr-x 15 root root 4096 Jan 11 10:07 app-pda drwxr-xr-x 62 root root 4096 Jan 11 10:07 app-portage drwxr-xr-x 50 root root 4096 Jan 11 10:07 app-shells drwxr-xr-x 313 root root 12288 Jan 11 10:07 app-text drwxr-xr-x 198 root root 4096 Jan 11 10:07 app-vim drwxr-xr-x 133 root root 4096 Dec 22 09:59 app-xemacs drwxr-xr-x 20 root root 4096 Dec 18 07:47 dev-ada drwxr-xr-x 55 root root 4096 Jan 11 10:07 dev-cpp drwxr-xr-x 108 root root 4096 Jan 11 10:07 dev-db drwxr-xr-x 17 root root 4096 Dec 27 13:24 dev-dotnet drwxr-xr-x 56 root root 4096 Jan 11 10:07 dev-embedded drwxr-xr-x 37 root root 4096 Dec 28 09:42 dev-erlang drwxr-xr-x 35 root root 4096 Jan 11 10:07 dev-games drwxr-xr-x 37 root root 4096 Jan 4 11:40 dev-go drwxr-xr-x 684 root root 20480 Jan 2 12:06 dev-haskell drwxr-xr-x 530 root root 20480 Jan 11 10:07 dev-java drwxr-xr-x 107 root root 4096 Jan 11 10:07 dev-lang drwxr-xr-x 500 root root 20480 Jan 11 10:07 dev-libs drwxr-xr-x 21 root root 4096 Jan 11 10:07 dev-lisp drwxr-xr-x 39 root root 4096 Jan 11 10:07 dev-lua drwxr-xr-x 253 root root 12288 Jan 11 10:07 dev-ml drwxr-xr-x 1604 root root 69632 Jan 11 10:07 dev-perl drwxr-xr-x 230 root root 12288 Jan 11 10:07 dev-php drwxr-xr-x 1791 root root 69632 Jan 11 10:07 dev-python drwxr-xr-x 61 root root 4096 Jan 11 10:07 dev-qt drwxr-xr-x 346 root root 16384 Jan 11 10:07 dev-ros drwxr-xr-x 686 root root 20480 Jan 11 10:07 dev-ruby drwxr-xr-x 34 root root 4096 Jan 11 10:07 dev-scheme drwxr-xr-x 40 root root 4096 Jan 11 10:07 dev-tcltk drwxr-xr-x 76 root root 4096 Jan 11 10:07 dev-tex drwxr-xr-x 40 root root 4096 Dec 4 08:34 dev-texlive drwxr-xr-x 403 root root 12288 Jan 11 10:07 dev-util drwxr-xr-x 80 root root 4096 Jan 11 10:07 dev-vcs drwxr-xr-x3 root root 12288 Jan 11 10:07 eclass drwxr-xr-x 83 root root 4096 Jan 5 11:08 games-action drwxr-xr-x 129 root root 4096 Jan 11 10:07 games-arcade drwxr-xr-x 72 root root 4096 Jan 11 10:07 games-board drwxr-xr-x 60 root root 4096 Jan 11 10:07 games-emulation drwxr-xr-x 24 root root 4096 Jan 5 11:08 games-engines drwxr-xr-x 66 root root 4096 Jan 11 10:07 games-fps drwxr-xr-x 10 root root 4096 Jan 11 10:07 games-kids drwxr-xr-x 73 root root 4096 Jan 11 10:07 games-misc drwxr-xr-x 14 root root 4096 Oct 11 20:04 games-mud drwxr-xr-x 105 root root 4096 Jan 5 11:08 games-puzzle drwxr-xr-x 20 root root 4096 Jan 5 11:08 games-roguelike drwxr-xr-x 50 root root 4096 Jan 11 10:07 games-rpg drwxr-xr-x 12 root root 4096 Dec 27 13:24 games-server drwxr-xr-x 21 root root 4096 Dec 28 09:42 games-simulation drwxr-xr-x 16 root root 4096 Dec 29 13:40 games-sports drwxr-xr-x 54 root root 4096 Jan 11 10:07 games-strategy drwxr-xr-x 44 root root 4096 Jan 11 10:07 games-util
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-12 16:48, james wrote: I also install and re-install, as many of the gentoo systems get "attacked" before I can complete a secure install, or the hackers just read much more than I do. I guess I'm still popular, in very negative way. Hmmm. Is that "attacked" to be interpreted in some sort of metaphorical way or do you mean really hacked over the internet? May I ask how, and how do you know? What's involved in a secure install?
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Sunday, 12 January 2020 23:32:16 GMT Neil Bothwick wrote: > On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote: > > > I had a similar issue with the .tmp-unverified-download-quarantine > > > continually appearing, deleting it made no difference. In the end I > > > deleted the whole portage tree and resynced, then the problem > > > disappeared. This may or may not have a bearing on your profile issue, > > > but it's worth fixing first. > > > > I just finished running "emerge --sync" again, based on something I saw > > on the internet - it did the whole thing again, takes about 2 hours. > > Two hours? How slow is your connection? Assuming this is not the time it takes to run rsync (even on a dial-up analogue modem connection?) I would guess the delay is caused by the post-sync tree verification. The .tmp-unverified-download-quarantine file is where the sync is stored until the signature verification is performed. Even on a really old dual-core laptop with low RAM the sync and verification only takes around 20 minutes. > > Same result. But I didn't delete "the whole portage tree". What does > > that mean? > > > > rm -rf /var/db/repos? > > If you're using the new default location, I think it is > /var/db/repos/gentoo, but someone should confirm that. Yes, the new location for the portage ebuilds is: $ ls -la /var/db/repos/gentoo/.* /var/db/repos/gentoo/.: total 1132 drwxr-xr-x 175 root root 4096 Jan 11 10:14 . drwxr-xr-x4 root root 4096 Jan 2 14:22 .. -rw-r--r--1 root root 1349 Jan 11 08:39 Manifest -rw-r--r--1 root root 29427 Jan 11 08:39 Manifest.files.gz drwxr-xr-x 124 root root 4096 Jan 11 10:07 acct-group drwxr-xr-x 109 root root 4096 Jan 11 10:07 acct-user drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-accessibility drwxr-xr-x 206 root root 4096 Jan 11 10:07 app-admin drwxr-xr-x6 root root 4096 Jan 2 12:06 app-antivirus drwxr-xr-x 100 root root 4096 Jan 11 10:07 app-arch drwxr-xr-x 63 root root 4096 Jan 11 10:07 app-backup drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-benchmarks drwxr-xr-x 52 root root 4096 Jan 11 10:07 app-cdr drwxr-xr-x 152 root root 4096 Jan 11 10:07 app-crypt drwxr-xr-x 313 root root 12288 Jan 11 10:07 app-dicts drwxr-xr-x 45 root root 4096 Jan 11 10:07 app-doc drwxr-xr-x 86 root root 4096 Jan 11 10:07 app-editors drwxr-xr-x 206 root root 4096 Jan 11 10:07 app-emacs drwxr-xr-x 126 root root 4096 Jan 11 10:07 app-emulation drwxr-xr-x 50 root root 4096 Jan 11 10:07 app-eselect drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-forensics drwxr-xr-x 125 root root 4096 Jan 11 10:07 app-i18n drwxr-xr-x 20 root root 4096 Jan 2 12:06 app-laptop drwxr-xr-x 73 root root 4096 Jan 2 12:06 app-leechcraft drwxr-xr-x 31 root root 4096 Jan 11 10:07 app-metrics drwxr-xr-x 307 root root 12288 Jan 11 10:07 app-misc drwxr-xr-x 22 root root 4096 Jan 11 10:07 app-mobilephone drwxr-xr-x 55 root root 4096 Jan 11 10:07 app-office drwxr-xr-x 10 root root 4096 Jan 2 12:06 app-officeext drwxr-xr-x 15 root root 4096 Jan 11 10:07 app-pda drwxr-xr-x 62 root root 4096 Jan 11 10:07 app-portage drwxr-xr-x 50 root root 4096 Jan 11 10:07 app-shells drwxr-xr-x 313 root root 12288 Jan 11 10:07 app-text drwxr-xr-x 198 root root 4096 Jan 11 10:07 app-vim drwxr-xr-x 133 root root 4096 Dec 22 09:59 app-xemacs drwxr-xr-x 20 root root 4096 Dec 18 07:47 dev-ada drwxr-xr-x 55 root root 4096 Jan 11 10:07 dev-cpp drwxr-xr-x 108 root root 4096 Jan 11 10:07 dev-db drwxr-xr-x 17 root root 4096 Dec 27 13:24 dev-dotnet drwxr-xr-x 56 root root 4096 Jan 11 10:07 dev-embedded drwxr-xr-x 37 root root 4096 Dec 28 09:42 dev-erlang drwxr-xr-x 35 root root 4096 Jan 11 10:07 dev-games drwxr-xr-x 37 root root 4096 Jan 4 11:40 dev-go drwxr-xr-x 684 root root 20480 Jan 2 12:06 dev-haskell drwxr-xr-x 530 root root 20480 Jan 11 10:07 dev-java drwxr-xr-x 107 root root 4096 Jan 11 10:07 dev-lang drwxr-xr-x 500 root root 20480 Jan 11 10:07 dev-libs drwxr-xr-x 21 root root 4096 Jan 11 10:07 dev-lisp drwxr-xr-x 39 root root 4096 Jan 11 10:07 dev-lua drwxr-xr-x 253 root root 12288 Jan 11 10:07 dev-ml drwxr-xr-x 1604 root root 69632 Jan 11 10:07 dev-perl drwxr-xr-x 230 root root 12288 Jan 11 10:07 dev-php drwxr-xr-x 1791 root root 69632 Jan 11 10:07 dev-python drwxr-xr-x 61 root root 4096 Jan 11 10:07 dev-qt drwxr-xr-x 346 root root 16384 Jan 11 10:07 dev-ros drwxr-xr-x 686 root root 20480 Jan 11 10:07 dev-ruby drwxr-xr-x 34 root root 4096 Jan 11 10:07 dev-scheme drwxr-xr-x 40 root root 4096 Jan 11 10:07 dev-tcltk drwxr-xr-x 76 root root 4096 Jan 11 10:07 dev-tex drwxr-xr-x 40 root root 4096 Dec 4 08:34 dev-texlive drwxr-xr-x 403 root root 12288 Jan 11 10:07 dev-util drwxr-xr-x 80 root root 4096 Jan 11 10:07 dev-vcs drwxr-xr-x3 root root 12288 Jan 11 10:07 eclass drwxr-xr-x 83 root root 4096 Jan 5 11:08 games-action drwxr-xr-x 129 root root 4096 Jan 11 10:07 games-arcade
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 1/12/20 3:51 PM, n952162 wrote: While installing gentoo from scratch, after doing a "emerge --sync", the command: eselect profile list fails because it can't get any profiles, and I see that the 17.1 profile is in a .tmp-unverified-download-quarantine. 1. what do I have to do to get this going again? 2. how did I end up in this situation?� Is this a known bug.� I simply followed the handbook. Some folks on this list will not like the advise I give; caveat emptor my friend. So, I install and give away many old system so folks can first learn about gentoo, with a working baseline. my latest one, is for a savant EE, that just hates W. I have not seen him for a very long time. He asked for one, and I could not say no. Gentoo is all I recommend as I've pretty much tried many other linux distros; most give me heartburn for a myriad of reasons. I also install and re-install, as many of the gentoo systems get "attacked" before I can complete a secure install, or the hackers just read much more than I do. I guess I'm still popular, in very negative way. SO, I'm always looking for a quick and easy gentoo install method/medium. CloverOS (cloveros.ga) use to work well. Then quite a few releases (through the decemeber 2019) failed in one way or another. I have not tried the latest release, so I'm about to give it a spin, just for fun. I offer this, hoping that all have gone through a few installs, via the handbook, but putting together your own streamlined install system, is a pita to figure-out and get reasonable stable. I've been using gentoo since 2003. A quick, supported install is a pet-peeve for me; to each his own. I've burned up some HD and cpus, and ram trying to bring old gentoo installs up to date; although most made it fine, despite tons of hours. I hope this helps you. Installing gentoo is a religious experience, once you diverge from the handbook; ymmv. Perhaps one day, I'll be able to afford a 7nm and tons of ram system, so the heavy compiling can be complete therein and moved to a target, just like most embedded systems installs are these days. hth, James
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Sun, 12 Jan 2020 23:41:43 +0100, n952162 wrote: > > I had a similar issue with the .tmp-unverified-download-quarantine > > continually appearing, deleting it made no difference. In the end I > > deleted the whole portage tree and resynced, then the problem > > disappeared. This may or may not have a bearing on your profile issue, > > but it's worth fixing first. > I just finished running "emerge --sync" again, based on something I saw > on the internet - it did the whole thing again, takes about 2 hours. Two hours? How slow is your connection? > Same result. But I didn't delete "the whole portage tree". What does > that mean? > > rm -rf /var/db/repos? If you're using the new default location, I think it is /var/db/repos/gentoo, but someone should confirm that. > or: > > rm -rf /var/db/pkg? No, that's the database of installed packages, don't mess with it. > And why should it work? Is it not rather something broken in the > upstream repository? Or the 20200108 minimum cd image I'm using? It's > otherwise a naked machine. No idea, but something went wrong on one sync and I was stuck with this directory. Deleting it was no help, but deleting the whole tree fixed it. It did slow down sync times, but not the the extent you have. -- Neil Bothwick WinErr 00B: Inadequate disk space - Free at least 50MB pgpnSfnnXatmm.pgp Description: OpenPGP digital signature
Re: [gentoo-user] .tmp-unverified-download-quarantine
On 2020-01-12 23:07, Neil Bothwick wrote: On Sun, 12 Jan 2020 21:51:28 +0100, n952162 wrote: While installing gentoo from scratch, after doing a "emerge --sync", the command: eselect profile list fails because it can't get any profiles, and I see that the 17.1 profile is in a .tmp-unverified-download-quarantine. 1. what do I have to do to get this going again? 2. how did I end up in this situation? Is this a known bug. I simply followed the handbook. I had a similar issue with the .tmp-unverified-download-quarantine continually appearing, deleting it made no difference. In the end I deleted the whole portage tree and resynced, then the problem disappeared. This may or may not have a bearing on your profile issue, but it's worth fixing first. I just finished running "emerge --sync" again, based on something I saw on the internet - it did the whole thing again, takes about 2 hours. Same result. But I didn't delete "the whole portage tree". What does that mean? rm -rf /var/db/repos? or: rm -rf /var/db/pkg? And why should it work? Is it not rather something broken in the upstream repository? Or the 20200108 minimum cd image I'm using? It's otherwise a naked machine.
Re: [gentoo-user] .tmp-unverified-download-quarantine
On Sun, 12 Jan 2020 21:51:28 +0100, n952162 wrote: > While installing gentoo from scratch, after doing a "emerge --sync", the > command: > > eselect profile list > > fails because it can't get any profiles, and I see that the 17.1 profile > is in a .tmp-unverified-download-quarantine. > > 1. what do I have to do to get this going again? > 2. how did I end up in this situation? Is this a known bug. I simply > followed the handbook. I had a similar issue with the .tmp-unverified-download-quarantine continually appearing, deleting it made no difference. In the end I deleted the whole portage tree and resynced, then the problem disappeared. This may or may not have a bearing on your profile issue, but it's worth fixing first. -- Neil Bothwick I'm not a complete idiot - several parts are missing. pgpPH0Y0_OZ9y.pgp Description: OpenPGP digital signature
