hpr-knowledge-base/hpr_transcripts/hpr2023.txt

Episode: 2023
Title: HPR2023: Setting up my Raspberry Pi 3
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2023/hpr2023.mp3
Transcribed: 2025-10-18 13:26:56

---

This is HPR Episode 2023 entitled, Setting Up My Raspberry Pi Free.
It is hosted by Dave Morris and is about 29 minutes long.
The summer is, I bought a Pi Free, a case, a heat sink, and a SSD and a set of a pi-up and a server.
This episode of HPR is brought to you by an honesthost.com.
Get 15% discount on all shared hosting with the offer code, HPR15, that's HPR15.
Better web hosting that's honest and fair at An Honesthost.com.
Hello everyone, this is Dave Morris. I've got a show about the Raspberry Pi today. Just to set the context slightly.
Today is the day after Hacker Public Radio reached the rather difficult situation
where it was running out of shows. There were not going to be any more shows in the queue tomorrow.
And I thought I would put this show together in a bit of a hurry in order to try and help fill the gap.
Luckily, we've had seven more shows submitted since that point,
but we're still pretty close to the edge, and we're going to fall over that cliff unless we get more submissions.
So please, if you can, submit a show. If you listen to Hacker Public Radio, then please contribute if you haven't done so already.
Right, my show today is called Setting Up My Raspberry Pi 3, and I bought a Pi 3 in March. It's currently April.
And it was soon after it was released. I'm on various alert lists that tell me this thing, so I thought I'd grab one while they were available.
In fact, they remained available. Continuously pretty much, I think. I want to use this Pi as a server since it's the fastest one that I own.
I have several others. And so I set it up in what I reckon is the best way for this particular role.
And I thought it would be as if I shared what I did. In case you haven't found this sort of information or done this yourself,
show loads of people have. And if that's the case, we'll just hop onto the next show.
But in case you haven't, hopefully this might help a little bit.
So let me list the hardware that I bought. I've tried to link all of this to various sources in the notes.
And there are long show notes with this containing that sort of information.
First of all, obviously the Raspberry Pi Model 3. Then I bought a case, which I like the Pimironi Pibo Piibo cases.
This one was called the Ninja, because it's in great names.
They're good cases, so I like them. It's one of these things. If you haven't seen them, it's made from acrylic.
And it's built up from multiple layers, laser cut layers, which you stack on top and below the pi board itself.
And when it's put together, there's enough room inside it to put one of these hats, HAT things, which dreadful acronym,
which stands for hardware attached on top. But you know, hats, that's fine anyway.
I don't know if I'm going to put one in here, but I thought if I had a case that could do it, then I'm not going to be disappointed in the future.
Apparently this case has got better ventilation than some of the predecessors, which is important for the Raspberry Pi 3.
So I also bought a 2.5 amp universal power supply. Most of the ones I've got a lower rated 2 amp or less.
I come on to wire in a moment. I bought a heat sink. There are two varieties I saw. There's a 6mm one, which is what I bought.
And I think a 7mm. 6mm gives enough room to put it on the CPU and have room to put a hat on top.
And this helps because the pi is a bit hotter. The pi 3 is a bit hotter than its predecessors.
Now what I wanted to do was connect a disk to this beast. So I bought a USB to SATA converter.
This one's got two USB connectors. One you don't really need for the pi 3. It's for using with other systems that don't produce enough power on a USB.
But the other one is obviously the data connection and power. So it's there for signals there for boosting the power from another USB port.
I haven't connected it and don't seem to have a problem with it. I bought a SSD. I found the lowest price I could, which ended up being 120 gigs.
Which I think will be plenty for what I want to do. It would have been nice to have had more, but the prices are still not that low compared to spinning disk.
And I wanted to try an SSD rather than a spinning disk.
I bought a 32 gig microSD class 10 card, but on reflection it's overkill. I'm probably going to swap that out for a smaller one and use a 32 gig somewhere else in due course.
So let me tell you about what I did to set this up. That's really the meat of this thing.
But I'll start with some of the basic things. I installed Razbian the latest version which is Jesse on the microSD card.
Then I set the pie up with a monitor and keyboard and a mouse, temporarily. I've got an old VGA monitor from years ago, which I use for this.
And I've got an HDMI to VGA adapter cable, so I can do this.
So I normally configure up my pies using this and then most of them are just running headless. In fact, all of them are running headless.
So what I normally do, just as a quick list, when I'm setting up a pie, I allocated a fixed IP address. I get the MAC address of it.
And I go to my router and set it up by MAC address to have a fixed IP within my home LAN.
And then I can add that to the very central host files on other systems just to make it easier to connect to it.
I just called it RPI-5. I've actually got six pies now, including the pie zero.
I run all my pies pretty much all, there's one maybe that's debatable.
But I run them directly off the LAN and I've got a router with a gigabit capability.
Most of them are now I guess only. I've got various ones, various pies connected either directly to the router or I've got a bunch of gigabits switches around the house and I connect it to one of them.
I make sure I put VIM on the pie pretty early on because I do not like nano and I want to be able to use a proper editor when I need to edit anything.
I make sure SSH is up and running. That was an issue in the older days, older times, older versions of Razbian, but it isn't so much now.
I think you have to switch it on through Raz by config, but I can't remember whether I did that or not.
Anyway, it was running for the time I had finished. I always create an account on my pies and fill around with the pseudowers editing it with a VI pseudow for which I want VI to be running.
I should say to be available and I use the same account name on all my pies so I can easily administer them with CSSH which is a cluster SSH2.
I share my SSH key with the pie so I can just log in to that account without a password.
I always either delete the pie account, the PI account on them, or change its password and just change the password on this one.
Then I made sure that the pie would boot up in text mode because I want to run it headless and then I put it where it's going to live and there we go.
Let me tell you about what I wanted to do with the SSD.
I wanted to make the system run off the SSD rather than the SD card.
I want this to run for long periods of time. I want it to run as a generic server for various tasks.
I want it to be reliable. I don't want to see my SD card getting corrupted or anything like that.
I've found out how to do this thing where you run your operating system off the disk.
I've actually done this before with another pie but a pie 2 and I bought a cheapo 1TB disk for that.
But I had to power that from a USB hub, a powered USB hub which I bought for not very much about £10 or something.
I've got that set up as well but I think an SSD is going to be better for long term use.
The 1TB is a lot of disk so it's quite nice to have that.
It's going to be doing some backups of that particular machine.
But in doing the pie 2 I use the Adafruit tutorial which I've linked to in the notes.
And this tutorial is based on an article which goes back to 2013 and is available on the Raspberry Pi forums.
Again I've indexed it written by a guy called Paul V.
Just as an aside while I'm talking about this, pies and cases and stuff, I'd actually bought an aluminium case for the pie 2.
It's got the name of F-L-I-R-C, Flur I suppose you say.
I like this because it's quite nice looking and it's very robust and it's got a heat sink built into it.
There's a heat sink that the case is constructed so this part of it hovers just over the CPU.
And there's a pad that you can put on the top of the CPU to connect it on.
And so the whole case becomes a heat sink.
I would love to have got another one of these. They're a little bit more pricey but not much.
But I don't think I can use it with the Pi 3 because it will block the Wi-Fi and the Bluetooth.
And I'd quite like to have those available even though I'm not using the Wi-Fi at the moment.
I haven't tried it out and I can't find confirmation that this would be a problem but I've heard several people suggest that you do not put a Pi 3 in a metal case.
Anyway, let's get back to the Adafruit tutorial.
So what I did was I set everything up with the SSD connected through the SATA connector.
And then I went to the Pi and SSH to it in fact, to determine what device my SSD was connected to.
I found it was actually on slash dev slash SDA1. I used D message to find this.
I grabbed the Adafruit code which is on GitHub. I think you can get it off a repository but it's the Adafruit repository.
And I couldn't be bothered to set that up. So I just did a Git clone which I've put in the notes.
You'll find it in the tutorial. The tutorial is great but I thought it would be useful if I did a show on it.
And I simply ran the script that comes in from the Git repository.
Basically it's just a script and some stuff for configuring it all up as a package should have been packaged.
So I just cDed to the directory which had been created by the Adafruit Git repository.
And with sudo, ran the script called Adafruit hyphen pi hyphen external root hyphen helper.
You have to give it a minus D and the name of the device, not the name of the partition SDA1, the name of the device slash dev slash SDA in my case.
And ran that and rebooted the pi and it was all done. So it's pretty simple.
Now you could know if you want to do this you can just go with our tutorial, follow it and you'll be good to go.
But what I've done in this particular show is I've just drilled down into the script to explain what it does.
I wanted to know what it did and it's bash script and it's very nicely written.
And I thought I'd just share what I found by going through it and describing the actions.
None of which are really world-shattering but it's useful to know.
Especially if you want to modify it in any way or undo what you've done or anything of that sort.
So it has to be run as root because it's going to do some low-level stuff with the disk and stuff.
It's available, the script available is under MIT license.
So I have included a copy on the HBR site so you can have a look at it and check it out as I describe it.
And as I've said in the notes, if you're not interested you can just skip to the end.
So the script starts by ensuring all the necessary packages have been installed.
It's actually quite nicely put together this script.
It's using various functions which report messages with a piece of colored text on the front of them.
It's really nice to look at on a color terminal.
It wants to make sure that the packages that it needs are available.
It uses that to get to install them.
So I guess that's going to restrict it to running on a Debian system which I don't...
I'm not sure if it's actually been stated that that's a restriction.
But there you go.
Didn't actually follow that through to see if there were other versions of it.
It wouldn't be very hard to modify it to something else.
Anyway, the packages at once are GDisk, RSync and Parted.
It then uses the Parted tool.
I'd never come across this before. It's actually really nice.
It's where it's letting you script various disk functions.
And it makes a partition table type GPT.
And then it makes a primary partition of type EST4 on the disk.
So as it does this, it's actually going to zap the disk.
It's going to completely obliterate anything that currently exists on that disk.
Then it does a make FS, MKFS, to build an EST4 file system on that partition.
And it calls it root FS.
Then it uses a tool called BLK block, BLKID block ID.
I call it, because it needs to know the UUID for the partition.
This is an interesting tool, actually.
When you call it in the way that's being used in the script, which is BLKID minus O,
space, export, and then the name of the partition.
When you do that, it returns a list of information about the partition you're pointing it at.
But it does it in the format, key equals value.
There's a bunch of these. You can just run it.
It doesn't change anything. You can run and see how it works.
That's what I did when I was writing these notes.
Now, what it does is the script encapsulated this call to BLKID with an EVAL call.
So it's actually a command substitution.
I'm saying all this talk, because I'm assuming you've been listening to some of my other shows
and know what I'm talking about.
This command substitution is an argument to the EVAL capability of bash.
What that does is it takes all of the stuff that's returned by the command, the BLKID command,
and it executes it as if it's a bunch of bash commands.
And the bash commands will be things like key equals value.
So one of them is UUID equals and then the value of the UUID.
So what that then does is it's in the environment it creates a variable called UUID and capitals,
and it sets it to that value.
So once that's called, you will have these various values set.
There's a bunch of other ones, but you'll have them all set.
And then the script stores the variable UUID into its own variable,
which is called target partition UUID.
So that's a clever piece of bash stuff, which I have not covered in any of my shows yet,
but we'll do in due course.
Now the script then has to get the thing called the partition unique GUID from the device.
So there are these two values as the UUID and then there's this GUID.
This is needed to make the boot sequence use this disk rather than the SD card.
And it does this by sending the command to the GDisk utility.
The command at sending is simply the letter i, which is asking for partition information.
So GDisk is followed by the name of the device.
And in the output that comes back, there will be a line beginning with partition unique GUID colon.
And there's a pipeline that's set up, which searches for that string with GREP.
And the fourth element, which is the actual GUID value, is extracted with ORC.
And the result of all this is that a variable called partition unique GUID is set to that GUID.
So this is another case of doing it in a command substitution.
So the line is export partition underscore unique underscore GUID equals.
And then the command substitution echo letter i to GDisk.
Blah blah blah, I won't read it all out in detail.
You can see it if you want to examine it closely.
It's on line 120 of the script.
I didn't number the copy, but I'm sure you'll be able to do that for yourself.
So by this point, the script has determined the partition new GUID and the GUID,
which are two values that it needs for the next stage.
And it reports these lines 122 and 123.
The next thing it does is to mount the new partition that's been created.
And it mounts it against a mount point called slash MNT.
Which I assume already exists, because mount doesn't usually create mount points for you.
I'd imagine that it always gets created automatically by Raspbian.
There is part of the Raspbian setup.
Didn't actually look at that personally, but anyway, having mounted the disk,
it's now made everything, collect information about it, and it's mounted it.
It uses our sync to simply copy everything under the root directory,
which is the slash directory on the SD card to slash MNT on the external disk.
And this is not quick because those Raspbian cards are not particularly fast.
And there's a lot of files there, an entirety of a Raspbian system.
In my case, I installed full Raspbian.
So that means there was a fair amount, pretty much the entirety of the Raspbian system
is being copied across to the hard disk, or the SSD or whatever.
Then the script edits the file slash boot slash cmdllne.txt, command line.txt.
And it first of all makes a backup copy called slash boot slash command line.txt.bak.
Yeah, it just uses a CP to do that.
And it uses said to edit it.
But I made the note that being slightly a bit of a smart alloc here,
but it's using said to do the edit.
It could have done the edit and the backup in the same command,
which you will know if you have been following my said series, I said.
So, okay, you can slap me about the head another time.
Anyway, the said command changes the definition of the root device in this command line.txt file
to the disk rather than to the SD card.
And it sets an extra value called root delay equals five,
which is a five second delay for the disk to become ready.
The comments there in the script saying the author's not sure if this is really necessary.
I haven't experimented with shorter ones.
I've only seen people recommend something like a two second delay.
In my case with an SSD, I would imagine there's very little delay.
That's probably a delay for the disk to spin up out of thought.
You're going to have no spinning when it comes to an SSD.
So, I shall tune that at some stage.
The said command, which is online, let me just look.
Online 135 of the script.
It uses the minus i command line option to do an edit in place.
And that's the point at which you could generate the backup as you will know.
Et cetera, et cetera. Advertising my said series, of course.
Now, notice, here's an interesting thing,
because I have not done this in the said series I've been doing.
The command, which is an s command, is enclosed in double quotes.
I've been in closing things in single quotes,
because that's the safest thing to do.
But this one's enclosed in double quotes because there's a reference to a variable substitution in there.
And you can't do variable substitutions in single quotes.
So, what he wants to do is to substitute in the value of partition underscore,
unique underscore, GUID, that was fished out earlier on.
And that value has to be plugged into this file, interestingly.
So, he's done it in double quotes, which will achieve that particular necessity.
That's actually something that sort of will come out of my series about the whole expansion process within Bash.
Just in case you're interested.
So, notice that the author has escaped the slashes in the s command.
He's looking for the sequence slash dev slash mcblk0p2,
which is the name of the partition on the SD card.
And he's put, escapes, he's put backslashes in front of the slashes.
But he's used the vertical bar delimiter to the s command.
So, you don't need to escape.
You're needed to do that if you used slashes as your delimiter.
So, just me being picky.
So, once all that's happened, then your command line has been updated to point the right place.
And the next thing the script does is to edit et cetera FS tab.
I should have said that the command line thing, the boot command line,
is the actual command that's invoked during the boot process that gives the boot process information about what way to get the rest of the code to be running to start up your Raspberry Pi.
Et cetera, slash FS tab is a file that is used by the starting Linux system
to mount any devices that are necessary.
So, in the original one, there will have been an entry for the root partition on the SD card.
So, we want to point that instead at the equivalent on the hard disk.
So, the sequence here is that a said command is run against the copy of the FS tab, which is under slash mount.
So, slash MNT slash et cetera slash FS tab, editing that.
And it comments out the line containing the SD card partition.
And it looks for a line beginning work that contains MMC BLK 0P2,
puts a hash mark on the front with a nice piece of said.
And it's that in place, of course.
Then it echoes the new line to the end of the file.
And this is a line which contains a parameter substitution.
It's in double quotes. And the thing that being part of it being substituted,
my mouth is saying what I'm looking at.
The thing that's substituted in there is the UUID that we collected earlier on.
So, it's making a line that says slash dev slash disk slash by hyphen UUID slash.
Then the UUID value that we collected and then the rest of it won't read it all out.
And it depends that to the end of the et cetera FS tab copy.
So, once that's done, everything is finished.
And the script simply prompts you to check to see if you want what happened.
And I'm going to look at the files that have been changed,
which are simply this command line slash boot slash command line dot text and slash MNT slash et cetera FS tab.
And once you're happy, just reboot.
So, I obviously did this and I captured the transcript of what went on.
And I do this just from my own records, really stick it into my wiki or a keep all sorts of stuff.
And so, I thought I'd just stick this into the collection of files for these notes.
So, there's a link to it in the notes.
I didn't actually do exactly the way that the tutorial recommends.
I normally S U2 to root and just run everything as root rather than using pseudo all the time.
But that's just a personal foil.
One thing that I also followed up with was if you set up such a thing,
and for some reason rather you wanted to revert, how would you do it?
Obviously, you could just generate a new SD card and bond that in and everything's good to go.
You can also edit the slash boot slash command line dot text on the SD card,
because that's really the only thing that's left on the SD card that is particularly important in this process.
Anyway, we've got a backup there, so you can just simply revert by replacing the change file with the backup.
Of course, since any updates and changes and installations and so forth,
you might have done will be done on the external disk if this happens sometime afterwards.
Then those will disappear because they're on the disk and you've just set things up to boot of the SD card.
So, you'd have to reapply them or do something clever to copy them across.
But I've never wanted to do this sort of reversion, I have to say,
but you know, it's useful in case you ever do to understand what you could do.
So I'm finishing off then with a picture of my little corner,
which contains three Raspberry Pi's, one of which is in the metal case with a powered USB hub and a disk,
and another of which is the latest Pi 3, one at the front, actually.
You can see the SSD connected to it, and it's even got my little eight port gigabit switch alongside.
So you can pick those up by the way for quite small amounts of money on eBay, which is why I've got several of them.
Yeah, so that's pretty much it. It's just me really telling you about something you could have worked out for yourself,
but sometimes it's useful if somebody else points you in the direction.
And I thought it would be useful just to look at what was entailed in making this change,
just in case it all looked too mysterious, et cetera, et cetera.
So hopefully you found that useful and speak to you next time.
Okay, bye.
You've been listening to Heka Public Radio at HekaPublicRadio.org.
We are a community podcast network that releases shows every weekday Monday through Friday.
Today's show, like all our shows, was contributed by an HPR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how easy it really is.
Heka Public Radio was founded by the digital dog pound and the Infonomicon Computer Club,
and it's part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on the website
or record a follow-up episode yourself.
Unless otherwise status, today's show is released under Creative Commons,
at Tribution, ShareLite, 3.0 license.