Attachment 8399 Details for Bug 19323 – part of Ady's comments in #mageia-bugsquad

part of Ady's comments in #mageia-bugsquad

Ady.txt (text/plain), 1.87 KB, created by Marja Van Waes on 2016-09-10 10:04:08 CEST

(hide)

Description:

Filename:

MIME Type:

Creator: Marja Van Waes

Created: 2016-09-10 10:04:08 CEST

Size: 1.87 KB

patch

obsolete

>
>2016:09:09:17:31< Ady> hmm, in current Mageia-Cauldron-netinstall-x86_64.iso the size of efiboot.img is not a multiple of 2048 bytes. Could that be the problem?
>2016:09:09:17:34< Ady> Oh, also the headers of the efiboot.img fat image are not aligned to 2048 bytes. Wondering if this was also the case when prior builds resulted OK.
>
>2016:09:09:20:44< Ady> marja: the first most clear sign is the change in size of the efiboot.img. It used to be around 4MB, and now it is about 1MB, still FAT12. So the changes in C/H/S values (changing from using dd to using newer version of dosfstools) might have trigger some issue. The free space in older efiboot.img were much smaller than 3MB, so it doesn't seem logical to have now such a small efiboot.img. Thus, the "disk full"
>2016:09:09:20:44< Ady>  error seems correct: mcopy is not able to put all the files in such a small image.
>2016:09:09:21:01< Ady> hmm, the dd command used to create the file with "bs=1k count=$efisize", and then the way the efisize is calculated was changed, together with the command for "mkdosfs -C", in which the new efisize is the block-count. So, I am guessing the change in the resulting size of the image (too small now) comes from these changes to "make_boot_img".
>2016:09:10:08:38< marja> Ady: i did not check the code for myself, because i can't really read it
>2016:09:10:08:39< Ady> marja: I ma sure I know less than you do. Now, this is going to sound strange being here in this channel, but I do not use mageia's bug tracker. My prior comments were originated in two things: comparing efiboot.img from older iso versions, and from http://gitweb.mageia.org/software/drakx/commit/images/make_boot_img?id=ffb4ebf055de6b4cf5a4b2618717f16396837557
>
>2016:09:10:08:42< Ady> "-C" in mkdosfs expects a "block_count" value, and the resulting $efisize calculation (used then as block_count) seems to be too small for the files to be mcopy'ed.

2016:09:09:17:31< Ady> hmm, in current Mageia-Cauldron-netinstall-x86_64.iso the size of efiboot.img is not a multiple of 2048 bytes. Could that be the problem?
2016:09:09:17:34< Ady> Oh, also the headers of the efiboot.img fat image are not aligned to 2048 bytes. Wondering if this was also the case when prior builds resulted OK.

2016:09:09:20:44< Ady> marja: the first most clear sign is the change in size of the efiboot.img. It used to be around 4MB, and now it is about 1MB, still FAT12. So the changes in C/H/S values (changing from using dd to using newer version of dosfstools) might have trigger some issue. The free space in older efiboot.img were much smaller than 3MB, so it doesn't seem logical to have now such a small efiboot.img. Thus, the "disk full"
2016:09:09:20:44< Ady>  error seems correct: mcopy is not able to put all the files in such a small image.
2016:09:09:21:01< Ady> hmm, the dd command used to create the file with "bs=1k count=$efisize", and then the way the efisize is calculated was changed, together with the command for "mkdosfs -C", in which the new efisize is the block-count. So, I am guessing the change in the resulting size of the image (too small now) comes from these changes to "make_boot_img".
2016:09:10:08:38< marja> Ady: i did not check the code for myself, because i can't really read it
2016:09:10:08:39< Ady> marja: I ma sure I know less than you do. Now, this is going to sound strange being here in this channel, but I do not use mageia's bug tracker. My prior comments were originated in two things: comparing efiboot.img from older iso versions, and from http://gitweb.mageia.org/software/drakx/commit/images/make_boot_img?id=ffb4ebf055de6b4cf5a4b2618717f16396837557

2016:09:10:08:42< Ady> "-C" in mkdosfs expects a "block_count" value, and the resulting $efisize calculation (used then as block_count) seems to be too small for the files to be mcopy'ed.

Actions: View

Attachments on bug 19323: 8399