#811 PR merged: ebiso image size is too small if BACKUP is TSM¶
Labels: enhancement, bug
pavoldomin opened issue at 2016-03-30 21:19:¶
The patch increases the UEFI image size, if BACKUP is TSM. The reference issue: #810
I must admit I start to dislike this UEFI image size determination code
(which is my own partly).
Perhaps we should think about more scientific approach to calculate
needed size for the UEFI image?
On the other hands its just few lines of code (compared to bit more if
'more scientific approach' is in place). Any comments please?
jsmeix commented at 2016-03-31 09:27:¶
Regardless that I know basically nothing at all about
how to make an UEFI bootable ISO image
I like to suggest a general approach
how to deal with such kind of issues:
Provide a new variable in default.conf like
# The size of the UEFI boot image in KiB. # It must be big enough for initrd and kernel. # If unset or empty rear will use default/fallback values: # Usually 32000 KiB should be sufficient. # When elilo or shim is used 128000 KiB should be sufficient. # Additional space is needed when special backup restore software # is used (e.g. additional 96000 KiB when TSM is used): EFIBOOT_IMAGE_SIZE_KiB=32000
and use that in the efiboot_img_size function.
Reasoning:
As far as I understand it from https://github.com/rear/rear/issues/810#issue-144721705
Work-around, if any I have modified rear code: extended UEFI image size by experimentally determined value for this particular setup
the main problem is how to automatically determine
a correct value.
When there is no reliably working automatism,
I think it should be possible for the user to
explicitly specify something that makes it work
for his particular case - otherwise we may need
to endlessly adapt and enhance the automatism
trying to make it work for all (corner) cases until
it becomes an overcomplicated monster that
nobody can maintain any longer.
A possible enhancement request:
I wonder why the size is measured in KiB and not in MiB.
Is such fine granularity really useful?
All rear defaults have '000' at the end i.e. are measured in 1000 KiB
so that I assume using 1024*1024 Bytes as unit is more appropriate.
By the way:
I needed reverse engineering to find out that the measurement unit
of that plain "size" named variable is KiB because I found it used in
20_mount_efibootimg.sh
dd if=/dev/zero of=$TMP_DIR/efiboot.img count=$(efiboot_img_size) bs=1024
I wished variable names were more meaningful, cf.
https://github.com/rear/rear/wiki/Coding-Style
pavoldomin commented at 2016-03-31 12:41:¶
Thanks for feedback!
Frankly, I am against adding new variable to the config file (there is
too many of them already), as we can find the needed value automatically
(by counting the total size of the to-be-copied files). ReaR user should
not be forced to determine the space needed for uefi boot image I
think.
Perhaps @gozora may comment on this, as this has been discussed when he
was adding his ebiso support patch.
I absolutely agree with the variable names and units comment. Also [[
... ]] && ... does not seem to honor the style as i read it now :)
I'll change it like:
dd if=/dev/zero of=$TMP_DIR/efiboot.img count=$(efiboot_img_size_MiB) bs=1048576
gozora commented at 2016-03-31 13:01:¶
At the time I was writing ebiso, I primary focused to implement it into
ReaR with least pain possible.
So I just took existing approach for ISO creation and just extended it,
with a thought that it (if there is need) will be changed. Looks like
the time is here.
As far as I remember dd ... command was called (with some fixed size)
to create blank UEFI image and consecutively mounted. After loop mount
was settled, files were copied.
In this I agree with @pavoldomin that users should not decide about
image size, but size should be rather determined automatically before
dd command is triggered. Maybe we could add some additional
script/flow.before blank image is created to have some better guess
about final image size?
It is been a time since I was in touch with ReaR code, so I definitely
need some refreshment.to have more accurate view.
@jsmeix if you want, I can take a closer look (during weekend) to find
possible way, how to automatize this.
jsmeix commented at 2016-03-31 14:02:¶
@pavoldomin
I fully agree with you.
My above comment was made under the (wrong) assumption that "there is no reliably working automatism".
When rear "can find the needed value automatically (by counting the total size of the to-be-copied files)" it should do that and not bother the user with tasks that can be reliably automated.
jsmeix commented at 2016-03-31 14:05:¶
@gozora
I would very much appreciate it if you could have a closer look.
I am not really the right one for this issue because
"I know basically nothing at all about how to make
an UEFI bootable ISO image".
gozora commented at 2016-04-03 15:25:¶
As mentioned in issue #810, pull request #813 was created and it
should supersede this pull, request.
Hope nobody minds ...
[Export of Github issue for rear/rear.]