It ran fine when I worked up another one. I forgot that I had already performed the source builds prior to running the script the first go-around. Duh! I’m personally not a fan of scripts unless I write them for myself, but it worked fine.
I also got my shiny new RockPiX and it worked right out of the box with Debian AMD64 build. Also no problems going from source, so no clue what I fouled up my first go-around.
Anyhow, speaking of source packages, I found the new improvements on this branch of librtlsdr to be interesting:
I burned it to a stick, set up my Windows device to boot from USB UEFI. But boot fails. My device is HP 10-p018wm detachable, not exactly a standard laptop. But I also notice that the FAT partition from the image is completely empty. Is there something I need to know to use a live USB image? It’s been years since I last did live CD boot.
That’s because you missed “Only BIOS boot works. I’ll add EFI boot later” in my previous posting.
In the meanwhile I have fixed EFI boot. I also finally received my new rtl stick in the mail yesterday, so I could test the image and fix DVB blacklisting, which I had forgotten previously. The new image edit: is here superseded, see below.
Another thing: how did you burn the image to the the USB stick? You can’t just copy it. On linux, after unpacking the 7z archive you would use dd if=the_image.img of=/dev/sdX bs=8M status=progress where sdX is the drive letter of your stick (making sure thrice that you are not accidentally erasing your hard disk). On Windows you have a choice of tools to do the same thing. I think that Windows 10 can unpack 7z natively; if not, just get 7zip here.
The FAT partition is the EFI partition, which in the previous image was indeed empty. The system is on the second partition, which is ext4, so Windows can’t read it.
Not really. For this image you need a 64-bit computer and it works both with BIOS and UEFI. You will have to press something (usually F8 or F12) during boot to get a boot menu and then choose to boot from the USB stick. The EFI boot presents itself as “debian”, while the BIOS boot will/might show up as “USB HDD” or similar. Once you have chosen the right thing, it should boot straight into a graphical interface and offer you a login screen. If you have attached your RTL stick with its antenna before you boot, you should be able to just open firefox and see aircraft.
The FA .debs that were used on the stick are also stored on the image in /home/pi/.
May I also suggest a sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/piaware-ubuntu20-amd64/master/install-piaware-web.sh)" . It adds the default index page of the FA SD-card image and makes it possble to just use http://localhost/ in the browser.
Excellent. Over and above problems running piaware itself, I am particularly interested in video, networking and sound problems, i.e. the sort of driver problems that can arise when a system that was installed on some hardware is booted on some other hardware.
sshd is enabled, but root cannot ssh in with password.
User pi is in sudoers, but su - works also and is much handier for root work than sudo this and sudo that.
You can get your feeder-id with cat /var/cache/piaware/feeder-id .
What you have there is a normal debian system. If you are not familiar with linux, you can also (simultaneously) use it for things completely irrelevant to ADS-B, like word processing and listening to music. Beware that doing so can bring forward that day when you wave a final goodbye to Windows.
Then again, the error message “service not found” could itself be misleading. The simplest way to test, assuming that lighttpd is up and running, is to point a browser to http://test_host/ . If you get the piaware status page, the package is good.
When I installed piaware-web manually on Ubuntu, it was ok.
Next I purged it and deleted cloned source folder, and ran the bash script. The installation successfully completed. However when I opened the web page in browser at ip-of-computer and ip-of-computer:80, it showed lighttpd place holder page. Only then I checked status by systemd and got responce service not found. Anyway I will check and try again tonight.
However the same bash script is working OK on Debian 10.6 and Kali 2020, and piaware-web page is displayed ok.
The package creates /etc/lighttpd/conf-available/50-piaware.conf. lighttpd knows nothing about it unless you also ln -s /etc/lighttpd/conf-available/50-piaware.conf /etc/lighttpd/conf-enabled/50-piaware.conf and systemctl reload lighttpd . I suspect (but I am not sure and I can’t check right now) that the .deb has a post-install scriptlet which does just that. Or perhaps there is no such scriptlet (but then why would it have worked on Debian and Kali without manual intervention?). Most likely cause is that there is a scriptlet, but it failed. If so, most likely suspect is permissions (it’s almost always permissions, even when you have double-checked permissions).
Unfortunately, I don’t have much control over that Windows detachable. The whole BIOS is hijacked by some HP thingy. I cannot get it to respond to F2, F10, or F12. The only way I can get it to try from USB is from Windows 10 recovery menu in Advanced Settings.
That Windows device is too feeble so I used balenaEtcher for Mac. (I could use dd on Mac, of course.)
I had never heard of it, but now that I look at it, it seems a valid and proper tool. Of course dd is always preference #1 because it’s so straight-forward, no magic whatsoever included.
It’s very difficult for me to help with this while not understanding where the problem is, but I note that you previously wrote “set up my Windows device to boot from USB UEFI”. If you do again exactly what you did then, but with the new image that I posted today, it should work.
After above commands, used bash script from github to reinstall. It worked oh on two, but failed to display the page on Ubuntu. I was in hurry to leave, so did not try to debug. Most likely clear browser cache, and reload browser will solve it. I will attend it tonight or tomorrow morning.
Uhm, there’s also that other spooky thing, even worse than permissions in creating utterly frustratingly inexplicable errors: selinux. Check getenforce and set selinux to disabled or permissive if needed.
The new image boots from UEFI in my detachable. (The poor thing really doesn’t enjoy the KDE desktop ) Not only that, I finally discovered a path to enable BIOS boot, although BIOS boot with the new image didn’t work. (The trick is still inside Windows 10 advanced boot settings, using the Troubleshoot option. The reason why the normal F2 and F10 didn’t work at boot time is because the keyboard is detachable and requires OS support. The boot loader has to conjure up a touchscreen keypad.)
Another problem with my detachable: This image doesn’t have a driver for its builtin dual band Intel WiFi chip. I had to use a USB 2.4GHz WiFi dongle. Still, after alligator clipping the USB head to my broken Pro Stick Plus, I saw my first plane.
Great, so now it is confirmed to work on all three. What more you could do, since dump1090 and piaware-web are in principle useless without piaware, would be to combine the three scripts into one. And in that process perhaps adopt (and adapt[*1]) the patch that I submitted as an issue on github yesterday to get rid of the hard-coded “buster”.
[*1] It relies on /etc/debian_version, so it probably needs a few more conditionals to work with ubuntu and kali.
It should be able to identify the device and load the correct driver, but there are adapters out there for which there are no linux drivers. Still, it’s strange for an Intel chip and a recent kernel. Can you run lspci; lsusb in a terminal and give me the output?
[ 13.354158] intel_sst_acpi 808622A8:00: firmware: failed to load intel/fw_sst_22a8.bin (-2)
[ 13.354280] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
[ 13.354395] intel_sst_acpi 808622A8:00: Direct firmware load for intel/fw_sst_22a8.bin failed with error -2
[ 13.354401] intel_sst_acpi 808622A8:00: request fw failed
[ 13.419067] Intel(R) Wireless WiFi driver for Linux
[ 13.419071] Copyright(c) 2003- 2015 Intel Corporation
[ 13.419183] iwlwifi 0000:01:00.0: enabling device (0000 -> 0002)
[ 13.421074] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-29.ucode (-2)
[ 13.421192] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-29.ucode failed with error -2
[ 13.421232] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-28.ucode (-2)
[ 13.421333] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-28.ucode failed with error -2
[ 13.421364] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-27.ucode (-2)
[ 13.421465] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-27.ucode failed with error -2
[ 13.421494] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-26.ucode (-2)
[ 13.421595] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-26.ucode failed with error -2
[ 13.421625] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-25.ucode (-2)
[ 13.421726] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-25.ucode failed with error -2
[ 13.421755] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-24.ucode (-2)
[ 13.421855] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-24.ucode failed with error -2
[ 13.421886] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-23.ucode (-2)
[ 13.421987] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-23.ucode failed with error -2
[ 13.422016] iwlwifi 0000:01:00.0: firmware: failed to load iwlwifi-7265D-22.ucode (-2)
[ 13.422117] iwlwifi 0000:01:00.0: Direct firmware load for iwlwifi-7265D-22.ucode failed with error -2
[ 13.422123] iwlwifi 0000:01:00.0: minimum version required: iwlwifi-7265D-22
[ 13.422211] iwlwifi 0000:01:00.0: maximum version supported: iwlwifi-7265D-29
[ 13.422307] iwlwifi 0000:01:00.0: check git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
Output from lspci
$ lspci
00:00.0 Host bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register (rev 36)
00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers (rev 36)
00:03.0 Multimedia controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Imaging Unit (rev 36)
00:0a.0 Non-VGA unclassified device: Intel Corporation Device 22d8 (rev 36)
00:0b.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller (rev 36)
00:14.0 USB controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series USB xHCI Controller (rev 36)
00:1a.0 Encryption controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine (rev 36)
00:1c.0 PCI bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Express Port #1 (rev 36)
00:1f.0 ISA bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCU (rev 36)
01:00.0 Network controller: Intel Corporation Wireless 3165 (rev 81)
From lsusb
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 04f2:b5a9 Chicony Electronics Co., Ltd
Bus 001 Device 008: ID 8087:0a2a Intel Corp.
Bus 001 Device 005: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 04f3:0755 Elan Microelectronics Corp.
Bus 001 Device 007: ID 14cd:125d Super Top
Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
Bus 001 Device 004: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 002: ID 214b:7000
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Well, long antenna short, my decent antenna currently attached to the broken stick is likely overloading the preamp with out of band noise. Waiting for a filter in mail order. But the main reason why the graph only showed one plane is because air traffic is near zero during night in my area.
) Not only that, I finally discovered a path to enable BIOS boot, although BIOS boot with the new image didn’t work. (The trick is still inside Windows 10 advanced boot settings, using the Troubleshoot option. The reason why the normal F2 and F10 didn’t work at boot time is because the keyboard is detachable and requires OS support. The boot loader has to conjure up a touchscreen keypad.)