You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!

Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.

If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.

Having a problem logging in? Please visit this page to clear all LQ-related cookies.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

... when my internet connection went south. At first it became very slow so I let it continue for about an hour (Sep 25-29 should have been then only updates!). Finally it stopped completely so I killed it.

Later I restarted it and the internet went down again so I killed it and went to bed.

This left my local mirror in an indeterminate state. I am guessing that rsync is smart enough to pick up where it left off, but I am less clear about how the ChangeLog.txt is used to identify the updates in the script.

So I manually edited the local ChangeLog.txt to remove the Sep 25 and 29 sections, then ran the update again. It appeares to have worked normally and completed within a few minutes (typical for my connection).

I am looking for reassurance that my local repo should be fixed by these actions before using it to update a machine.

How do seasoned Slackers recover from interrupted mirror updates? Is there anything else I should do to be sure?

if I have understood correctly how Eric's script works, after having verified if there's differences between the local and the remote ChangeLog.txt it runs an rsync in either case that will do a sync between the remote and the local folder, so you should have an up-to-date local mirror at the end, no matter if it got interrupted in a previous attempt or not.

I thought so but wanted reassurance from my betters before borking a machine.

Until now I have always been paranoid about bulk updates and did everything with installpkg/upgradepkg, one at a time. My experience using slackpkg with local mirror thus far has been flawless I want to keep that up if possible!

The answer for me is pretty easy: I don't use Eric's script, I just use a simple rsync command that does not check for changes in the Changelog.txt. This way it doesn't matter if the mirroring is interrupted, rsync is handling that just fine.

The answer for me is pretty easy: I don't use Eric's script, I just use a simple rsync command that does not check for changes in the Changelog.txt. This way it doesn't matter if the mirroring is interrupted, rsync is handling that just fine.

There is a reason why I check on changes in the ChangeLog.txt file. When you want to maintain your own local mirror and schedule a daily check for updates, it is much friendlier to the remote Internet server if you check a single file, than to blindly run rsync on the complete directory tree.
It's not just you who is downloading this stuff, you know.

Users of my mirror-slackware-current.sh script should realize that it has a help function explaining the possible parameters to the script:

Code:

$ mirror-slackware-current.sh -h
...
-f Force sync and the creation of new ISO image(s)
even if no update of the ChangeLog.txt was found.
This is how you resume after an aborted attempt.
Note: this will also create any missing local
directories needed for the mirror.
...

There is a reason why I check on changes in the ChangeLog.txt file. When you want to maintain your own local mirror and schedule a daily check for updates, it is much friendlier to the remote Internet server if you check a single file, than to blindly run rsync on the complete directory tree.
It's not just you who is downloading this stuff, you know.

I am pretty sure that the 1.376 seconds load I cause once a day isn't disturbing the mirror that much. Seeing that the mirror I use also hosts Debian, grml, Knoppix, CPAN, CentOS, Gentoo, CCC, Ubuntu, Mozilla, openSuse, XFCE, VLC and kernel mirrors I doubt that the load I generate is even noticed.

By the way, everyone who wants can use my mirror (slackeee.de::slackware) for syncing their own local mirrors, I don't mind that.

There is a reason why I check on changes in the ChangeLog.txt file. When you want to maintain your own local mirror and schedule a daily check for updates, it is much friendlier to the remote Internet server if you check a single file, than to blindly run rsync on the complete directory tree.
It's not just you who is downloading this stuff, you know.

Users of my mirror-slackware-current.sh script should realize that it has a help function explaining the possible parameters to the script:

Code:

$ mirror-slackware-current.sh -h
...
-f Force sync and the creation of new ISO image(s)
even if no update of the ChangeLog.txt was found.
This is how you resume after an aborted attempt.
Note: this will also create any missing local
directories needed for the mirror.
...

Eric

Thanks Eric.

Yes, the excellent help function is what got me going in the first place!

I always run manually so that I know that it all worked, but would not have immediately thought of the consequences of using -f in a scheduled script. Always good to hear the reasons why things work the way they do from the designer himself!