Re: How to create a USB flash software repository?

On Tuesday 19 Jan 2010 06:03, while playing with a tin of spray paint,
script||die painted this mural:

Getting the whole distribution file tree is the hard part,

Not really. I maintain a local web server specifically for network
installs[0] of the various versions, all of which were retrieved using
rsync to create the local mirror.

keeping the
update tree update is harder,

A daily/weekly cron job to mirror one of the update mirrors works
perfectly for me, and has done for several years now. I think I first
started doing this with SuSE 8.0 or 8.1, not sure which one. And, once
I set it up, I've had it mirroring all the versions since 7.0.

and loading only what's in use or needed
is hardest.

That is a much harder task. You'd need to have a complete list of all
the packages installed on each machine, including any possible
architecture or release differences. Maintaining them would be a bit of
a pain so it'd probably be easier to just mirror the entire selection
of packages.

All this could be so much simpler if you could just tell
Yast here's where I want you to save all downloaded files, and here's
where I want you to read them from (always in terms of parent folders,
dynamic indexing in ram only, and selectable deltas/rpms whatever). Then
you could take that portable drive or usb to another machine and bingo.

A USB drive would be a better option if mirroring the updates is
included as there's quite often package and/or metadata changes, and
it's a good idea to minimise writes to USB memory sticks. Also, while a
USB key may (possibly) be a little faster, they aren't up to the same
capacity as a hard drive and are also a lot more expensive.

Before beginning the move Yast will export to wherever you want
(should always be this way) the packages list. You can later import this
same list as the basis for completing an initially minimal install after
the first boot on another machine (or a new install on another partition).

/etc/yzpp/repos.d is the folder I copy into the new system on the other
machine. This folder is where Yast notes the local rpm repo paths for
itself (it takes a lot of time to configure it).

Why not export them using:

zypper lr -e repos

copy the repos.repo file to the other machine and then import the repos

zypper ar -r repos


rsync -vidhut --bwlimit=10 --progress \
--exclude *debug* \
--exclude *delta* \
--exclude *patch* \
--exclude *-info* \
--exclude INDEX* \
--exclude *acroread* \
--exclude *xen* \
--exclude eclipse* \
--exclude *-i18n* \
--exclude *-html* \
--exclude *ava* \
--exclude OpenOffice* \
--exclude *devel-doc* \
--delete-excluded \
--delete-after \

You're skipping several packages there, which could cause possible
issues when doing an update, although I can understand a reason for
doing so. Purely out of curiosity, is there a reason for you skipping
the delta and patch packages?

Anyway, I have a daily cron job that mirrors the entire trees for the
various versions I'm using. The command used to do the mirroring in
that script[1] is:

rsync -avP \
--exclude rpm/ppc \
--exclude rpm/ppc64 \
--exclude deltas/* \
--exclude deltas/* \
--safe-links \
--delete-after \
--delete-excluded \
--timeout=1800 \
"${server}/${version}" \

$server is[2]:


$dest and $version are the destination root directory, and the version
being mirrored. For my own local 11.2 update mirror the full path is on
an NFS exported directory which all my machines would see as:


[0] My network is configured with a PXE boot server set up to allow
installation of all the current releases, along with a few other
network based tools, e.g. a network bootable gparted and memtest are
the main tools.

[1] My script actually reads the active mirrors, server path and server
options from a MySQL database. This makes it a lot easier to maintain
as all I need to do is set/reset a flag and a particular version is
enabled or disabled. This means there's no need for me to edit the
script to remove old versions, although new versions do require a new
entry in the table. For the curious, a copy of my script is here:

[2] the reason for $server being in the database, rather than being a
part of the script, is that originally the server paths were versioned.
Having the server path stored in the database was actually quite useful
because, when openSUSE 10.3 was released, the path was changed from the
previously used path: rsync://

David Bolt

Team Acorn: OGR-NG @ ~100Mnodes RC5-72 @ ~1Mkeys/s
openSUSE 11.0 32b | | | openSUSE 11.3M0 32b
openSUSE 11.0 64b | openSUSE 11.1 64b | openSUSE 11.2 64b |
TOS 4.02 | openSUSE 11.1 PPC | RISC OS 4.02 | RISC OS 3.11