From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Fischer To: development@lists.ipfire.org Subject: Re: Incorrect naming convention used on the Core Update 170 download file. Date: Sat, 17 Sep 2022 13:00:27 +0200 Message-ID: <6aa8a3df-e3e2-aa42-33dd-13a548d2441f@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4509260953587452610==" List-Id: --===============4509260953587452610== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, please find my comments below... ;-) On 17.09.2022 12:22, Adolf Belka wrote: > Hi Matthias, >=20 > On 17/09/2022 11:28, Matthias Fischer wrote: >> Hi, >>=20 >> Confirmed. Somehow the name of the ISO has changed. >>=20 >> But - correct me if I'm wrong! - the naming of the ISO file takes place >> in '/usr/local/bin/backupiso': > That is correct but before that occurs the first step is to download the=20 > original iso from the IPFire download site and it looks in that download=20 > site for an iso named ISO=3D"ipfire-$IPFVER.$arch-full-core$COREVER.iso"=20 > which is fine for CU169 and earlier but CU170 has had the arch portion=20 > moved to a different location in the filename. >=20 > Either the new filename structure for the IPFire CU170 download has been=20 > changed accidentally or it has been done deliberately but forgotten to=20 > change the template in backup.pl etc. >=20 >>=20 >> Current is: >> ... >> ISO=3D"ipfire-$IPFVER.$arch-full-core$COREVER.iso" >> ... >>=20 >> IMHO it could be sufficient to change this to: >> ... >> ISO=3D"ipfire-$IPFVER-core$CORVER-$arch.iso" > Changing that would fix the problem but only if the change of the=20 > download filename on the IPFire server was changed deliberately. As I see it - ${URL} is OK, but the name of the *file to download* (the ${ISO}-variable) changed - somehow...: https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire-2.27-cor= e170-x86_64.iso And ${ISO} is exactly the variable 'wget' needs (e.g): Line 81 in 'backup.iso': ... wget --quiet -c ${URL}${ISO} ... Line 84f: ... echo "Fetching ${URL}${ISO}.b2" wget --quiet -O ${ISO}.b2 ${URL}${ISO}.b2 ... Or do I miss something? [(Brett vorm Kopf!?)] Best, Matthias > Regards, > Adolf. >> ... >>=20 >> I haven't searched for other occurences yet, but I think that could be >> the culprit... >>=20 >> jm2c >>=20 >> Matthias >>=20 >> On 16.09.2022 16:24, Adolf Belka wrote: >>> Hi All, >>> >>> On 16/09/2022 16:02, Adolf Belka wrote: >>>> Hi everyone, >>>> >>>> On the forum there have been a couple of people who tried creating an is= o backup and it only showed a 0 byte file. >>>> >>>> >>>> I have confirmed with my vm testbed. The same thing works fine for CU169. >>>> >>>> >>>> After looking through code I have found that Core Update 169=C2=A0 and 1= 70 file name order is different. The arch is placed in a different location >>>> >>>> >>>> https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core169/ipfire-2.2= 7.x86_64-full-core169.iso >>>> >>>> https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire-2.2= 7-core170-x86_64.iso >>>> >>>> This means that backup.pl is not able to find the Core Update 170 iso fr= om the downloads site. >>>> >>> If the change in iso file naming convention was intended then backup.pl a= lso needs to be modified for the iso naming convention. >>> >>> >>> Regards, >>> >>> Adolf. >>> >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>> >>=20 >=20 --===============4509260953587452610==--