[RPi 3B Rev 1.2] "Weekend with Arch Linux ARM" Series

Raspberry Pi 2

Re: [RPi 3B Rev 1.2] "Weekend with Arch Linux ARM" Series

Postby Lander1979 » Fri Aug 09, 2019 3:42 am

After powering up the Pi this morning the DNS errors are back :( Must of been something I did yesterday that temporarily shook it loose...

OK this is interesting... If I connect a wired network connection I get " [84.656823] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready.

Now wifi is working, I then remove the wired connection... wifi remains running fine. I think the issue might be with whatever is bridging wlan0 to eth0... for some reason it's not fully awake ?

If I reboot or power cycle the Pi wifi remains working. (this is what tricked me into thinking it was fixed last night).
Even after leaving it powered down for several minutes wifi remains working. This feels like it might be a hardware switch issue on the pi, perhaps power management or blocking?
Lander1979
 
Posts: 27
Joined: Thu Jul 11, 2019 7:35 am

Re: [RPi 3B Rev 1.2] "Weekend with Arch Linux ARM" Series

Postby Lander1979 » Sat Aug 10, 2019 5:57 am

Today's update. I have a Pi 3b+ and a decent ($150AU) 7" 1024x600 hdmi touchscreen, and a ($50AU name-brand Sandisk Ultra) 128GB class10 SDCard. This allows me to do some fun things with the GUI distro's on Pi (right now I'm playing with a full install of i3, KDE Plasma, Gnome, and xfce4, all working perfectly togehter using SDDM as the login manager to switch between them, my /dev/sdx2 is sitting at 44% used ).

I have been experimenting with a RTL-SDR dongle on my large computer running Arch Linux decoding ADSB transponder signals from aircraft and porting the data to a web server that displays the results on a real-time map. Living smack bang in between 5 airports, one of them being Edinburgh AFB, affords for some entertaining flight data and the map gets quite busy at times. I aim to shift these experiments off of the main computer and onto the rPi.

Here is my Installation process and thoughts thus far;

I formatted and mounted my SDCard like so;

/dev/sdx1 +600M vfat *a /boot
/dev/sdx2 +32GB ext4 /
/dev/sdx3 +8.5GB swap
/dev/sdx4 +78GB ext4 /home

I had no issues with being able to read disk volumes above a certain size using ext4, everything just worked. I made the boot partition +600M as It is the only readable part of the sdcard when it is accessed by a MSWIN system, it will also act as the storage for emergency file transfer from MS based systems.

32GB is the upper end of what is recommended for a full rolling installation of Arch Linux so I went with that for the root drive. Some people say that swap drives are no longer needed as the newer kernel's support swap files, but I am a traditionalist and I believe this just works better. The remainding disk space was then assigned to the /home drive.

First Installation steps I took were to follow the ArchLinuxARM Install wikki to the letter. Getting this right is important as it will affect everything else down the track (like user permissions which are truncated by tar causing file access escalation issues; like needing to run ping as a super user, and disk RW acces issues when setting up/changing users home directories).

These instructions are here; https://archlinuxarm.org/platforms/armv ... berry-pi-2

For the longevity of this tutorial I won't repeat the instructions here as arch is a rolling distro; this could change at any time, and probably will.

The Installation files are zipped in a special format called bsdtar which allows the storage of extended file meta-data which Arch uses to dynamically control file and service access permissions. If we use the incorrect program to extract these files we will lose these extended file headers and then we will begin to get into trouble.

If you went this far and didn't use the correct program to unzip and install, and don't want to go back and repeat what you've already done, there is a solution, reinstalling a package will fix the extended file headers.

So we can use this article here to create a recovery script to re-install everything. Even if we didn't mess anything up we can still do this step so that we have a viable recovery option. NOTE: Watch for the missing closing bracket in the Authors code and refer to his screenshots of nano. Use the option pacman --color=auto for a colourful pacman display.

https://linuxhint.com/reinstall_all_pac ... rch_linux/
I went one step further here and added an additional file called update.sh
$this->bbcode_second_pass_code('', '
#!/bin/bash
echo "Deleting old package list."
rm packages.txt
sync
echo "Done. Creating new Catalogue..."
pacman -Qq > packages.txt
sync
echo "Done. Update successful."
')
Now when we add any changes to our packages and we want to reflect this in our recovery file we can issue the command; $this->bbcode_second_pass_code('', './update.sh')


Before you do any pacman related things here llike initializing the keyring you will want to jump across to the main-line ArchLinux install wikki and follow the section on setting up the pacman mirrorlist.
https://wiki.archlinux.org/index.php/installation_guide

We will also want to set up our config.txt for our screen hardware as well as any other Pi-specific instructions like alsa sound and poll only once to preserve the sd card. Refer to the wikki tab on the arm installation page for details. Then finnish the instructions in the ARM install wikki from above.

Once the ARM install wikki has been followed I browse through the main-line ArchLinux install wikki to see if there are any additional steps that are applicable. It turns out there are; Setting up locale and timezone, as well as setting up swap, the fstab, and localhost and network.

Pi wireless may misbehave as it isn't perfect and is shoehorned in on the same bus as the bluetooth. There are fixes and patches but I haven't delved too deeply into them. Essentially you have 3 choices here; 1 use both bluetooth and wireless but have half bandwidth and buffer overrun issues, 2 use wireless but don't use bluetooth, or 3 use bluetooth but don't use wireless. Since I don't actually have any bluetooth devices I wish to pair with I go with option 2 and leave any bluetooth setup out of the process.

If you have any wireless issues try using a wired connection for initial updates, this can often "kick" the wireless module into full life so it wont keep saying "DNS ERROR" even though it can ping and curl. I have no idea why this dirty trick works, it just does. Either wireless doesn't know it's own mac adress and DHCP gives it a kick in the rear, or there is a soft-switch on the wireless chip that isn't doing what it's supposed to...

Once you have booted into your new system and initialized your pacman key rings youre going to want to modify your ps1 to make the terminal a bit easier on your eyes, this can be equated to the choice of playing pacman in monochrome as opposed to playing pacman in colour.
https://wiki.archlinux.org/index.php/Ba ... tomization

Seasoned Arch users consider the ps1 a signature of their work, and many exciting things can be done with modification to the bash files. For instance, all of the custom commands in the arch install iso are actually stored in script in the very same file we will be modifying to change our ps1.

I consider the arch iso bash to be a work of art and a beautiful template for anyone who wants to heavily modify their command prompt; https://github.com/arcolinux/arcolinux- ... el/.bashrc

This is my Root User PS1;
$this->bbcode_second_pass_code('', 'alias ls='ls --color=auto'
alias pacman='pacman --color=auto'
PS1='[\[\033[1;31m\]\u@\[\033[0m\]\033[1;30m\]\h\[\033[0m\]\033[1;34m\]\w\[\033[om\]]\$' ')
This is my Normal User PS1;
$this->bbcode_second_pass_code('', 'alias ls='ls --color=auto'
PS1='[\[\033[1;32m\]\u@\[\033[0m\]\033[1;30m\]\h\[\033[0m\]\033[1;34m\]\w\[\033[om\]]\$' ')

At this stage we can treat the installation the same as we would a standard one. so follow the main-line installation guide, and then follow the post-installation guide here;
https://wiki.archlinux.org/index.php/in ... stallation
Last edited by Lander1979 on Mon Aug 12, 2019 5:13 pm, edited 1 time in total.
Lander1979
 
Posts: 27
Joined: Thu Jul 11, 2019 7:35 am

Re: [RPi 3B Rev 1.2] "Weekend with Arch Linux ARM" Series

Postby Lander1979 » Sun Aug 11, 2019 3:11 am

Ok if I boot up and switch to tty2 and log in I have no wireless, whats more the terminal will be spammed with "brcmfmac power management disabled". If I google this I find a long-running bug hunt across all distro's that the wireless chip manufacturer Cypress keeps closing as solved... when it clearly isn't. I think either we have defective chips or the connection method between the chip and the rest of the system is flawed which would be a rpi manufacturing error.

I have stable wifi however when logging in to tty1, so it looks like NetworkManager is working as it should under SDDM.

https://github.com/raspberrypi/linux/issues/1444
https://github.com/raspberrypi/linux/issues/2453

The Kali Distro guys rely heavily on wifi and their recommendation is shutting off the on-board wifi alltogether and use an external wifi dongle.

In conclusion, your mileage may vary, if you are relying on the onboard bluetooth and wireless for mission critical aspects of a project then the best bet is to switch both out to external USB devices and leave the onboard chips dormant... the way they share the data bus on the rpi is just too iffy.
Lander1979
 
Posts: 27
Joined: Thu Jul 11, 2019 7:35 am

Previous

Return to Broadcom

Who is online

Users browsing this forum: No registered users and 4 guests