Jip-Hop / sedunlocksrv-pba

Conveniently unlock your Self Encrypting Drive on startup (via HTTPS) without the need to attach monitor and keyboard
GNU General Public License v3.0
37 stars 8 forks source link

Building fails on Ubuntu 22.04 when SSH is enabled #21

Closed kennethso168 closed 5 months ago

kennethso168 commented 8 months ago

I've created an Ubuntu VM for building the image as per #20 .

System:
  Kernel: 5.15.0-100-generic x86_64 bits: 64 compiler: gcc v: 11.4.0 Console: pty pts/0
    Distro: Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Machine:
  Type: Kvm System: QEMU product: Standard PC (i440FX + PIIX, 1996) v: pc-i440fx-8.1
    serial: <superuser required>
  Mobo: N/A model: N/A serial: N/A BIOS: SeaBIOS
    v: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org date: 04/01/2014

I've tested that building with sudo SEDUTIL_FORK="ChubbyAnt" ./build.sh works.

However, when I put my authorized_keys file in the repo and ran again with sudo SEDUTIL_FORK="ChubbyAnt" ./build.sh SSH, I came across the following not enough space error:

Installation finished. No error reported.
+ cat
+ cp -r /home/kenneth/sedunlocksrv-pba/img.dnbBJX/fs/boot /home/kenneth/sedunlocksrv-pba/img.dnbBJX/img/
cp: error writing '/home/kenneth/sedunlocksrv-pba/img.dnbBJX/img/boot/corepure64.gz': No space left on device
+ cleanup

Doing the same debugging steps as in #20 (setting GRUBSIZE=25 instead of 15, adding df -h before and after the cp). I think it was only short of a little bit space (maybe around ~0.1MB):

+ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            96M 1004K   95M   2% /run
/dev/sda1       7.6G  2.7G  5.0G  35% /
tmpfs           479M     0  479M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      105M  6.1M   99M   6% /boot/efi
tmpfs            96M  4.0K   96M   1% /run/user/1000
/dev/loop3p1     50M   14M   36M  28% /home/kenneth/sedunlocksrv-pba/img.dKkLHd/img
+ cp -r /home/kenneth/sedunlocksrv-pba/img.dKkLHd/fs/boot /home/kenneth/sedunlocksrv-pba/img.dKkLHd/img/
+ df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            96M 1004K   95M   2% /run
/dev/sda1       7.6G  2.7G  5.0G  35% /
tmpfs           479M     0  479M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/sda15      105M  6.1M   99M   6% /boot/efi
tmpfs            96M  4.0K   96M   1% /run/user/1000
/dev/loop3p1     50M   40M  9.9M  81% /home/kenneth/sedunlocksrv-pba/img.dKkLHd/img
+ sync
+ umount /home/kenneth/sedunlocksrv-pba/img.dKkLHd/img

Maybe the GRUB packages recently got a little bit larger in Ubuntu? Should we increase the GRUBSIZE?

kapitainsky commented 8 months ago

I have noticed the same when testing with the latest TinyCore 15 (I will post PR bumping its version later)

I think GRUBSIZE is the same but problem is with rounding error here:

FSSIZE="$(du -m --summarize --total "${TMPDIR}/fs" | awk '$2 == "total" { printf("%.0f\n", $1); }')"

And then sometimes it results with image size being a bit too small.

All works when I add 1 to compensate for any rounding problems.

# Make the image
dd if=/dev/zero of="${OUTPUTIMG}" bs=1M count=$((FSSIZE + GRUBSIZE + 1))
kapitainsky commented 8 months ago

I am convinced that problem is FSSIZE rounding - I can add some fake file to the image and keep increasing its size with every build. All works initially but fails at some stage with FSSIZE still reporting the same value.

re GRUBSIZE I think we should not increase it - all build is clearly documented and works. In addition it is mentioned already in build.sh:

GRUBSIZE=15 # Reserve this amount of MiB on the image for GRUB (increase this number if needed)

If user decides to build using different platform it is expected that understans what is doing and can adjust build script accordingly. As maybe increasing it to 25 works for Debian 12 but is not enough for Fedora 36?

As I mentioned I am testing TinyCore 15 now and will submit PR - will also include +1 for image size.