| View previous topic :: View next topic |
| Author |
Message |
modulo
n00b
Joined: 16 May 2020
Posts: 1
|
 Posted: Sat May 16, 2020 11:15 pm Post subject: |
 |
|
Just tried the image but I am having trouble with genup - here is what I get, typically:
| Code: | pi64 ~ # genup
* Checking Portage configuration, please wait...
* Gentoo System Updater v1.0.24
* Updating Portage tree and syncing the eix cache
* (this may take some time)...
* Syncing all portage overlays
* Fetching remote list...
* Fetch Ok
* Syncing selected overlay(s)...
* Running emerge --sync
>>> Syncing repository 'gentoo' into '/var/db/repos/gentoo'...
* Using keys from /usr/share/openpgp-keys/gentoo-release.asc
* Refreshing keys via WKD ... [ ok ]
>>> Starting rsync with rsync://isshoni.org/gentoo-portage-pi64-gem...
>>> Checking server timestamp ...
timed out
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(642) [Receiver=3.1.3]
>>> Retrying...
!!! Exhausted addresses for isshoni.org
>>> Syncing repository 'genpi64' into '/var/db/repos/genpi64'...
>>> Syncing repository 'sakaki-tools' into '/var/db/repos/sakaki-tools'...
/usr/bin/git fetch origin
/usr/bin/git fetch origin
Already up to date.
Already up to date.
=== Sync completed for sakaki-tools
=== Sync completed for genpi64
Action: sync for repo: gentoo, returned code = 1
Action: sync for repo: sakaki-tools, returned code = 0
Action: sync for repo: genpi64, returned code = 0
* emerge --sync failed
* Time statistics:
22 seconds for syncing
25 seconds total
* genup: Error: Caught signal - exiting |
I tried adding the IP for isshoni.org in my hosts file in case it was a DNSSEC issue, but it appears that while I can browse to isshoni.org, I don't see gentoo-portage-pi64-gem there.
Also tried manually starting rsyncd.
About the only thing I changed with the system so far was to change the timezone and locale. I did manually emerge layman because genup said layman -S was failing, appears that layman was not installed. Didn't really help though.
Thanks |
|
| Back to top |
|
 |
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Sat May 16, 2020 11:42 pm Post subject: |
|
|
modulo,
just tried this on a fresh copy of the image, connected via a mobile phone hotspot, and all seems to be working OK.
The rsyncd on isshoni.org (82.221.139.201) binds gentoo-portage-pi64-gem to the web directory served at https://isshoni.org/pi64-portage-gemato/
What do you get if you run: | Code: | | pi64 ~ # emaint sync --repo gentoo |
?
_________________
Regards,
sakaki |
|
| Back to top |
|
|
InvisibleRasta
Apprentice
Joined: 30 Mar 2011
Posts: 188
|
| Posted: Mon May 18, 2020 7:06 pm Post subject: |
|
|
| jsut got a new 32GB ssd jsut to test this out. thank you |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun May 24, 2020 8:37 pm Post subject: |
|
|
I have an odd issue with the latest genpi64. I'm trying to use `genup` and it appears to be working, but my X session went black with my mouse cursor still moveable. It used to be limited to a region of the screen but I deduced it was due to the screen locking. I entered my password and the mouse cursor could move around freely again, but my graphics won't come back yet. I opened tty2 and I can login just fine. emerge seems to be pegging my CPU and RAM use is sitting at about 700 MB on a Pi3B (128MB used for graphics) and the default 1G swap (that I plan to expand later), of which only 78MB or so are being used.
I don't really feel comfortable customizing this until it's up to date. Is there a way to do this without my graphics crapping out?
(In the middle of writing this, I noticed it moved on from the "--pretend --empty --verbose @world" stage to actually merging packages -- so maybe it's just super slow. I don't know if my graphics will come back or not.)
EDIT: Next morning, it's still going! 749 of 978 packages...
EDIT2: It completed, but I was unable to get the display driver back. I checked the last emerge log (forgot exact path atm) and it exited with status of 1. The only warnings I could find were typical ones like missing kernel sources, etc., since you don't really need them with a binhost-supported genpi64. At any rate, a reboot seemed to help things, when it struck me to check /etc/portage/make.conf for MAKEOPTS. Sure enough, the default -j5 -l4 was too much for my RPi3, so I lowered it to -j2 -l2 and turned a flashdrive into swap, so now things shouldn't be killed due to low memory.
We'll see how it goes when I need to compile something. I threw 16GB of storage at it, on a separate bus, so hopefully things will be better.  |
|
| Back to top |
|
|
ian.au
l33t
Joined: 07 Apr 2011
Posts: 607
Location: Australia
|
| Posted: Thu May 28, 2020 10:01 pm Post subject: |
|
|
I'm looking forward to getting one of these https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-sale-now-at-75/ I must say.
I've been able to migrate / adapt everything I need to use the pi4 as a desktop, but had to use zram to expand swap and even out the memory use. 4GB is just a touch underdone for an everyday driver, which I've been doing since January with very few issues.
Zram saves larger operations from hitting swap and has really smoothed out the operation of the system. It also seems to have completely resolved an intermittent issue I was having with chromium suddenly crashing when a number of tabs / windows were open for an extended period. It hasn't appreciably slowed the system and monitoring memory use, it seems pretty stable. Ram use jumps up to around 60% and rarely goes past 70%, almost no swapping.
An 8GB pi is going to be a pretty useful desktop replacement for general use, IMO, it's a real pity most won't experience Gentoo on it. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54744
Location: 56N 3W
|
| Posted: Thu May 28, 2020 10:23 pm Post subject: |
|
|
| https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-sale-now-at-75/ wrote: | | But power users, who want to be able to map all 8GB into the address space of a single process, need a 64-bit userland. There are plenty of options already out there, including Ubuntu and Gentoo. |
That Gentoo link points to Sakakis genpi64 repo.
Well done Sakaki!
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
spork_kitty
Tux's lil' helper
Joined: 05 Jul 2019
Posts: 124
|
| Posted: Sun May 31, 2020 2:57 pm Post subject: |
|
|
The news of an 8GB Pi is wonderful! You'll be able to host a minetest server, maybe render something simple in Blender, build Firefox without swap... it'll be nice!
Congrats on GenPi getting the recognition it deserves! There's better RelEng put into this than Gentoo itself imo. |
|
| Back to top |
|
|
safeness
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 105
Location: Eastside, WA
|
| Posted: Mon Jun 01, 2020 4:34 pm Post subject: |
|
|
Hello everyone,
Just curious if anyone has been able to get Rpi-play built on gentoo? https://github.com/FD-/RPiPlay
After running cmake, I get
| Quote: | CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
BRCM_EGL
linked by target "ilclient" in directory /home/pi/RPiPlay/renderers
BRCM_GLES_V2
linked by target "ilclient" in directory /home/pi/RPiPlay/renderers
OPENMAXIL
linked by target "ilclient" in directory /home/pi/RPiPlay/renderers
CMake Error at renderers/CMakeLists.txt:26 (add_library):
No SOURCES given to target: ilclient
CMake Generate step failed. Build files cannot be regenerated correctly.
|
Any ideas on how to fix this?
Thanks! |
|
| Back to top |
|
|
safeness
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 105
Location: Eastside, WA
|
| Posted: Tue Jun 02, 2020 4:45 pm Post subject: |
|
|
It looks like one of the requirements is raspberrypi-omxplayer (and there's an ebuild!) but that fails.
There's a fix on git for the problem I'm having here: https://github.com/popcornmix/omxplayer/commit/96800576209bbf02939a3d71dec91ec1c1da586b
So I've tinkered around a bit with repoman to have a modified ebuild (the -9999 version fails because of an old patch) but I keep getting ebuild.notadded
Any help would be greatly appreciated! |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Jun 05, 2020 7:47 pm Post subject: |
|
|
Run a FOSS, 64-bit Jitsi Meet Videoconferencing Server on your RPi4!
Hello,
If you're looking for a secure, FOSS alternative to Zoom, Hangouts etc. for video-conferencing, you may have come across Jitsi Meet, an Apache-licensed WebRTC-based solution. It has a client that runs purely in your web browser (with native Android and iOS clients also available), coupled with a back-end server complex that performs forum management, selective video forwarding, NAT traversal etc. The source is available here, and you can quickly try Jitsi, with no password needed, at https://meet.jit.si
Unfortunately however, setting up your own Jitsi server instance is somewhat complex, due to the requirement to cross-sectionally configure a group of services, integrate with Let's Encrypt (for certificate management) etc. While Debian has a multi-component, debconf-guided solution for this (curated by upstream), Gentoo currently does not (in tree anyhow).
To help address this, I have recently put together a set of ebuilds in my sakaki-tools overlay which covers the core Jitsi service set, including a pkg_config step that mirrors the flow of upstream's debconf / postinst logic, providing an easy, prompt-based setup for single-box installs. The ebuilds support both OpenRC and systemd, allow for use of either nginx (preferred) or apache as the webserver, and are available on ~amd64 (x86_64) and ~arm64 (aarch64). The server-side Java components are built from source (*) using the provided java-maven-pkg eclass. Automated TLS certificate issuance (and renewal) via Let's Encrypt is supported, but not mandated. Starting a new video-conference is set up to require a password by default (and once created, you can then add a password to that particular conference at your option, before distributing the URL to others).
I have built and pushed the necessary binary packages to the binhost, and made required changes to masks etc in the custom profile, so now you can easily install your own Jitsi server instance on an RPi4 running gentoo-on-rpi-64bit! (Of course, you can also build from source if you wish, rather than using the binhost.) A 2GiB RPi4 is realistically the minimum system to use here (NB: because Jitsi does not process the video streams, but acts simply as a meeting coordination point, selective forwarding unit and TURN server, the CPU requirements are not onerous - an RPi4 should be able to handle a reasonable number of simultaneous participants).
To get started, first follow 'RPi4 64-bit Gentoo Install' instructions below. Once done, follow the 'Jitsi Configuration and Bring-Up' instructions next.
Should you wish to have your Jitsi server start automatically on boot, finally follow the 'Starting Jitsi Automatically' instructions.
Have fun, and please report any issues either in this thread (preferred) or via email to sakaki@deciban.com!
best,
sakaki
PS: if you are instead looking for a quick way to get an x86_64 Gentoo Jitsi server up and running, you might like to take a look at my nspawn-gentoo-jitsi-meet project on GitHub!
RPi4 64-bit Gentoo Install
Prerequisites: you have an RPi4 running gentoo-on-rpi-64bit. It has a dedicated IPv4 address (IPv6 should be supported too, but I haven't fully tested it), and at least 2GiB of RAM. Ideally, for stability your external IP connection is via Ethernet. You have registered a domain name (we will use, purely as an example, foo.barfoo.org in what follows) that resolves (via A record) to the IP address of your RPi4 mini-server: you can ping foo.barfoo.org from an external machine and your RPi answers successfully. No web, prosody, turn, videobridge or jicofo server should currently be running on the target RPi4. Ports 80/tcp, 443/tcp, 4445/tcp, 4446/udp and 10000/udp must be open.
OK, to begin, update the overlays:
| Code: |
pi64 ~ # emaint sync --repo sakaki-tools
pi64 ~ # emaint sync --repo genpi64
|
With that complete, you're ready to emerge the various component servers (jicofo, jitsi-videobridge, coturn etc)! To do so, simply issue:
| Code: | | pi64 ~ # emerge -v --noreplace net-im/jitsi-meet-server |
This package, and all deps, should be available as binary packages on the binhost (if your system is relatively up-to-date), so this shouldn't take too long (compile from source is possible too, but takes about 45mins or so). Assuming it completes OK, congratulations, you are now able to proceed with configuring and bringing up your Jitsi Meet server instance! Continue reading immediately below.
Jitsi Configuration and Bring-Up
Configuration of the Jitsi server complex is done by following a prompt-driven process to fill out a 'master' configuration file (/etc/jitsi/jitsi-meet-master-config; this is a little like the 'env' file in the Docker variant of Jitsi Meet). A set of hooks, one per component, are then automatically invoked to build the underlying configurations (and associated setup steps) for jitsi-videobridge, jicofo, the webserver etc. This ensures that passwords, UUIDs etc. are consistent across all components.
Of course, the underlying blocks may also be configured directly by those who are knowledgeable about Jitsi's 'wiring', and indeed non-single-box installs will require you to do so. But the point of the approach taken here is to help you get a simple instance up and running with the minimum of hassle.
In what follows, I'm going to assume you have a DNS 'A' record pointing to your RPi4, IP address 82.221.139.201, with fully-qualified domain name (FQDN) of foo.barfoo.org — obviously, adapt this for your actual system.
NB: it is possible to reconfigure the server complex any number of times. So you could create a localhost-based version initially for testing, and then migrate to an externally visible version. Or redeploy an existing version to create fresh passwords etc. Up to you!
OK, so now, issue:
| Code: | | pi64 ~ # emerge --config jitsi-meet-master-config |
and you should be prompted to enter the answers to various questions. In what follows, you can simply press Enter to accept the offered default (shown in square brackets) or, type a different answer and then press Enter. The configuration process provides quite a lot of explanatory text for each question but, in the interests of brevity, in the below only the questions (and responses) will be shown.
Remember, this for the (notional) domain foo.barfoo.org, at IP address 82.221.139.201, administrative email your@email.address; obviously, adapt for your own system!
Here's a full flow (minus commentary); parts you may or may not see (depending on whether or not it is the first time you are running the config) are shown in parentheses:
| Code: | pi64 ~ # emerge --config jitsi-meet-master-config
(* Re-use existing configuration for ...? (y/n) [n]: <press Enter>)
* Hostname [...]: <type foo.barfoo.org and press Enter>
* External IP address [...]: <type 82.221.139.201 and press Enter>
* Internal IP address [...]: <type 82.221.139.201 and press Enter>
* Create a localhost alias for foo.barfoo.org? (recommended) (y/n) [y]: <press Enter>
* Copy foo.barfoo.org into "/etc/hostname"? (recommended) (y/n) [y]: <press Enter>
* Max videobridge daemon RAM [1024m]: <press Enter>
* Username [admin]: <press Enter>
* Password [horse-battery-staple]: <press Enter - your generated password will differ>
* Supply pre-existing key/crt pair for foo.barfoo.org? (y/n) [n]: <press Enter>
* Activate Let's Encrypt for foo.barfoo.org? (y/n) [y]: <press Enter>
* Email address [...]: <type your@email.address and press Enter>
* Configuration complete: write it? (y/n) [y]: <press Enter>
* Build component configurations from this? (y/n) [y]: <press Enter> |
It is possible to reconfigure the server any number of times.
Once the underlying component configuration completes, you can try starting up your new Jitsi Meet server instance!
To do so, issue:
| Code: | | pi64 ~ # rc-service jitsi-meet-server restart |
This will start the various component servers (nginx, jitsi-videobridge, jicofo, turnserver/coturn and prosody).
Startup will take about five seconds. Once done, you should be able to browse to https://foo.barfoo.org (remember, this is just a fictional example, use your own FQDN!) from any remote machine and start a new meeting (click GO)! If all is well, you should find that the browser reports a valid TLS certificate ('padlock' symbol) issued by Let's Encrypt.
An automatic renewal job is also scheduled for you, which will keep this certificate up-to-date, restarting the webserver and turnserver as required.
In the browser, allow use of your camera / microphone when prompted, and then click on "I am the host" in the pop-up dialog which appears, and use the credentials above (in this example "admin" / "horse-battery-staple" (without quotation marks); obviously, adapt as appropriate). The new meeting will start, and you will see yourself on screen. You should then be able to send the meeting URL (click the circular (i) icon at the bottom of the window to see it, or look in your browser address bar) to others to enable them to join - they will not require these credentials (however, you can set a 'room' password before inviting any guests, if you wish, again via the circular (i) icon). Note that as you have an externally valid TLS certificate, users can also join via the official Android or iOS Jitsi apps.
To allow Android or iOS app users to initiate new meetings, you'll need to have them add your host address (in this example, https://foo.barfoo.org/) in the Server URL field, under the settings tab of the app (you will also need to let them know the convener credentials — here, "admin" / "horse-battery-staple").
Should you wish to bring the server complex down at any point, issue:
| Code: | | pi64 ~ # rc-service jitsi-meet-server stop |
Logs may be viewed at /var/log/jitsi/... , and in /var/log/messages.
Starting Jitsi Automatically
Once you have your Jitsi server instance working well, you may decide you want to start it up automatically whenever your RPi4 reboots.
To do so, issue:
| Code: | | pi64 ~ # rc-update add jitsi-meet-server default |
Acknowledgement: thanks to all the participants on this GitHub thread for showing how to get jitsi-sctp building on aarch64.
(*) This approach - inspired with thanks by net-p2p/bisq-0.6.3.ebuild - builds the top level (Java) code for sctp, jicofo, and jitsi-videobridge from source, but still pulls in a large number of upstream jars as dependencies. Chasing through all of these to bring them into Portage is certainly possible but way too much work for the scope of this project. Where existing ebuilds exist in Portage, they can be used (as demonstrated e.g. by the dom4j example), and the bundled mvn2ebuild utility makes it relatively straightforward to convert a working maven Java build to an ebuild.
On the web application side, I have just used the upstream deb and unpacked the (compiled) webroot. The is no live server-side content (all that is done via the other components, jicofo, prosody and jitsi-videobridge), and the client-served content is either minified JavaScript or WebAssembly. It is straightforward to build your own webroot if desired (see e.g. here) but unfortunately the use of npm (coupled with interlinked git repos) makes it difficult to port straightforwardly into an ebuild (npm really doesn't want to run offline when using git ><).
_________________
Regards,
sakaki |
|
| Back to top |
|
|
safeness
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 105
Location: Eastside, WA
|
| Posted: Sun Jun 07, 2020 8:34 pm Post subject: |
|
|
@sakaki: looks cool, thanks for the info!
I found that the issue with raspberrypi-omxplayer I was having is here: https://bugs.gentoo.org/626000
Anyone know how to work through this?
Thanks in advance! |
|
| Back to top |
|
|
Sakaki
Guru
Joined: 21 May 2014
Posts: 409
|
| Posted: Fri Jun 12, 2020 4:25 pm Post subject: |
|
|
Hello,
I have just unmasked the first rpi-5.4.y kernels for use by gentoo-on-rpi-64bit users. This is slightly ahead of RPi engineers making this the default branch (still rpi-4.19.y at the time of writing) but stability now appears to be good, and I want to ship a 5.4 kernel in the forthcoming 1.6.0 image release (in the very early stages of prep now).
To update, ensure you have network connectivity, then issue:
| Code: | demouser@pi64 ~ $ sudo emaint sync --repo genpi64
demouser@pi64 ~ $ sudo emerge -v1u bcm2711-kernel-bis-bin bcmrpi3-kernel-bis-bin |
Once this completes, reboot, and you should be using your new kernel!
If, on the other hand, you would rather stay with the 4.19 kernels pro tem (and avoid these auto-bumping to 5.4 on your next genup run), then instead issue:
| Code: | | demouser@pi64 ~ $ sudo nano -w /etc/portage/package.mask/kernel |
and place in that file:
| Code: | >=sys-kernel/bcmrpi3-kernel-bin-5.4
>=sys-kernel/bcm2711-kernel-bin-5.4
>=sys-kernel/bcmrpi3-kernel-bis-bin-5.4
>=sys-kernel/bcm2711-kernel-bis-bin-5.4 |
Save, and exit nano.
Any problems, with the 5.4 kernels, please let me know.
PS the underlying autobuilds for the kernels have been modified, to track rpi-5.4.y (see here, here, here and here).
_________________
Regards,
sakaki |
|
| Back to top |
|
|
sqeeezy
n00b
Joined: 18 Apr 2020
Posts: 5
Location: Spain
|
| Posted: Tue Jun 16, 2020 8:14 pm Post subject: |
|
|
Kernel upgrade went fine but audio jack out doesn't output audio since the change. I had a quick dabble in alsamixer but I'm busy with non-computer things just now so left it. Just so you know.
_________________
- ... .----. .. / -- .- .... -. ..- / ..- - . .-. -. .- / --- - / - .-- .- -. / --- - / --. . .. ..-. ..- .-. / .... .. -. --. - ... / ..- - --- |
|
| Back to top |
|
|
danstoj
n00b
Joined: 20 Jun 2020
Posts: 2
|
| Posted: Sat Jun 20, 2020 10:13 am Post subject: Pi4 Argon1 Case Fan |
|
|
  Shim Fan option in settings, within GenPi64, doesn't run my Argon1 case fan to cool down my Pi4.
I ran this..... ( curl https://download.argon40.com/argon1.sh | bash ) in terminal and got stuck because I'm clearly a Linux noob. (my 8 year old daughter needs this fan to run for a nice cool Pi4 cpu[/topic])
The above script installs and work on Raspbian X and Raspberry Pi OS without issues. (but not installing on GenPi64) possibly due to some kind of dependencies.
I hope that I'm in the right place and the correct forum.
Someone please point me to what this script needs in order to complete installation and run my fan, pretty please.
Dan
_________________
Thanks to Raspberry Pi and Github sakaki-/gentoo-on-rpi-64bit , for pointing me to Gentoo and showing me the true power.
Thumbs up to ETA PRIME on Youtube |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54744
Location: 56N 3W
|
| Posted: Sat Jun 20, 2020 11:37 am Post subject: |
|
|
danstoj,
Welcome to Gentoo.
I've had a look at the script you linked and I understand why it won't work on genpi64.
| Code: | pkglist=(raspi-gpio python-rpi.gpio python3-rpi.gpio python-smbus python3-smbus i2c-tools)
for curpkg in ${pkglist[@]}; do
sudo apt-get install -y $curpkg |
That fragment checks for a number of installed packages and tries to install them if they are not found.
Its using apt-get which won't work in Gentoo as Gentoo uses Portage as its package manager.
The script goes on to set up a systemd service. That's a problem for genpi64 as genpi64 uses OpenRC, not systemd.
It can be fixed by converting what the script does to use the way that genpi64 but its beyond my skill level.
Step1 Is finding raspi-gpio python-rpi.gpio python3-rpi.gpio python-smbus python3-smbus i2c-tools in Gentoo and overlays.
They may have different names in Gentoo. They may not exist as ebuilds at all.
Step2 is converting the systemd service to openrc.
Step3 is wrapping it all up in one or more ebuilds but that's optional.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23029
|
| Posted: Sat Jun 20, 2020 4:08 pm Post subject: Re: Pi4 Argon1 Case Fan |
|
|
As a general note, you should never ever trust any package where the recommended install procedure is curl URL | bash or variants thereof. This is derisively referred to as curlpipesh, and is strongly discouraged by security-minded people because you are downloading an arbitrary shell script from the Internet and running it with no opportunity to review it ahead of time, no assurance that it is safe or even sane, no record of what you downloaded (so if it fails, good luck figuring out what it did before it failed), and no guarantee that it will serve the same content when someone else downloads it earlier or later than you did (so you cannot even rely on other peoples' reviews of its quality, because they may have unknowingly reviewed a different version than you have/will run). Some scripts even commit the additional mistake of starting their execution before the download completes, so if the transfer is interrupted in the middle, you will run an incomplete script, with consequences ranging from nothing to the script running a command with incomplete arguments. Hypothetically, suppose a script contained a section: | Code: | sudo rm -rf /var/tmp/scratch-space/
echo "All done" |
This is intended to clean up the scratch area used by earlier lines in the script, and is reasonable when it works correctly. Suppose further that the connection gets interrupted at just the wrong moment, so the script you actually run stops at /var:Now the script deletes everything under /var, some of which you probably want to keep. If the script is not set to verbose mode (and the default is not verbose), you won't even know what happened. All you have is that the script finished and now /var has been wiped out.
At the very least, you should download the script to a local file, review it to the extent that you feel necessary, and then run the saved copy. This at least lets you have some confidence that it downloaded correctly, and that you can share it for later review if needed. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sat Jun 20, 2020 8:04 pm Post subject: |
|
|
| Or it stops at "sudo rm -rf /" |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23029
|
| Posted: Sat Jun 20, 2020 10:21 pm Post subject: |
|
|
| I thought about that, but that would actually be safer, since rm now defaults to --preserve-root, which, as I understand it, will just fail when the target is /. |
|
| Back to top |
|
|
Tony0945
Watchman
Joined: 25 Jul 2006
Posts: 5127
Location: Illinois, USA
|
| Posted: Sun Jun 21, 2020 2:34 am Post subject: |
|
|
| Hu wrote: | | I thought about that, but that would actually be safer, since rm now defaults to --preserve-root, which, as I understand it, will just fail when the target is /. |
good to know, but I'm not going to test it! |
|
| Back to top |
|
|
Ralphred
l33t
Joined: 31 Dec 2013
Posts: 704
|
| Posted: Sun Jun 21, 2020 4:29 pm Post subject: Re: Pi4 Argon1 Case Fan |
|
|
| danstoj wrote: | | doesn't run my Argon1 case fan to cool down my Pi4. |
Nasty hacky patch https://liquid.me.uk/GenPi64-argon1.patch here.
Grab the argon1.sh from the manufacturer and apply the patch with | Code: | | patch -p1 < GenPi64-argon1.patch |
I CBA to write an ebuild for pypi, so that's a bit hacky too, it just d/l's the tarball and installs it. |
|
| Back to top |
|
|
danstoj
n00b
Joined: 20 Jun 2020
Posts: 2
|
| Posted: Sun Jun 21, 2020 4:48 pm Post subject: Re: Pi4 Argon1 Case Fan |
|
|
| Ralphred wrote: | | danstoj wrote: | | doesn't run my Argon1 case fan to cool down my Pi4. |
Nasty hacky patch https://liquid.me.uk/GenPi64-argon1.patch here.
Grab the argon1.sh from the manufacturer and apply the patch with | Code: | | patch -p1 < GenPi64-argon1.patch |
I CBA to write an ebuild for pypi, so that's a bit hacky too, it just d/l's the tarball and installs it. |
That works! Thanks
_________________
Thanks to Raspberry Pi and Github sakaki-/gentoo-on-rpi-64bit , for pointing me to Gentoo and showing me the true power.
Thumbs up to ETA PRIME on Youtube |
|
| Back to top |
|
|
safeness
Tux's lil' helper
Joined: 02 Jul 2004
Posts: 105
Location: Eastside, WA
|
| Posted: Tue Jun 23, 2020 4:18 pm Post subject: |
|
|
Can anyone please help me to build raspberrypi-omxplayer?
This is the bug I ran into: https://bugs.gentoo.org/626000
It's a requirement for rpi-play (screen cast from iOS with raspberry pi!) https://github.com/FD-/RPiPlay
Any help will be greatly appreciated. Thanks in advance! |
|
| Back to top |
|
|
drizzt
Guru
Joined: 21 Jul 2002
Posts: 428
|
| Posted: Wed Jun 24, 2020 4:01 pm Post subject: Re: Pi4 Argon1 Case Fan |
|
|
| Ralphred wrote: | | danstoj wrote: | | doesn't run my Argon1 case fan to cool down my Pi4. |
Nasty hacky patch https://liquid.me.uk/GenPi64-argon1.patch here.
Grab the argon1.sh from the manufacturer and apply the patch with | Code: | | patch -p1 < GenPi64-argon1.patch |
I CBA to write an ebuild for pypi, so that's a bit hacky too, it just d/l's the tarball and installs it. |
Hi,
I tried to download the patch but server didn't respond. Is the patch still available ? Is there an alternative download option available ?
best regards
_________________
People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54744
Location: 56N 3W
|
| Posted: Wed Jun 24, 2020 5:04 pm Post subject: |
|
|
drizzt
The download work for me ..
| Code: | $ wgetpaste downloads/GenPi64-argon1.patch
Your paste can be seen here: http://dpaste.com/3CJ32V3 |
I didn't read it.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
drizzt
Guru
Joined: 21 Jul 2002
Posts: 428
|
| Posted: Wed Jun 24, 2020 5:08 pm Post subject: |
|
|
thank you neddy.
Restartet my pi and now works too 
best regards
_________________
People don't have to earn my respect. I offer my respect to them, but be careful to lose my respect... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
