The .iso are in /var/tmp/backupiso
They show up in my backup menu, with 277MB and 307MB.
As Bernhard and I wrote, please look in the /var/tmp/backupiso/ dir
Bernhard and Paul,
Sorry about the delay in response. Long day here with lots going on.
Here is a 5:41 PM EST Snapshot of that directory. /var/tmp/backupiso/
Likewise, I hadn’t done anything with this directory or files after my post above, so its been sitting there untouched since I attempted the backup of the iso. As you can see, there is a previous .md5 from May and one .md5 from Jun 19th as well as a .iso, both 0 length files.
Now to remove the files from command line, and verify they are gone in the GUI.
Now they are gone from the directory backupiso…
And they also show gone from the GUI Below… Just to double check…
On the backups screen I do this… and click the button to backup and wait… 5:48 PM EST
At 5:54 PM EST I ran the ls -lach so I could see all files and their permissions, however just like before 0 byte-length.
Again back to the GUI at 5:55 PM EST to coorelate… and there is 0.00 MB listed on the only 1 ISO listed.
What do you think?
Also, here is a couple of other tidbits… I was about 50 GB low on my estimate of 500 GB… Its actually free 550 GB, even with as hard as I am pushing this device.
and top…
and lscpu so I can show you guys in pre-thought that the cpu’s are there as well.
Plenty of RAM Available and 0 SWAP used, along with .3% cpu usage. I am not even touching this system resource wise. Thought I might share this with you so you can understand its not a resource issue.
Eric, thanks for the screenshots, it seems building the iso fails …
I updated to 145 just now and created a fresh iso
-rw-r–r-- 1 root root 286M Jun 19 15:23 ipfire-2.25.x86_64-full-core145-2020-06-19-15:23.iso
dmesg -T | grep Joliet should output 3-4 lines like:
[Fri Jun 19 15:23:13 2020] ISO 9660 Extensions: Microsoft Joliet Level 3
another thing is that you generate .md5 files which I don’t.
there is a script that does everything, /usr/local/bin/backupiso, it generates md5 and if it fails, it will echo this else it does everything with the --quiet flag.
There must be a conflict with other processes running … I hope the devs chime in to help …
Tried making backup ISO from core146 testing, for i586 and also got zero length files in /var/tmp/backupiso/
Whether or not an ISO would be useful in my sitution is uncertain, because I run from dotIMG installed on USB device.
Just run the script ‘/usr/local/bin/backupctrl iso’ from a shell.
Thus some errormessages killed by the cgi should show up.
As far as I can see from the sources, the presence of the md5 files means an error in md5 sum.
Hey Paul…
At what point should I run dmesg -T | grep Joliet and which directory?
OR are you saying that I should start a backup in the GUI and fire off that command to see if the line items show up for the ISO
Can you elaborate?
Here is my output from the script. I am not sure what it is eluding to about mismatch on md5. Doesn’t it generate an md5 locally? In any event, maybe you can help me determine the malfunction.
the dmesg command can be run after the creation of the iso – in your case, the iso is not created.
(it would print ISO 9660 Extensions: …) I tested the script as well, do not get the errors you do.
Fetching https://downloads.ipfire.org/releases/ipfire-2.x/2.25-core145/ipfire-2.25.x86_64-full-core145.iso.md5
Checking md5 of ipfire-2.25.x86_64-full-core145.iso
md5 is OK
Remastering iso
mount: /dev/loop0 is write-protected, mounting read-only
Running mkisofs
I: -input-charset not specified, using utf-8 (detected in locale settings)
Size of boot image is 4 sectors -> No emulation
Size of boot image is 2880 sectors -> No emulation
3.52% done, estimate finish Sat Jun 20 07:30:57 2020
7.02% done, estimate finish Sat Jun 20 07:31:11 2020
…
98.17% done, estimate finish Sat Jun 20 07:30:59 2020
Total translation table size: 2048
Total rockridge attributes bytes: 7775
Total directory bytes: 18432
Path table size(bytes): 74
Max brk space used 1c000
142617 extents written (278 MB)
Cleaning up
Case and point… hmmm…
I almost feel like the iso download from the URL included in the output is getting blocked somehow. I will look.
Ok.
Thanks for the hint. 
backupiso does only load the IPFire ISO, if there is no file ipfire-2.25.x86_64-full-core145.iso !
Your file seems to be defective ( size 0, e.g. ).
Just delete it and try again.
EDIT: didn’t read carefully. Sorry.
The problem seems to be the md5 file.
This should exist after the error. What is its contents?
Here is a copy of that backupiso script…
[root@ipfire bin]# cat backupiso
#!/bin/sh
FIXME: edit this lines before release
IPFVER=2.25
COREVER=$(cat /opt/pakfire/db/core/mine)
arch=$(uname -m)
case “${arch}” in
aarch64|x86_64)
;;
i?86)
arch=“i586”
;;
*)
echo “Arch is not supported” >&2
exit 1
;;
esac
URL=“https://downloads.ipfire.org/releases/ipfire-2.x/$IPFVER-core$COREVER/”
ISO=“ipfire-$IPFVER.$arch-full-core$COREVER.iso”
makeiso() {
local dir="${1}"
local output="${2}"
local args=
# Add EFI options when EFI image is present
if [ -e "${dir}/boot/isolinux/efiboot.img" ]; then
args="${args} -eltorito-alt-boot -e boot/isolinux/efiboot.img -no-emul-boot"
fi
# Compose ISO
mkisofs -J -r -V "IPFire ${IPFVER} ${arch}" \
-b boot/isolinux/isolinux.bin -no-emul-boot -boot-load-size 4 -boot-info-table \
-c boot/isolinux/boot.catalog \
${args} ${dir} > ${output}
# Add DOS paritition table
if [ -e "${dir}/boot/isolinux/efiboot.img" ]; then
isohybrid --uefi ${output}
else
isohybrid ${output}
fi
return 0
}
if [ -z $1 ]; then
echo usage: $0 backup-file
exit
fi
TS=$1
mkdir -p /var/tmp/backupiso
cd /var/tmp/backupiso
if [ ! -f ${ISO} ]
then
echo “Fetching ${URL}${ISO}”
wget --quiet -c ${URL}${ISO}
fi
echo “Fetching ${URL}${ISO}.md5”
wget --quiet -O ${ISO}.md5 ${URL}${ISO}.md5
echo “Checking md5 of ${ISO}”
md5sum --status -c ${ISO}.md5
if [ $? -eq 0 ] || [ $? -eq 24 ]
then
echo “md5 is OK”
else
echo “md5 mismatch”
echo “Fetching again ${URL}${ISO}”
wget --quiet -O ${ISO} ${URL}${ISO}
echo “Checking again md5 of ${ISO}”
md5sum --status -c ${ISO}.md5
if [ $? -eq 0 ] || [ $? -eq 24 ]
then
echo “md5 is OK”
else
echo “md5 mismatch”
echo “aborting backup because md5 mismatch”
exit 1
fi
fi
rm ${ISO}.md5
echo “Remastering iso”
mkdir -p backupiso.tmp.${TS}
mount -o loop ${ISO} backupiso.tmp.${TS}
cp -pr backupiso.tmp.${TS} backupiso.${TS}
umount backupiso.tmp.${TS}
rm -r backupiso.tmp.${TS}
Copy backup file to disk
cp “/var/ipfire/backup/${TS}.ipf” “backupiso.${TS}/backup.ipf”
Add a version tag
touch “backupiso.${TS}/backup-${TS}.media”
echo “Running mkisofs”
makeiso backupiso.${TS} $(basename ${ISO} .iso)-${TS}.iso
echo “Cleaning up”
rm -rf backupiso.${TS}
Eric
clean up the /var/tmp/backupiso/ dir and run a backup.
Monitor that dir, it should have 2 files (watch ls /var/tmp/backupiso/
The iso file keeps growing until it stops.
ctrl-c to get out of watch
I had a blip in my reverse dns, that I just fixed, now can reach out to downloads.ipfire.org, but for some reason still getting 0 Byte-length files and the sort.
But I did figure something out… I tried to manually wget that .md5 file in your output, and my current one. I just upgraded to core146 for the heck of it.
Check this crap out… Someone changed something on the server side at the domain. obviously they didn’t intentionally screw it up, but somehow on their webserver or proxy they have downloads.ipfire.org being temporarily redirected with a 302 to www.ipfire.org which ends in a 404 error.
[root@ipfire tmp]# wget https://downloads.ipfire.org/releases/ipfire-2.x/2.25-core146/ipfire-2.25.x86_64-full-core146.iso
–2020-06-20 13:38:12-- https://downloads.ipfire.org/releases/ipfire-2.x/2.25-core146/ipfire-2.25.x86_64-full-core146.iso
Resolving downloads.ipfire.org… 81.3.27.38
Connecting to downloads.ipfire.org|81.3.27.38|:443… connected.
HTTP request sent, awaiting response… 302 Found
Location: https://www.ipfire.org/error/404 [following]
–2020-06-20 13:38:13-- https://www.ipfire.org/error/404
Resolving www.ipfire.org… 81.3.27.38
Connecting to www.ipfire.org|81.3.27.38|:443… connected.
HTTP request sent, awaiting response… 404 Not Found
2020-06-20 13:38:13 ERROR 404: Not Found.
To check from browser, I said hmm, let me go look and tried the below.
IN Chrome, I typed in:
https://downloads.ipfire.org/
Hit Enter and it landed me here.
When you click download you will find downloads for
IPFire 2.25 - Core Update 145
but, I am upgraded to stable release 146 now… lol
Soo… if you goto https://www.ipfire.org/download/ipfire-2.25-core146
Notice I just changed the 145 to 146 in the URL… Nothing is there.
Well, hell ya’ll, I guess I am on hold doing any type of ISO backup until someone can fix this one…
but, I am upgraded to stable release 146 now… lol
Core Update 146 is not released, yet.
1 Like
Eric
Try this from a terminal … it should work.
wget https://downloads.ipfire.org/releases/ipfire-2.x/2.25-core145/ipfire-2.25.x86_64-full-core145.iso
HTTP request sent, awaiting response… 200 OK
Length: 292552704 (279M) [application/octet-stream]
Saving to: ‘ipfire-2.25.x86_64-full-core145.iso’
146 is testing so some files may not be available
Hi Paul,
I had visited this directory before, but hells bells, if its available through pakfire and not http wget in the script will never see it LOL
This is flipping strange… I am in the stable repo, refreshed, installed and rebooted… How the hell did I get a 146 dev version, out of the stable repo… ?
There is a Save button at the end of IPFire>Pakfire menu. Make sure you’re back on 145 Stable, then test my previous post. You should be able to wget any link (eg. wget https://google.com will get you the index.html file)
1 Like