Description of problem: Downloaded net install iso is always named "boot.iso". The page url is www.mageia.org/en/downloads/get/?q=Mageia-2-beta1-Boot-x86_64-CD.iso. I'd rather have the downloaded file be named Mageia-2-beta1-Boot-x86_64-CD.iso. Also, the iso is advertised as being only 40 MB large, which is wrong: it's only 17 MB large! Version-Release number of selected component (if applicable): Mageia-2-beta1-Boot-x86_64-CD.iso. How reproducible: always Steps to Reproduce: 1. go to http://www.mageia.org/en/2/ 2. select a net install iso 3. wait for the d/l to happen, note page url and file name... :) regards, Feth
IIUC, this "netinstall iso" which should be only for advanced users, is actually a link to the boot.iso on the cauldron mirrors, which i think has been frequently updated since. (it's also been cleaned up bigtime). This is of course just an addition of information. The size is mentioned wrongly and I also did notice that different name that you get. Though, IMHO this is a rather low priority minor bug.
CC: (none) => alien
Yup, low priority. Bug anyway. There also are plenty of advanced users with broadband connection who may prefer a netinst iso :)
Priority: Normal => Low
for the size, all are different x86_64 boot-nonfree.iso 23M boot.iso 17M i586 boot-nonfree.iso 45M boot.iso 32M
Known, thanks for the tracker. There are actually two things to consider: - reporting the right size of the ISO (that's more related to how the download index info is built and updated; this is still half automatic, half manual process); - reporting the right name/version/release/build of the ISO (because it's frequently updated).
CC: (none) => rdalvernyAssignee: mageia-webteam => rdalverny
Status: NEW => ASSIGNED
ISO size report is now automatic when we update the list of new ISOs. Reporting the right name/version/release/build (that is, naming it differently than boot.iso in the very repository) is not in my reach. This is something that should be open against the distribution itself, for packagers to consider.
Assignee: rdalverny => mageia-webteam
ok
Status: ASSIGNED => NEWVersion: trunk => CauldronCC: (none) => sysadmin-bugsComponent: www.mageia.org => Release (media or process)Assignee: mageia-webteam => bugsquadSummary: Downloaded net install iso is always named "boot.iso" => rename "boot.iso" to a better nameProduct: Websites => MageiaSource RPM: (none) => drakx-installer-binariesSeverity: minor => enhancement
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Marja, The bug was never relevant against a released distribution. Actually, it looks like the page vanished, therefore this bug has no object for the moment :-) -- Feth
Keywords: NEEDINFO => (none)CC: (none) => sander.lepik
The page is still there, but the beta download link was not working indeed; updated.
URL: http://www.mageia.org/en/downloads/get/?q=Mageia-2-beta1-Boot-x86_64-CD.iso => http://www.mageia.org/en/downloads/get/?q=Mageia-2-Boot-x86_64-CD.isoTarget Milestone: --- => Mageia 3
Thanks Romain! Then the "bug" is still valid against Cauldron!
*** Bug 7964 has been marked as a duplicate of this bug. ***
CC: (none) => jeffreybruton
CC: (none) => ennael1Summary: rename "boot.iso" to a better name => rename "boot.iso" to a better/full nameSource RPM: drakx-installer-binaries => drakx-installer-images
this is not a package issue (so i don't think it's applicable on an rpm package), but should be handled on download page really. ideally on the mirrors, it's best to be kept boot.iso, since on cauldron it updates very frequently. it would be nice if the webpages can sort of take a peek and report the size from its peeked mirror; and the full names, well, there's different ones of course :-). i586 + x86_64 + nonfree i586 + nonfree x86_64 for each mageia release... maybe product "Websites" and not mageia should be selected on this BR...
all.img or boot.iso are created with the rpm witch copy them on /install/ http://svnweb.mageia.org/packages/cauldron/drakx-installer-images/current/SPECS/drakx-installer-images.spec?view=markup#l120 >i586 + x86_64 + nonfree i586 + nonfree x86_64 for each mageia release... no it's boot.iso or boot-nonfree.iso when you download it, nothing more and download page search them in /install/
what i mean is that the mirrors should be unchanged, but the download page could make it so that if you download it via this link that it would have a different (suggested) filename when you save it to disk. so i think the webpages should be adjusted and not the repository/mirrors/boot.iso generation script that is what i mean.
AL13N: I suggest what you do: not changing build or source file name...instead changing weblink code to land file on client with proper name. Please see extensive details in bug # 7964. Thanks Jeffrey Bruton
that's exactly what i'm suggesting for webteam(which i'm not part of)... and why i think this bug is wrongly filed :-)
so change it, fix it or do whatever you want
Sorry, but the webpage naming logic is flawed... As long as the boot(-nonfree).iso is in current location, it's a changing target. So having for example the Alpha3 download page label it as Mageia 3 - alpha3 it would only be a valid name until next rebuild, after that it would not be a "clean" alpha 3 anymore. So we would need to start copying it to the /iso tree like all other isos during alpha/beta/RC to have that part match... wich brings us to the next problem... stage2 & rescue. they are also moving targets, so they will only match an alpha/beta/RC until first rebuild, after that it would be a mismatch against other isos... Of course we could start naming boot.iso, stage2 and rescue to match alpha/beta/RC, but that means altering drakx-installer-binaries too for every alpha/beta/RC so it knows what stage2 image to load... or rewrite some drakx parts to make it easier to switch naming... So... is it worth it? But yes, the boot.iso could probably be named to something like Mageia-<release>-netinstall(-nonfree)-<arch>-CD.iso where <release> would be: Cauldron/1/2/3/... and <arch> would be: arm/i586/x86_64/... That would match the other iso naming scheme better
CC: (none) => tmb
since boot.iso; and network based install etc... is only for advanced users, i see no need to have some sort of freeze for alpha3 or whatever... i would just let it move and advance. you can sort of see it as an updated version of the alfa3 :-). so i think the webpage is adequate for this sort of thing. so the naming for cauldron need not have all of this beta/alfa stuff in it imho, and your naming scheme would be adequate. of course this complicates QA on alfa/beta/rc's but maybe QA shouldn't be concentrated on that anyway... if something's not reproducable, it'll have been fixed :-) well, this is all just my personal opinion, of course
Thomas: Can you please explain why you say the current isos are a moving target? As I detail in Bug # 7964 the mirror location of the isos are: mirror.site/mageia/distrib/cauldron/i586/install/images/ or mirror.site/mageia/distrib/cauldron/x86_64/install/images To my knowledge (albeit limited) these locations are simply the current Cauldron Network Install (Alpha-#, Beta-#, RC-#, etc.) and the tree structure has been the same for M3-A1 through M3-A3...and will be the same (at least the above locations of the iso files) for Cauldron Network Install going forward...unless the build process is changed significantly. Thanks very much Jeffrey Bruton
he means that the boot.iso files themselves are often updating on cauldron, and thus can change at any time and thus the alfa3 version will not stay alfa3 but will move towards beta1 etc... until release and next cauldron arises
Yep, that's the "moving target" ... they get rebuilt for every new kernel released, and also for other changes done to any of the packages used during build and other fixes to the installer boot process. And as the stage2 they load (installer or rescue mode) also gets changed/updated between alpha/beta/rc releases, naming the iso more than "Cauldron" in development process is not really realistic... Then you have the fact that packages in Cauldron gets updated too, so the repos are not staying the same as alpha/beta/rc isos either :) But we should atleast make the naming more clear, and also include arch for those that downloads from both arches and forgets wich one is wich :)
Disclaimer: I don't have the slightest understanding of the process. I imagine the following would help provide meaningful bug reports: * a sequence number to be included in the downloaded iso name (and inside the iso, in a txt file). * a way to match this number with package versions. Perhaps you know of another way to provide the same functionality. Note that a date is an acceptable sequence number.
It's not that the Web page logic is flawed, it's that it's different than from the way the boot.iso is generated/updated today, because it takes a different view to the issue of downloading Mageia: the Web page is to provide download links to final, static images (of each build/release): they are not expected to change But, in the case of providing netinstall images too on this page, only boot.iso was available, with an identical filename in different locations: - yes, it's a moving target for Cauldron, but that's a temporary downside - in that, yes, as Thomas suggested, it would be beneficial to have a freezed copy of boot.iso and so on each Cauldron release - as it will be beneficial later to have freezed pre-installed VM images along the other ISO images). Correct me if I'm wrong, but it's not an issue on final releases (1, 2 to this day) as the files tree doesn't change anymore (but for updates)? - that's in part the reason why the advertized download size doesn't always match the actual download size; but download size is purely indicative anyway; - that's in part the reason we don't have checksums for these ISOs either; - yes, the downloaded file name doesn't match the advertised name on the Web page, but that's linked to the above again. If we could have a freezed copy under such an explicit name under iso/, that would be perfect. - no, the Web site will not provide the download client with a specific Content-Name, because: - downloads are actually dispatched to files hosted on (http, ftp) mirrors, all over the world; - rewriting on the fly the downloaded file name to the client means to control each mirror; - a temporary, imperfect solution could be to symlink from iso/ to actual files, but that won't fix the point that the linked boot.iso change over time; - making a freezed, appropriately named copy of the boot.iso on each release would fix that.
i forgot about the mirrors... well, you could proxy them... (and get those not from mirrors) you could symlink them on primary mirror for each final release and alpha/beta releases, if you want to...
or hardlink...
All: Thanks very much for the effort and considered thought on this issue. Even though this might seem like a very small issue to some, as it is now, it is not indicative of a world class distribution...which M is and will be even more as time goes on. Some of you are probably getting the idea (correctly) that I spend nearly all my testing time on Install/Upgrade. Not only is Install the first impression a new user gets, but if they can't install (or upgrade for current users) then all other issues actually running the OS or apps are rather insignificant in my mind. Further, I believe Install/Upgrade is one of the biggest (if not THE biggest) problem areas for typical users. With all that said however I'm glad in all of the software projects I've been involved with including this one, work on all the various issues happens concurrently. If we just focused on Install/Upgrade until it was right and then moved on to the next area etc., dev/release would be incredibly slow indeed. Probably my long-winded self "preaching to the choir" again. Thomas' "iso freeze" idea is definitely a step in the right direction and thanks very much for it. Just like all bug reports, it get a good discussion going and all you very smart folks thinking up ways to make things even better than they are. Thanks Jeffrey Bruton
*** Bug 12553 has been marked as a duplicate of this bug. ***
CC: (none) => bwgartner
So doing this in PHP is likely self defeating as it needs to redirect to a mirror. IMO the only way to do it would be to symlink (or hardlink) the boot.iso to the isos folder. This way we could redirect to the nice name rather than the one in the distrib tree. It might affect some mirrors if they don't carry the distrib tree (i.e. ISO only) unless we do a hardlink. Any other suggestions?
CC: (none) => mageia
Well, we could make d-i-i create the isos as: Mageia-<rel>-netinstall-<arch>.iso Mageia-<rel>-netinstall-nonfree-<arch>.iso where <rel> is either a number for stable releases, and cauldron the rest of the time.
In the mean time I guess I could modify links on DL page to use header with suggestion for a changed filename. I'll use the naming scheme as Thomas suggested in comment #30.
URL: http://www.mageia.org/en/downloads/get/?q=Mageia-2-Boot-x86_64-CD.iso => http://www.mageia.org/sl/downloads/get/?q=Mageia-5-Boot-i586-CD.iso&d=1CC: (none) => filip.komarAssignee: bugsquad => atelier-bugsTarget Milestone: Mageia 3 => Mageia 6
I also agree with the naming scheme from comment 30, looks straightforward.
Heh, I've completely forgot about this discussion... I'll do the comment #30 naming in next d-i-i build
So, I've renamed the images in drakx-installer-images-2.35 currently building, so the mirrors in cauldron will now have: all.img@ all-nonfree.img@ boot.iso@ boot-nonfree.iso@ hd_grub.img@ hd_grub-nonfree.img@ Mageia-Cauldron-all-nonfree-x86_64.img Mageia-Cauldron-all-x86_64.img Mageia-Cauldron-hd_grub-nonfree-x86_64.img Mageia-Cauldron-hd_grub-x86_64.img Mageia-Cauldron-netinstall-nonfree-x86_64.iso Mageia-Cauldron-netinstall-x86_64.iso MD5SUM MD5SUM-nonfree SHA512SUM SHA512SUM-nonfree (the "*@" files shown above are compat symlinks to not break any webpages or scripts) in stable releases like the upcoming mga6 you can expect s/Cauldron/6/ and so on...
Status: NEW => RESOLVEDResolution: (none) => FIXED
Oh, and I can drop the compat symlinks when webpages are updated
commit e40731ebeb58c3122b0cb364a3d68805b237ba15 Author: filip <filip.komar@...> Date: Sun May 22 21:04:52 2016 +0200 bugfix for mga#4876 (for now only for mga6 dev1) + iso sizes update --- Commit Link: http://gitweb.mageia.org/web/www/commit/?id=e40731ebeb58c3122b0cb364a3d68805b237ba15
Thanks for the fix Thomas. Our webpage is updated for mga6 dev1. I'm not sure if anybody is using any scripts with hardcoded filename tough. So I can't comment on dropping the symlinks. BTW I'll also take a look what can be done for older releases renaming with the php sending headers.
CC'ing documentation team, because undoubtedly some documentation needs to be adjusted (In reply to Thomas Backlund from comment #30) > Well, we could make d-i-i create the isos as: > > Mageia-<rel>-netinstall-<arch>.iso > Mageia-<rel>-netinstall-nonfree-<arch>.iso > > where <rel> is either a number for stable releases, and cauldron the rest of > the time. (In reply to Thomas Backlund from comment #34) > So, I've renamed the images in drakx-installer-images-2.35 currently > building, so the mirrors in cauldron will now have: > > all.img@ > all-nonfree.img@ > boot.iso@ > boot-nonfree.iso@ > hd_grub.img@ > hd_grub-nonfree.img@ > Mageia-Cauldron-all-nonfree-x86_64.img > Mageia-Cauldron-all-x86_64.img > Mageia-Cauldron-hd_grub-nonfree-x86_64.img > Mageia-Cauldron-hd_grub-x86_64.img > Mageia-Cauldron-netinstall-nonfree-x86_64.iso > Mageia-Cauldron-netinstall-x86_64.iso > MD5SUM > MD5SUM-nonfree > SHA512SUM > SHA512SUM-nonfree > > (the "*@" files shown above are compat symlinks to not break any webpages or > scripts) > > in stable releases like the upcoming mga6 you can expect s/Cauldron/6/ and > so on...
CC: (none) => doc-bugs, marja11
(In reply to Filip Komar from comment #37) > Thanks for the fix Thomas. Our webpage is updated for mga6 dev1. > > I'm not sure if anybody is using any scripts with hardcoded filename tough. > So I can't comment on dropping the symlinks. > > BTW I'll also take a look what can be done for older releases renaming with > the php sending headers. This is after the fact but I am giving my )-: now. Prior to the name change, except for EFI, any release of the boot.iso could be used to install any Mga(release) For EFI it had to be Mga5 or later. I could use the Mga5 boot-nonfree.iso to run an EFI Mga5 install on a system and then use the same iso to install|upgrade Mga6 (cauldron) With the name of both the iso and the image changed only a Release specific iso can be used.
Well you can still install Cauldron with the Mageia 5 netinstall ISO. It will just be using the installer that was released with Mageia 5, so the naming scheme is accurate.
(In reply to Rémi Verschelde from comment #40) > Well you can still install Cauldron with the Mageia 5 netinstall ISO. It > will just be using the installer that was released with Mageia 5, so the > naming scheme is accurate. You are partly correct naming change has no adverse affect, but I am only using the Mga5 stage1 and then changing the path to use the Cauldron stage2 installer. The reverse is true if I was using the Cauldron iso to install Mga5 or after it is released Mga6.
CC: (none) => cae
(In reply to Charles Edwards from comment #41) > (In reply to Rémi Verschelde from comment #40) > > Well you can still install Cauldron with the Mageia 5 netinstall ISO. It > > will just be using the installer that was released with Mageia 5, so the > > naming scheme is accurate. It is indeed possible, when starting boot.iso/netinstall.iso to manually adjust the path to use repositories for a different version of Mageia, and that will also cause you to use stage2 for that different version. > > You are partly correct naming change has no adverse affect, but I am only > using the > Mga5 stage1 and then changing the path to use the Cauldron stage2 installer. > The reverse is true if I was using the Cauldron iso to install Mga5 or after > it is released Mga6. Why? I don't see why, with only the name of boot.iso changed into mageia-version-netinstall-arch.iso, it suddenly wouldn't pull in stage2 from path/to/mageia's/distrib/<whichever_version>/<arch>/install/stage2/mdkinst.sqfs after you set it to use path/to/mageia's/distrib/<whichever_version>/<arch>/
(In reply to Marja van Waes from comment #42) > (In reply to Charles Edwards from comment #41) > > (In reply to Rémi Verschelde from comment #40) > > > Well you can still install Cauldron with the Mageia 5 netinstall ISO. It > > > will just be using the installer that was released with Mageia 5, so the > > > naming scheme is accurate. > > It is indeed possible, when starting boot.iso/netinstall.iso to manually > adjust the path to use repositories for a different version of Mageia, and > that will also cause you to use stage2 for that different version. > > > > > You are partly correct naming change has no adverse affect, but I am only > > using the > > Mga5 stage1 and then changing the path to use the Cauldron stage2 installer. > > The reverse is true if I was using the Cauldron iso to install Mga5 or after > > it is released Mga6. > > Why? I don't see why, with only the name of boot.iso changed into > mageia-version-netinstall-arch.iso, it suddenly wouldn't pull in stage2 from > > path/to/mageia's/distrib/<whichever_version>/<arch>/install/stage2/mdkinst. > sqfs > > after you set it to use > > path/to/mageia's/distrib/<whichever_version>/<arch>/ I agree. You may have misunderstood what I thought I was saying. I can still use the iso Stage1 from Mga(X), change the path to use Stage2 from Mga(Y) and install Mga(Y).
(In reply to Filip Komar from comment #37) > BTW I'll also take a look what can be done for older releases renaming with > the php sending headers. After some work I give it more thought. It's not worth the effort especially on last third of a support cycle of mga5. There are many higher priorities for the main web site anyway.
If you want consistency I can duplicate the isos in mga5 release tree so there would be: Mageia-5-all-nonfree-x86_64.img Mageia-5-all-x86_64.img Mageia-5-hd_grub-nonfree-x86_64.img Mageia-5-hd_grub-x86_64.img Mageia-5-netinstall-nonfree-x86_64.iso Mageia-5-netinstall-x86_64.iso
That would be great Thomas.