I originally installed GNU Radio on this computer when it was networked
pybombs. Since then, the computer has become air gapped (no internet
connection allowed). I need to update the install to the latest versions
UHD and GNU Radio. Two questions:
Is there a way that would allow me to use pybombs to update from a
If so, how would I create this dvd and then point pybombs to it?
Should I forget the original pybombs install and start over with a
containing all files needed to install the latest version. If so, how do
make this dvd?
depends. Many of the things that pybombs does actually consist of
calling your distro’s package manager. So if you can do that with a DVD
source, you’re set (I remember this being relatively easy on debian,
with a DVD actually being a remote just like debian’s repo servers are);
for the things you build from source: well, you can always just edit all
recipes involved and change the URLs to something locally served, I
That’s easier. Use “pybombs package”, and you get a tar.gz of your
prefix. again, this will only include things that are not installed by
using your distro’s package manager.
I’ll try the second approach. I created the target.tar.gz from a
(same OS) that is networked and fully updated. I have copied this over
the air gapped machine, but now what do I do? Just having the target
isn’t enough to update the install. How do I update from here?
Thanks for helping me through this Marcus, I appreciate it.
Another words, if I installed Doxygen on my non-air gapped computer and
used this to make the target.tar.gz then the air gapped computer must
Doxygen installed as well for the install to work?
I’m running into a problem that might be related to this, in that when I
start grc on the air gapped computer after extracting the target.tar.gz
it, it prints the welcome to gnu radio 3.7.8 message but then barfs on
line 34, in getitem
Do you know what problem this represents?
For my understanding, please help me understand this:
As far as the prefix directory is concerned, in a normal pybombs install
where the prefix is a local user directory, you are saying that the
directory is self contained and all that is needed for a working GRC,
assuming all dependencies are installed, is this correct? The build
doesn’t throw files into /usr/local directories or share directories or
other central locations?
Well, if you installed into a prefix on the air gapped computer, too,
you’d just overwrite everything in there with the contents of the
You must make absolutely sure that you bring all distro packages that
are related in any way to the software you’ll run to the same version
that you’ve got on your online PC.
To be honest, this sounds like something you should ask the people that
decide that and how you air gap your computer.
I think the only practical way to have both an immediately updateable
and yet air-gapped PC is to keep your data as cleanly archivable and
restorable as possible, and script your set up routines as far as
possible. Whenever you need an update, you then make a backup of your
work, flatten the air-gapped PC, use your scripts to set up the
environment in an up-to-date state, and then air-gap and restore your
work. Everything else is just asking for extra hours.
no solution here, but this is interesting because these kinds of
problems are one of the reasons why we’re re-working PyBOMBS. Are USB
drives allowed? I guess if so, you could fetch-all on one machine,
update a USB drive, and then have PyBOMBS read repos from that.
Of course, air-gapping becomes kind of pointless if you can install
anything from a USB drive.
well, Doxygen is not the best example, because it’s only needed to
generate documentation at build-time.
But consider this: when you set up your soon-to-be-airgapped computer,
you install python 2.7.8-15a-spam including the matching development
You do the same on your on-line machine.
After a month or so, you decide you might want to update the python
installation on your on-line computer. You do that, it’s now
2.7.9-vikings. Another month passes. You realize that “having the most
recent version of GR on the air-gapped computer” might be desirable. So
you use pybombs to update GNU Radio on your on-line PC.
The problem now is that the version of python on your air-gapped
computer (spam) doesn’t match the one that the fresh GNU Radio was
linked against. Since spam doesn’t have the same symbols as vikings,
things go wrong as soon as you try to call a python function from C++.
That might lead to confusion and ruin .
The same mechanism applies to all libraries that GNU Radio or any of the
things you build on your on-line PC. So you’d have to make absolutely
sure that the libraries installed on your on-line PC match the versions
on the air-gapped one.
Yes you’re right that we can’t use USB drives, but I should be able to
the same thing on a DVD. Can you explain the steps you would use to
the USB drive and I will do that on a DVD instead. This is the part I’m
just not sure how to do.
Similar issues here. On Fedora, you can use reposync to mirror a
to disc, transfer to DVD, then you can point yum to that when
installing/updating packages on your gapped machine. I believe you can
something similar for a git repository, burn to DVD, then point it your
when cloning and pulling. I have not tried the last part. May not be
to use pybombs then, but I have actually never used it; I keep a list of
dependencies GR needs, and just cut/paste to yum: