Federa Server Edition armhfp installation iso issue

[Peter Boy]

There is a bug against the Federa Server Edition armhfp installation iso

see https://bugzilla.redhat.com/show_bug.cgi?id=1963007

The F35 build exceeds the current max size of 700 mb (by about 20 mb)

There are obviously 2 options:

(a) reduce the size by removing some packages
(b) Determine a new max size

Unfortunately I’m not familiar with Fedora build process. According to my work with aarch64 server iso the arm build is a splendid materialization of the current concept of Fedora Server Edition. Therefore, I'm hesitant to remove packages. I would also have no idea which ones could be dispensable. Therefore, from a user/admin perspective, I would opt to set 750 as the new maximum size.

But I don't oversee the technical side. So I ask our technically savvy members to take up the cause. I’ll ask on the arm list, too.

Unfortunately, there is now a longer delay because I was not aware that this is a matter of the server WG and I was considered a contact. We should now try to get clarification as quickly as possible.

[Chris Murphy]

On Fri, Aug 20, 2021 at 2:16 PM Peter Boy  wrote:
> There is a bug against the Federa Server Edition armhfp installation iso
>
> see https://bugzilla.redhat.com/show_bug.cgi?id=1963007
>
> The F35 build exceeds the current max size of 700 mb (by about 20 mb)
>
> There are obviously 2 options:
>
> (a) reduce the size by removing some packages
> (b) Determine a new max size

This is the netinstall image. I'm not sure whether or why only armhfp
is busting the size limit, since all the netinstallers are pretty much
the same. But as there are no packages on the netinstall image, I
think we're looking at (b).

This might be a good topic for Monday's QA meeting, 2021-08-23 @ 15:00 UTC

--
Chris Murphy

[Matthew Miller]

On Sat, Aug 21, 2021 at 12:04:42AM -0600, Chris Murphy wrote:
> This is the netinstall image. I'm not sure whether or why only armhfp
> is busting the size limit, since all the netinstallers are pretty much
> the same. But as there are no packages on the netinstall image, I
> think we're looking at (b).

My 2¢... is anyone actually burning these to spinning media these days? And
physical flash media is at the point where < 16GB drives are cheaper than
8GB ones. So I think the primary concern is network transfer time.

[Peter Boy]

> Am 21.08.2021 um 17:52 schrieb Matthew Miller :
>
> On Sat, Aug 21, 2021 at 12:04:42AM -0600, Chris Murphy wrote:
> > This is the netinstall image. I'm not sure whether or why only armhfp
> > is busting the size limit, since all the netinstallers are pretty much
> > the same. But as there are no packages on the netinstall image, I
> > think we're looking at (b).
>
> My 2¢... is anyone actually burning these to spinning media these days? And
> physical flash media is at the point where < 16GB drives are cheaper than
> 8GB ones. So I think the primary concern is network transfer time.

At least the affordable arm-32 devices not even come with a CD drive.

But many popular arm-32 bit devices come with very limited RAM (e.g. 512 or even 256 mb) and small storage capabilities. So it nevertheless might be a good idea to keep the image as small as possible. And if Troy Dawson's hint (see my previous mail), that there might be unneeded kernel modules, is the culprit, it could be even more important when memory is scarce.

Peter

[Peter Boy]

> Am 21.08.2021 um 08:04 schrieb Chris Murphy :
>
> On Fri, Aug 20, 2021 at 2:16 PM Peter Boy  wrote:
> > There is a bug against the Federa Server Edition armhfp installation iso
> >
> > see https://bugzilla.redhat.com/show_bug.cgi?id=1963007
> >
> > The F35 build exceeds the current max size of 700 mb (by about 20 mb)
> >
> > There are obviously 2 options:
> >
> > (a) reduce the size by removing some packages
> > (b) Determine a new max size
>
> This is the netinstall image. I'm not sure whether or why only armhfp
> is busting the size limit, since all the netinstallers are pretty much
> the same. But as there are no packages on the netinstall image, I
> think we're looking at (b).

From Troy Dawson on the arm list I got the following information:
> > Am 20.08.2021 um 23:07 schrieb Troy Dawson :
> >
> > In the past, there was some large kernel modules that were not needed that were removed.
> > (the biggest module actually had a whole kernel built in it.  It was literally as big as the rest of the kernel)
> >
> > Usually it just requires taking the last build that is small enough, and compare it with the build that is bigger.
> > And then you hope that it's something obvious like a massive kernel module that snuck in.
> >
> > Troy

I think it makes sense to do the proposed audit.
> This might be a good topic for Monday's QA meeting, 2021-08-23 @ 15:00 UTC

@Chris, please could take that in your hands?

Thanks
Peter