I installed Buster 2 weeks ago and wanted to check for updates the other day but got an error:
E: Repository '
formatting link
buster InRelease' changed its 'Suite' value from 'testing' to 'stable' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
Despite the reference it took me a while to figure out I needed to add this option, once is enough:
$ sudo apt-get --allow-releaseinfo-change update
(then normal upgrade or dist-upgrade without the option). I later saw that some got an interactive prompt to accept the change but that wasn't the case for me.
This (Friday) evening I upgraded my RPi 512MB 2?B from Stretch to Buster by following the directions on the RaspberryPi.org website for doing the Stretch->Buster upgrade in situ. Overall it took about 5.5 hours to complete and was fairly straight forward and fairly painless.
Niggles (there were a few):
- every 30-60 minutes the upgrade asked whether it should keep a modified configuration file and waited for an answer, so if you use this way of upgrading, keep an eye on it for these questions so the upgrade doesn't sit waiting for input for too long.
- at about 66% complete the upgrade stopped after consistent making repeated complaints about the locale not being set. I set a default locale and restarted the process by rerunning the same command. This time it ran to completion
- Removing the unwanted packages listed in the Buster upgrade instructions and then running the "apt autoremove" upgrade command again deleted the listed packages plus lot of other unneeded packages. A third upgrade run didn't make any more changes, so I rebooted. This was uneventful.
- Finally, I ran my usual weekly update script to see if it would find any overlooked updates. None were found but a another 300MB of packages were reported as unwanted on the voyage and deleted.
- A final run of the weekly upgrade showed nothing more to do. "df -h" showed that Buster is about 0.7 GB bigger than Stretch.
Some other mousing around showed that Buster, unlike Stretch and prececessors, now runs an MTA by default. It uses Exim 4.
My 'todo' list now includes the replacement of Exim with Postfix to bring it inline with my other systems.
- A final reboot worked perfectly, so I ran my usual test routine, a CVS update of a moderately complex multi-module C program, followed by a clean compile and running a regression test suite, showed that this sequence worked as expected.
Yes, that's great. It's also a new version of Mathematica. Strangely, matrix multiplication (and solving linear systems which is about the same) is ~20% slower with V12 on a Pi4 than with V11.4 on a Pi3. Some point-release work to do for them.
... to be clear: the new Mathematica 12 also works on other Raspberry Pis, not just the Pi4. I don't know whether it works on Stretch but my guess would be no.
Following up: I now have Postfix running under Buster.
The package install was easy: I was expecting to use the 'alternatives' mechanism, but it turned out that running "apt-get install postfix" automatically removes exim.
Postfix is now up and running, but only after a major battle with the aliases system, which I use to route all mail sent on my LAN to my house server. Its MTA sends mail for external destinations via my ISP and accumulated everything else for collection by whatever machine on my LAN wants to read it: this means that logwatch reports from everything on the LAN come to me rather than having to be looked for. But, I digress.
It turned out that I could not get Postfix to accept any alias database generated on the RPi with the postalias tool. I ended up copying a known good one from this laptop, which runs Fedora 30, to the RPi. One Postfix restart later, the aliases file was accepted and the problem went away.
I'm thinking this must be a dependency of something you installed manually. I'd have to check my install but for now I think it's not likely that they include an (enabled) MTA by default.
It may have just crept silently in without you noticing - thats what happened here. I had no MTAs installed under Stretch and prior versions, so was somewhat surprised to see exim sitting there, quietly running.
When I found it I assumed it was there to keep RPi4 folks happy if they were expecting to use one as a cheap desktop Linux box. If I'd not wanted an MTA I'd have simply removed it, but it may have its uses in future so I swapped it for Postfix since thats what I already use everywhere else.
I can't check anymore because I do have one (indeed, Exim) as a dependency of the scheduler 'at' which I installed manually. This was from a fresh Buster install and it only came when I installed 'at' so I stand by my assertion. (What I meant was: something you installed *before* you upgraded, where either that dependency wasn't there before or perhaps you removed the old mta long ago and forgot. E.g. 'at' still works without exim, it just skips the local mails.)
Meh. Thunderbird or other GUI mail clients work just like their Win/Mac counterparts: they connect to the mail server themselves so don't need or use an MTA.
Oh! I do have another Buster install without at. No MTA there. The GUI mail client is claws-mail.
Packages that explicitly depend on exim4 listed below. It's not exhaustive "anything that might install exim", e.g. at is not listed because it picks a but I have no idea how it decides, maybe simply the first available from its own list.
Explicit dependencies on exim looks very much like a faulty conversion from the old 'alternatives' way of handling dependencies of the 'must have an MTA' variety from the old initd to systemd - IOW where the dependency is really 'must have an MTA installed' rather than 'must have Exim' installed.
Just had proof that my replacement of Exim with Postfix on the RPi is correctly configured: I'd also installed logwatch when I switched the RPi from Exim to Postfix, and today's logwatch report from the RPi has just been delivered to the MUA (Evolution) running on this Lenovo T440.
it's [mail] about the only way a headless process can communicate: exim to dump mail to a smart host is idiotically simple to set up soo root@pi cand tell you what went wrong
I believe thats why its there.
--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."
- Stephen Vizinczey
I know that from the old days with pine & mutt etc, but also recently because yes, that's how the scheduler 'at' operates. Sorry to keep banging on about that program but it has been the only thing for me in the last few years that wanted an mta.
So what I'm saying is, it's not there in a fresh install.
The all - purpose MTA used to be the horrible sendmail. I gave up on making any configuraton changes to it when even the O'Reilly book about it was so bad that to silently omitted and mention of one of the major configuration sections. I switched to using Postfix at that point and have never looked back since.
Understood, so presumably 'at' isn't there either.
However, last nights change shows that 'at' doesn't require Exim specifically: any full-featured MTA is acceptable.
I upgraded 8 simultaneously on Friday, and it didn't take that long for them, except the one in the shed which is right at the limit of WiFi range and needed a couple of goes at fetching all the packages.
That's a pain, but at least I was driving them from 8 ssh sessions on a large monitor, so I could see when each needed attention. Note, use the screen program, so if the comms drops for any reason, you can resume the same session - otherwise you'll need to fix a broken partial install.
The two main issues for me were:-
1) It seemed to un-configure nginx web server, and in one case reinstall Apache 2 which I'd removed. I needed to set up the nginx sites-available default file, and re-run the RPi Camera Web Interface installer, before my Pi's with cameras started serving again.
2) Bluetooth on the Raspberry Pi 3B is now very unreliable. I use the Pi
3B next to my Bluetooth LE enabled weather station to read its data, and the stack was getting framing errors after one or two reads, stopping any further comms until the interface was taken down and back up. I've found this is a known issue with Buster - it has set too a high a baud rate on the UART connected to the Bluetooth chip, and the 3B has no hardware handshaking. Luckily the weather station is in range of my 3B+ which has hardware handshaking on the UART, so seems to have no issues.
So if you use Bluetooth on a 3B, I recommend holding off on the Buster upgrade until an update lowers the baud rate to what it was under Stretch, which worked reliably for several years.
One thing you can do with the Pi is get it to download email from your ISP, and run an IMAP sever. Then all your email clients on computers, tablets and phones can read email from the IMAP server (using a VPN from outside). This has the advantage of only having to read email once, rather than finding it unread again on every other device.
I should clarify: my Internet connection is nominally 8Gb/sec (ADSL over POTS copper from a relatively distant exchange), but in practise never delivers bulk data faster than 450 Kb/sec. That said, though, the download was well under half the overall time taken - but it was on one of the early 512Mb Pi Bs.
That would be very annoying. Is it possible that the Apache uninstall had left stuff in your filing system that confused the upgrader, e.g. config files in /etc or something in /usr/share?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.