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 17:16:33 +0200 Message-ID: <8ae22fc0-b093-3035-4d5d-d29e7479ee7b@ipfire.org> In-Reply-To: <3ac7370b-95a3-370d-86eb-876482155d4e@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5609285258861614844==" List-Id: --===============5609285258861614844== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Adolf, comments below... On 17.09.2022 17:06, Adolf Belka wrote: > Hi Matthias, >=20 > On 17/09/2022 15:12, Matthias Fischer wrote: >> Hi, >>=20 >> comments below... ;-) >>=20 >> On 17.09.2022 13:29, Adolf Belka wrote: >>> Hi Matthias, >>> >>> On 17/09/2022 13:00, Matthias Fischer wrote: >>>> Hi, >>>> >>>> please find my comments below... ;-) >>>> >>>> On 17.09.2022 12:22, Adolf Belka wrote: >>>>> Hi Matthias, >>>>> >>>>> On 17/09/2022 11:28, Matthias Fischer wrote: >>>>>> Hi, >>>>>> >>>>>> Confirmed. Somehow the name of the ISO has changed. >>>>>> >>>>>> 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 >>>>> original iso from the IPFire download site and it looks in that download >>>>> site for an iso named ISO=3D"ipfire-$IPFVER.$arch-full-core$COREVER.iso" >>>>> which is fine for CU169 and earlier but CU170 has had the arch portion >>>>> moved to a different location in the filename. >>>>> >>>>> Either the new filename structure for the IPFire CU170 download has been >>>>> changed accidentally or it has been done deliberately but forgotten to >>>>> change the template in backup.pl etc. >>>>> >>>>>> >>>>>> Current is: >>>>>> ... >>>>>> ISO=3D"ipfire-$IPFVER.$arch-full-core$COREVER.iso" >>>>>> ... >>>>>> >>>>>> 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 >>>>> 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.2= 7-core170-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 >>> $(ISO) has not been changed in backup.pl or backup.iso. It is still >>> looking for a file named ipfire-$IPFVER.$arch-full-core$COREVER.iso >>> which for CU170 would be >>> >>> ipfire-2.27.x86_64-full-core170.iso >>> >>> but on the CU170 download site the file is actually named >>> >>> ipfire-2.27-core170-x86_64.iso >>> so the word full is missing and the arch (x86_64 or aarch64) has moved >>> to just before the .iso part. So wget will not find the file because the >>> name on the download site will have changed. >>=20 >> Exactly. >>=20 >>> I am not sure I am understanding the point you are making. Maybe I am >>> confusing what you are saying. >>=20 >> No problem, we'll sort this out... ;-) >>=20 >>> My understanding is that the name of the download file on the IPFire >>> server has changed... >>=20 >> Exactly. "Something" was changed during ISO-creation. On my devels the >> final Core170-ISOs got new names, too. But why!? >>=20 >>> and nothing has changed in backup.pl/backup.iso but >>> my understanding is that you think something has changed in backup.iso >>> and that is the cause of the problem. >>=20 >> No. >>=20 >>> Am I misunderstanding you? >>=20 >> Perhaps. A bit...;-) > I was misunderstanding you. We were actually saying the same thing. >=20 > I also missed that you were saying the build ISO name had changed. I went a= nd had a look at my recent build and found exactly what you said. :-) > I had a look through make.sh and eventually figured out that it was the cdr= om package that was modified by Michael to make the iso and image filenames m= ore aligned. Oh my. I never thought of searching there. I must have overlooked this commit somehow. > https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3Dfbd0608c2cb5372ff= f7857065ec7e605b1bf9cf7 >=20 > So the change was deliberately done but backup.pl etc was missed. Yep. > Thanks for your help in figuring it out. No problem. Had fun... ;-) > I will create a patch to fix backup for CU171. IMHO patching 'backup.iso' could perhaps be the easiest way. YMMV. Best, Matthias > Regards, > Adolf. >>=20 >> What I mean: *nothing* has changed in 'backup.iso' but *needs* to be >> changed so the download works again. Could be the easiest way. >>=20 >> OR: change the ISO naming conventions - read: the way the ISO are named. >> But where is this done!? >>=20 >> What I didn't find yet: what process or code line(s) is(are) responsible >> for the new names. And I just can't find anything responsible in >> 'backup.pl'. Perhaps some args have changed. But where!? >>=20 >> Best, >> Matthias >>=20 >>> >>> Regards, >>> >>> Adolf. >>>> ... >>>> >>>> Or do I miss something? [(Brett vorm Kopf!?)] >>>> >>>> Best, >>>> Matthias >>>> >>>>> Regards, >>>>> Adolf. >>>>>> ... >>>>>> >>>>>> I haven't searched for other occurences yet, but I think that could be >>>>>> the culprit... >>>>>> >>>>>> jm2c >>>>>> >>>>>> Matthias >>>>>> >>>>>> 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 a= n iso backup and it only showed a 0 byte file. >>>>>>>> >>>>>>>> >>>>>>>> I have confirmed with my vm testbed. The same thing works fine for C= U169. >>>>>>>> >>>>>>>> >>>>>>>> After looking through code I have found that Core Update 169=C2=A0 a= nd 170 file name order is different. The arch is placed in a different locati= on >>>>>>>> >>>>>>>> >>>>>>>> https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core169/ipfire= -2.27.x86_64-full-core169.iso >>>>>>>> >>>>>>>> https://downloads.ipfire.org/releases/ipfire-2.x/2.27-core170/ipfire= -2.27-core170-x86_64.iso >>>>>>>> >>>>>>>> This means that backup.pl is not able to find the Core Update 170 is= o from the downloads site. >>>>>>>> >>>>>>> If the change in iso file naming convention was intended then backup.= pl also needs to be modified for the iso naming convention. >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Adolf. >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Adolf. >>=20 --===============5609285258861614844==--