User-Agent: Build Identifier: While i686 images have an extra set of kernel packages installed, I don't think that accounts for 400MB of size difference. Reproducible: Always
Do you mean 40MB? Right now, http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/images/boot.iso is 426MB, and http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/i386/os/images/boot.iso is 474MB. kernel-PAE plus modules is about 40MB, so that's why.
No I mean 400. With livecd-creator there was a much smaller difference, so I suspect that livemedia-creator has something to do with the change, but it could be a recent change in the base for live images or some i686 dependency difference. Index of /pub/alt/stage/24_Beta-1.2/Labs/i386/iso Icon Name Last modified Size Description[PARENTDIR] Parent Directory - [ ] Fedora-Astronomy_KDE-Live-i386-24_Beta-1.2.iso 2016-04-28 16:05 2.9G [ ] Fedora-Jam_KDE-Live-i386-24_Beta-1.2.iso 2016-04-28 15:51 2.3G [ ] Fedora-Labs-24_Beta-1.2-CHECKSUM 2016-04-28 17:32 482 [ ] Fedora-Robotics-Live-i386-24_Beta-1.2.iso 2016-04-28 15:59 2.8G [ ] Fedora-Scientific_KDE-Live-i386-24_Beta-1.2.iso 2016-04-28 16:10 3.2G Index of /pub/alt/stage/24_Beta-1.2/Labs/x86_64/iso Icon Name Last modified Size Description[PARENTDIR] Parent Directory - [ ] Fedora-Astronomy_KDE-Live-x86_64-24_Beta-1.2.iso 2016-04-28 15:41 2.4G [ ] Fedora-Jam_KDE-Live-x86_64-24_Beta-1.2.iso 2016-04-28 15:29 1.9G [ ] Fedora-Labs-24_Beta-1.2-CHECKSUM 2016-04-28 17:34 490 [ ] Fedora-Robotics-Live-x86_64-24_Beta-1.2.iso 2016-04-28 15:43 2.4G [ ] Fedora-Scientific_KDE-Live-x86_64-24_Beta-1.2.iso 2016-04-28 15:58 2.8G
Do we need the initramfs images on the live image? I don't think they are used when booting live images. Host only versions should be rebuilt during installs from a live image, but I don't know if they are. It looks like doing this would save abot 50MB on x86_64 and 100MB on i686. Actually removal would probably be done in the live base post install script. But install to hard drive would need to work even if the initramfs images are missing.
(In reply to Bruno Wolff III from comment #3) > Do we need the initramfs images on the live image? I don't think they are > used when booting live images. Host only versions should be rebuilt during > installs from a live image, but I don't know if they are. They are not needed for boot, but not having an initramfs messes up the bootloader installation in some cases. They were added to the liveimg for bug 1214441. Anyway, in the case of Fedora-Astronomy_KDE-Live x86_64 vs. i686, it looks like the same amount of space is used in the ext4 rootfs.img filesystems, but the one for i686 is an 8.3GB file while x86_64 is 7.6GB, and the squashfs.img file for i686 is similarly larger on i686. I'm not sure why that would be, though.
That explains why live images suddenly got a lot larger a while back. I work on the games spin, which is size is a significant constraint. There is probably a better long term fix than including an extra 100 MB. I'm not sure if livemedia-creator tries to shrink the ext4 filesystem, like livecd-creator used to. At one time I asked about getting rid of the ext4 file system as squashfs file systems can now have special files. I think that would cause a problem with using dd to install from live images quickly. If the ext4 file system has deleted files in it, the deleted files might not compress well.
Depending on the way lmc is run it either makes a clean filesystem and copies everything over, or runs a ext4 discard pass on it to make sure deleted blocks are really zero. The initramfs inside the squashfs is currently needed by the lmc nohost run of dracut. But there may be some way to change that. There have also been problems with xz compression and i686, we have to limit the amount of ram used so it's possible it isn't compressing as well as on x86_64.
This patch will eliminate the need for the initramfs inside the squashfs.img, saving 40M or so: https://github.com/rhinstaller/lorax/pull/119
Proposed as a Freeze Exception for 24-final by Fedora user bcl using the blocker tracking app because: Would be nice to have the live iso's 40M smaller.
Is this likely to make it into final before the freeze? Something made the image bigger again and the i686 image is over its target size and I want to know if I need to drop another game to fix things.
(I am refering to the Games spin.)
I looked at the uncompressed ext4 images and i686 is only about 100 MB larger there. I wonder if the memory size limit is causing problems. I'm going to run some test compresses to see.
I tested the compression and the x86_64 filesystem compressed a lot better with the same options on the same machine. So I suspect, that other than the ramfs image change, we aren't going to get much more out of lorax. I'll need to look at the package level and see if there is something other than needing two kernels for the i686 version bloating things.
(In reply to Bruno Wolff III from comment #9) > Is this likely to make it into final before the freeze? Something made the > image bigger again and the i686 image is over its target size and I want to > know if I need to drop another game to fix things. Only if this is accepted as a freeze exception. I'm trying to be fairly conservative with the changes at this point.
Thanks for the update. They didn't go over freeze exceptions today and might not until a blocker review meeting next week. So I'll figure I need to make another cut this week.
Discussed during the 2016-05-30 blocker review meeting: [1] Decision was made to delay a decision on classification of this bug as a blocker or freeze exception until the appropriate parties can weigh in on the benefits of a fix and the invasiveness of said fix. Bruno, Brian, what are the benefits of fixing this bug and how invasive will the fix be? [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-30/f24-blocker-review.2016-05-30-16.01.txt
Right now the advantage would be that the i386 Games spin is within about 50 megabytes of the target size of 4 GiB. And a late change may put it over size with little time to adjust. The spin will still work over that size, but it might cause problems for some people trying to download it. Though probably not many people would have a problem with that limit these days. The x86_64 image is 400MB smaller and is in no danger of going over size. I believe that is the only time sensitive call for this change. I am not in a good position to evaluate the risk. But this is something I would have rather seen go in before final freeze which is upon us now.
The associated anaconda change is: https://github.com/rhinstaller/anaconda/pull/617 which just means that the initrd will always be regenerated for btrfs not just when /boot is on btrfs. I'd call it a minimal risk patch, it has been running in rawhide for a few weeks now. The benefit is that all lmc created live iso's will be about 40M smaller because they don't need to carry the initrd on the squashfs.img, just in the iso.
+1FE, seems safe, minor improvement on space savings but I guess it helps and the work is done with some testing as well.
+1 FE
This bug was discussed at the 2016-06-06 blocker review meeting [1] and determined to be an AcceptedFreezeException only if Fedora slips this next release. This will give the appropriate time to fix this bug and to test it. We plan to do the first post-slip build with these changes, if we slip. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-06-06/f24-blocker-review.2016-06-06-16.00.txt
The difference has dropped to about 250MB even without the initramfs/lorax change. It looks like it is mostly a reduction in the size of i686 images. I don't know what caused it.
Not going to push this change to f24. It is already in rawhide.