View previous topic :: View next topic |
Author |
Message |
n1ese Tux's lil' helper
Joined: 29 Sep 2019 Posts: 82
|
Posted: Mon Sep 30, 2019 12:26 pm Post subject: |
|
|
Thank you Sakaki and Neddy. Ordering my Rpi4 2GB tomorrow, can't wait to play with this. |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Sat Oct 05, 2019 2:16 am Post subject: |
|
|
I've added a new wiki page covering setup of a simple X11 desktop on the 'lite' image, here (includes screenshot). _________________ Regards,
sakaki |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Sun Oct 06, 2019 4:28 pm Post subject: |
|
|
Hello,
If you'd like to install and run precompiled Flatpak apps on your Gentoo RPi4 (or RPi3), please see my new wiki entry here.
Once set up as described therein, you can choose from a wide catalogue of prebuilt aarch64 and arm (32-bit) packages.
For example, screenshot of installing Midori.
And screenshot of running it.
Flatpak apps come with all dependencies bundled, don't require root priviliges to install or run, are isolated from potentially conflicting package versions in the main host OS, and provide a degree of user-configurable sandboxing.
Do consider however the security concerns that exist around this technology, before jumping in. _________________ Regards,
sakaki |
|
Back to top |
|
|
Gavinmc42 n00b
Joined: 23 Sep 2019 Posts: 21 Location: Brisbane
|
Posted: Mon Oct 14, 2019 2:30 am Post subject: |
|
|
Quote: | prebuilt aarch64 and arm (32-bit) packages |
Just noticed, "prebuilt 32bit apps". Will they just work on Gentoo64?
No Chroot needed?
Might solve my 32bti Laz/fpc/Ultibo issue at the moment.
While there may be security issues, apps that just run on any distribution just have to make it easier for users. _________________ Don't get Pi's if you are scared of learning. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54629 Location: 56N 3W
|
Posted: Mon Oct 14, 2019 9:05 am Post subject: |
|
|
Gavinmc42,
Maybe. An arm64 CPU is not required to provide the 32 bit instruction set.
I only know one arm64 CPU like that and its not fitted to Raspberry Pis.
There is no multilb on arm64, so dynamically linking 32 bit code on arm64 is not possible.
arm64 CPUs that have the 32 bit instruction set can switch (on a core by core basis) between 64 bit and 32 bit modes.
Flatpacks are like 'containers' they are completely self contained. Rather lie a statically linked QEMU that lets you run an arm64 chroot on an amd64 system.
So yes, if your arm64 CPU has the arm32 instruction set, it should just work.
The security implications are horrendous. All those obsolete vulnerable libraries included for free with your flatpack. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Mon Oct 14, 2019 1:26 pm Post subject: |
|
|
Gavinmc42,
yes, since (as Neddy notes) Flatpak's will bring a full [*] runtime set of necessary libraries with them, and the ARMv8 architecture allows a 64-bit kernel to support both 32 and 64-bit userlands, then Flatpaks marked as arm (32-bit) both show up in the catalogue (when you do remote-ls) and can be installed and run successfully on the gentoo-on-rpi-64bit image. It's not that dissimilar to chrooting into a 32-bit userland (which I discuss on the wiki here), just using some of the kernel containerization technology.
[*] most of the time. Some apps require things with a EULA (such as Oracle JDK/JRE) and these don't tend to get all their deps bundled. But for most regular apps, they will be. _________________ Regards,
sakaki |
|
Back to top |
|
|
n1ese Tux's lil' helper
Joined: 29 Sep 2019 Posts: 82
|
Posted: Thu Oct 17, 2019 10:10 pm Post subject: |
|
|
Sakaki wrote: | (hint: if you only have WiFi, you can use the bundled nmtui tool to easily setup a (persistent) network connection from the command line.) |
Sakaki, I am having issues with the nmtui tool on the lite image. When I select the SSID I want to connect to, it comes back with:
Could not activate connection: The access point /org/freedesktop/NetworkManager/AccessPoint/12 was not in the scan list.
Any thoughts? Thanks |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Thu Oct 17, 2019 10:28 pm Post subject: |
|
|
n1ese,
I've just double-checked, and it works on various APs around here... so definitely not a universal bug. There are some reports of similar errors (on other distros) online e.g. here and here.
Have you tried restarting NetworkManager? Code: | demouser@pi64 ~ $ sudo rc-service NetworkManager restart |
Is there any relevant information displayed in dmesg?
You could also try first deleting your desired SSID in nmtui (under the "Edit..." entry) and then connecting again. _________________ Regards,
sakaki |
|
Back to top |
|
|
n1ese Tux's lil' helper
Joined: 29 Sep 2019 Posts: 82
|
Posted: Thu Oct 17, 2019 10:38 pm Post subject: |
|
|
Sakaki wrote: | You could also try first deleting your desired SSID in nmtui (under the "Edit..." entry) and then connecting again. |
This worked. I manually added the SSID and password and it connected fine. |
|
Back to top |
|
|
n1ese Tux's lil' helper
Joined: 29 Sep 2019 Posts: 82
|
Posted: Fri Oct 18, 2019 12:20 am Post subject: |
|
|
Ok Sakaki, I continue to be an idiot. When trying to configure locales to US I get:
Code: | ganymede /home/n1ese # eselect locale set 4
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
Setting LANG to en_US ... |
Applications such as emerge then break
Code: | ganymede /home/n1ese # emerge --ask gpsd
setlocale: unsupported locale setting
setlocale: unsupported locale setting |
What am I doing wrong? |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Fri Oct 18, 2019 12:48 am Post subject: |
|
|
n1ese,
Have you added your desired locale monikers into /etc/locale.gen and generated them via locale-gen? See e.g. these notes. _________________ Regards,
sakaki |
|
Back to top |
|
|
n1ese Tux's lil' helper
Joined: 29 Sep 2019 Posts: 82
|
Posted: Fri Oct 18, 2019 1:04 am Post subject: |
|
|
Sakaki wrote: | n1ese,
Have you added your desired locale monikers into /etc/locale.gen and generated them via locale-gen? See e.g. these notes. |
Yes sir:
Code: | ganymede /home/n1ese # locale-gen
* Generating 3 locales (this might take a while) with 4 jobs
* (1/3) Generating en_US.ISO-8859-1 ... [ ok ]
* (3/3) Generating C.UTF-8 ... [ ok ]
* (2/3) Generating en_US.UTF-8 ... [ ok ]
* Generation complete
* Adding locales to archive ... [ ok ]
ganymede /home/n1ese # eselect locale set 4
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
Setting LANG to en_US ... |
but I seemed to fix it by doing everything again and re-running env-update && source /etc/profile
so weird, sorry for the wasted bandwidth. Thanks |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Sun Oct 27, 2019 1:28 am Post subject: |
|
|
Automated VL805 (USB) EEPROM / bootloader EEPROM updater now available for gentoo-on-rpi-64bit
All,
as you are no doubt aware, unlike its predecessor, the RPi4B contains a bootloader EEPROM (which replaces bootcode.bin) and also has an EEPROM region holding its VL805 USB chip's firmware. Several updates to both have been made available since launch, offering various bugfixes, additional features, improved power efficiency etc. (e.g., [1,2,3]), so it is well worth keeping them current.
On the Raspbian OS, the package rpi-eeprom may be used to automatically keep both of these on-board firmware components up-to-date, which is very convenient.
Well, I'm pleased to announce this automated update facility is now also available for Gentoo also! To get it, just run:
Code: | demouser@pi64 ~ $ sudo emaint sync --repo genpi64
| to refresh your repository metadata, then:
Code: | demouser@pi64 ~ $ sudo emerge -v rpi4-eeprom-updater
| to install the EEPROM update service (and current images [4]).
Once complete, reboot.
That's it! Now, each time you boot, your bootloader EEPROM and VL805 firmware EEPROM image versions will automatically be checked, by the rpi4-eeprom-updater package's startup service, against the current version images provided by the RP{F,T} (themselves pulled in via the dependency package dev-embedded/rpi4-eeprom-images). If either has changed, appropriate files will be written to your /boot partition (the script that does this is taken directly from the Raspbian rpi-eeprom package) such that on the next boot, a one-time recovery.bin bootloader will cause the image(s) to be (safely) reflashed. You can check the end of the file /var/log/rc.log after boot, to see if any updates are pending.
A weekly cron job on my build server checks the upstream rpi-eeprom package for updated debs, and, if any are found, automatically creates new counterpart ebuilds (dev-embedded/rpi4-eeprom-images and dev-embedded/rpi4-eeprom-updater), and pushes these to the genpi64 repo. That, in turn, means they will automatically get propagated to your machine via the usual weekly genup process (and then installed, on next boot, by the rpi4-eeprom-updater service as just described).
By default, only "critical" updates to the boot EEPROM and VL805 firmware are applied. If you would like (at your own risk) to apply even beta firmware as soon as it is available, edit the file /etc/default/rpi-eeprom-update and change:
Code: | FIRMWARE_RELEASE_STATUS="critical"
| to: Code: | FIRMWARE_RELEASE_STATUS="beta"
|
For avoidance of doubt, the updater may safely be used on the RPi3 (where it has no effect), on cards swapped between the RPi4 and RPi3, on 'full' and 'lite' images, and on gentoo64 images installed via PINN.
Any problems, please let me know!
Best, sakaki
[1] https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=250990
[2] https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=252501
[3] https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=255001
[4] The EEPROM images may be found at /lib/firmware/raspberrypi/bootloader/...
Edited to remove kernel upgrade step (now unnecessary). _________________ Regards,
sakaki |
|
Back to top |
|
|
orion777 Apprentice
Joined: 15 Mar 2017 Posts: 207 Location: Riga, Latvia
|
Posted: Mon Oct 28, 2019 6:48 pm Post subject: |
|
|
Good evening!
Do we have any remote desktop servers, that can be accessed from windows machine? It is required very seldom, but whet the desktop is required, it is very impractical to have HDMI cable... (typical I use ssh session) |
|
Back to top |
|
|
Tony0945 Watchman
Joined: 25 Jul 2006 Posts: 5127 Location: Illinois, USA
|
Posted: Mon Oct 28, 2019 11:21 pm Post subject: |
|
|
orion777 wrote: | Do we have any remote desktop servers, that can be accessed from windows machine? It is required very seldom, but whet the desktop is required, it is very impractical to have HDMI cable... (typical I use ssh session) |
If I understand what you want : https://sourceforge.net/projects/xming/
It runs on Windows and connects to the remote linux machines' X server. There are a few ssh config changes to be made to enable X forwarding. |
|
Back to top |
|
|
Sakaki Guru
Joined: 21 May 2014 Posts: 409
|
Posted: Tue Oct 29, 2019 8:16 am Post subject: |
|
|
orion777 wrote: | Good evening!
Do we have any remote desktop servers, that can be accessed from windows machine? It is required very seldom, but whet the desktop is required, it is very impractical to have HDMI cable... (typical I use ssh session) |
The current gentoo-on-rpi-64bit image ships with xrdp... you can use this to easily connect from a Windows box.
There is a note about this in the project's wiki: here (and, you no longer need to perform the emerge steps described in those instructions, since the necessary packages are bundled). _________________ Regards,
sakaki |
|
Back to top |
|
|
orion777 Apprentice
Joined: 15 Mar 2017 Posts: 207 Location: Riga, Latvia
|
Posted: Thu Oct 31, 2019 3:55 pm Post subject: |
|
|
Thank you!
The problem with xrdp, when connecting from Win7 machine, is that it is unable to accept connection to a machine with "wrong" certificate; whereas Win 8 and 10 can allow it.
So the solution for the Win7 is, as I understood, is to use security_layer=rdp in the /etc/xrdp/xrdp.ini |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54629 Location: 56N 3W
|
Posted: Thu Oct 31, 2019 6:05 pm Post subject: |
|
|
orion777,
You could even get a proper certificate from Lets Encrypt.
They are valid for 3 months at a time. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54629 Location: 56N 3W
|
Posted: Thu Oct 31, 2019 6:41 pm Post subject: |
|
|
Sakaki,
I always wondered why you used demouser for your default user.
I was reading it as de-mouser rather than demo-user until a few minutes ago. :) _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Goverp Advocate
Joined: 07 Mar 2007 Posts: 2185
|
Posted: Fri Nov 01, 2019 8:45 am Post subject: |
|
|
Quote: | Build a better mousetrap, and the world will beat a path to your door |
R. W. Emerson _________________ Greybeard |
|
Back to top |
|
|
BRX7 n00b
Joined: 27 Sep 2019 Posts: 1
|
Posted: Fri Nov 01, 2019 11:25 pm Post subject: Qemu virt kvm |
|
|
Hello again.
I have a question, do current kernels have kvm enabled for qemu/virt ?
As per
https://github.com/sakaki-/gentoo-on-rpi-64bit/wiki/Run-Another-OS-on-your-RPi-as-a-Virtualized-QEMU-Guest-under-KVM
Becuase i see this message on when i emerge qemu 4
* Unable to check your kernel for KVM support
And when i run a guest (win10 from the raspberry forums post)
qemu-system-aarch64: -enable-kvm: No machine specified, and there is no default
Use -machine help to list supported machines
scripts.sh: line 5: -M: command |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54629 Location: 56N 3W
|
Posted: Sat Nov 02, 2019 1:00 am Post subject: |
|
|
BRX7,
That Code: | * Unable to check your kernel for KVM support | means that the ebuild cannot find the kernel .config file.
If you have /dev/kvm you are good.
/proc/config.gz is provided by a loadable module. I forget its name.
Load that module and use zgrep on /proc/config.gz _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
orion777 Apprentice
Joined: 15 Mar 2017 Posts: 207 Location: Riga, Latvia
|
|
Back to top |
|
|
orion777 Apprentice
Joined: 15 Mar 2017 Posts: 207 Location: Riga, Latvia
|
Posted: Wed Nov 06, 2019 7:07 pm Post subject: |
|
|
Good evening!
Several weeks ago I was able to install the hard masket packets via emerge -> config changes... -> dispatch-conf
After the genup (yesterday) now I got the message (masked by: missing keyword), therefore I can't update the config in semi-automatic manneg.
The portage is usb_modeswitch |
|
Back to top |
|
|
Gavinmc42 n00b
Joined: 23 Sep 2019 Posts: 21 Location: Brisbane
|
Posted: Thu Nov 07, 2019 4:53 am Post subject: |
|
|
Something seems to have happened.
Every/most things seems to be masked now.
Extra steps now needed to unmark emerge keywords or what ever it is called. _________________ Don't get Pi's if you are scared of learning. |
|
Back to top |
|
|
|