Raspberry Pi systems use microSD cards and therefore are more error prone than typical servers with hard disks or SSD. Such corruptions are especially tricky when the only storage available to Raspberry Pi is the microSD card which booted Raspbian OS.
How To Force Filesystem Check
Best thing is to update the /boot/cmdline.txt file to force filesystem repair on the next boot.
I got one of my Raspberry Pi servers attempting to obtain DHCP IP address, a behavior that ignored my static IP address configuration.
Not sure why, but it appeared I’d be getting an extra DHCP address, from the same network segment, in addition to the static IP the Raspberry Pi already had.
Normally I’d just disable the service, but since my home office network is fairly static, I figured I would just remove the DHCP package.
WARNING: do not follow my steps unless you’re in the same situation and pretty sure you’re using static IP addressing.
Double Check that You’re Using Static IP
Check your /etc/network/interfaces file, it should have something similar for your primary interface – in wired network cable case it’s eth0:
Also, run ip a and make sure you’re seeing this same IP among the active interfaces:
greys@s7:~ $ ip a
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b8:27:ee:66:88:ff brd ff:ff:ff:ff:ff:ff
inet 192.168.1.99/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
Remove ISC DHCP Client
So I did this:
root@srv:~# apt-get remove isc-dhcp-client
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
libdns-export1104 libisc-export1100
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
dhcpcd5
Suggested packages:
dhcpcd-gtk
The following packages will be REMOVED:
isc-dhcp-client
The following NEW packages will be installed:
dhcpcd5
0 upgraded, 1 newly installed, 1 to remove and 207 not upgraded.
All cool? Not really. If you read carefully, you’ll notice that I removed isc-dhcp-client, but automatically installed dhcpcd5 – which started making DHCP requests again.
Remove DHCPcD5
Next step then! Let’s remove DHCPcD5:
root@srv:~# apt-get remove dhcpcd5
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following additional packages will be installed:
isc-dhcp-client
Suggested packages:
avahi-autoipd isc-dhcp-client-ddns
The following packages will be REMOVED:
dhcpcd5
The following NEW packages will be installed:
isc-dhcp-client
0 upgraded, 1 newly installed, 1 to remove and 207 not upgraded.
Much better!
Or is it? If you look closer, you’ll see that this command installed isc-dhcp-client back.
Delete both DHCP Client Packages
This time I specified both packages to be removed. I even used apt-get purge instead of apt-get remove – to definitely destroy any configs:
root@srv:~# apt-get purge dhcpcd5 isc-dhcp-client
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages were automatically installed and are no longer required:
libdns-export1104 libisc-export1100
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
pump
The following packages will be REMOVED:
dhcpcd5* isc-dhcp-client*
The following NEW packages will be installed:
pump
0 upgraded, 1 newly installed, 2 to remove and 207 not upgraded.
When this installed pump (that’s apparently another BOOTP/DHCP client – I never even heard about it before), I got curious.
Having researched online, it appears one can configure static IP in Raspberry Pi using DHCP client configs. Doesn’t sound right to me! There’s also the systemd way to disable dhcpd.service, but at this stage I was not looking for half measures.
Having carefully considered this, I decided to unstall the whole lot. It also removed wicd* (Wired and Wireless Network Connection Manager) bunch which is another set of packages for managing network interfaces and connections.
I’m honestly suprised and seriously suprised how involved a network interface and IP address configuration is! Since I’m not using any of these niceties and because this is a static server-like environment where I’m not switching Wi-Fi networks or changing connection profiles all the time, I’m comfortable letting it all go.
Uninstalling DHPCP clients, pump and Wicd
WARNING: be super sure you’re using static IP addressing on your Raspberry Pi system before running the next command.
Here’s the final uninstall command:
root@s7:~# apt-get remove dhcpcd5 isc-dhcp-client pump
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package 'isc-dhcp-client' is not installed, so not removed
Package 'pump' is not installed, so not removed
The following packages were automatically installed and are no longer required:
libdns-export1104 libisc-export1100 openresolv python-wicd
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
dhcpcd5 wicd wicd-daemon wicd-gtk
0 upgraded, 0 newly installed, 4 to remove and 207 not upgraded.
FINALLY! No more DHCP requests from this server 🙂
pS: on a somewhat relevant note, think I’ll upgrade all them 207 packages – but first will complete a reboot to check network configuration still works for the static IP.
I started updating my Centralised RSyslog server on Raspberry Pi the other day, and one of the things I’ve been meaning to research was syntax highlighting for RSyslog logs. After a brief search online, I found grc: a great tool for seeing output of many common Unix commands and log files in a completely new, colorful and useful way.
I noticed that it’s been a while since I upgraded my Raspberry Pi systems. I have updated Raspberry Pi firmware on all of them recently enough, but now decided to upgrade distro. Since Raspbian OS is based on Debian released, it meant I would have to upgrade Raspbian from Jessie base to Stretch.
Step 1: Update/upgrade existing distribution
This simply means we want to upgrade all existing packages before we’ll be moving to the next releast.
Having recently built a centralised log server with RSyslog on one of my Raspberry Pi systems at home office, I’m finally getting to reap the rewards: small and not so small errors get noticed and resolved at last.
Since they all looked like IPv6 addresses, I figured IPv6 would be the explanation. Since I’m not using IPv6 yet, the logical step to resolve issues was to disable IPv6.
Switch BIND9 named to using IPv4 only
By editing the /etc/default/bind9 file, it’s very easy to enfore IPv4 ONLY mode.
Change OPTIONS line from this:
OPTIONS="-u bind"
to this:
OPTIONS="-u bind -4"
Now we just need to restart named daemon. Confusingly enough, it’s done by restarting the service:
greys@becky:/ $ sudo systemctl restart bind9
let’s quickly confirm bind9 status:
greys@becky:/ $ sudo systemctl status bind9
● bind9.service - BIND Domain Name Server
Loaded: loaded (/lib/systemd/system/bind9.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-05-01 16:33:56 UTC; 3s ago
Docs: man:named(8)
Process: 3062 ExecStop=/usr/sbin/rndc stop (code=exited, status=0/SUCCESS)
Main PID: 3067 (named)
CGroup: /system.slice/bind9.service
└─3067 /usr/sbin/named -f -u bind -4
May 01 16:33:56 becky named[3067]: automatic empty zone: EMPTY.AS112.ARPA
May 01 16:33:56 becky named[3067]: configuring command channel from '/etc/bind/rndc.key'
May 01 16:33:56 becky named[3067]: command channel listening on 127.0.0.1#953
May 01 16:33:56 becky named[3067]: managed-keys-zone: loaded serial 788
May 01 16:33:56 becky named[3067]: zone 0.in-addr.arpa/IN: loaded serial 1
May 01 16:33:56 becky named[3067]: zone 127.in-addr.arpa/IN: loaded serial 1
May 01 16:33:56 becky named[3067]: zone localhost/IN: loaded serial 2
May 01 16:33:56 becky named[3067]: zone 255.in-addr.arpa/IN: loaded serial 1
May 01 16:33:56 becky named[3067]: all zones loaded
May 01 16:33:56 becky named[3067]: running
That’s it! Problem solved – no more IPv6 errors in named logs.
I’m converting one of my Raspberry Pi systems, becky, into an RSyslog-based log collector, and while there’s not enough knowledge for a complete tutorial yet, I think I’ll start making short notes here in case someone comes looking for them.
Centralised RSyslog: sort logs by host name
One of the most common tasks after you configure your remote servers to ship logs into your new RSyslog collector is to start logging events into separate log files.
Specifically, you may want to have one log per each server, perhaps with the hostname in the filename.
Here’s how you do this. Add the following lines to /etc/rsyslog.conf, taking into account that your logs location may not be the /logs filesystem but some other path:
While you probably know that Raspbian is the official OS for Raspberry Pi systems, it’s not the only operating system you can use.
In fact, most of Raspberry Pi beginners start with NOOBS – New Out Of Box Software, which is an installer you can download or buy on an SD/microSD card from most of Raspberry Pi vendors.
In addition to this, there’s now a Raspberry Pi Desktop – special distribution that allows you to try Raspbian OS inside a virtual machine or using live USB environment.
Because I own a number of Raspberry Pi systems, I get roughly the same question quite regularly about each one of them: how can I confirm what this Raspberry Pi model is from the command line? The reason I usually want to know is because the model of the Raspberry Pi hints the Raspbian release that will support it (older Raspbian releases do not have support for the most recent models of Raspberry Pi).
There’s a few hardware specs like CPU speed and generation, and also a memory size – they used to be helpful in getting the question above answered.
But turns out there’s an even better way: use the model file in the /proc/device-tree directory, like shown below:
$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2
On another server it returns this:
cat /proc/device-tree/model
Raspberry Pi 2 Model B Rev 1.1
Once you confirm the hardware model, consult the Raspbian page on Wikipedia to see Raspbian versions supporting it.