jbrzusto / liwixi Goto Github PK

pliwixi gives the user opportunities to cleanly abort the image creation process. This option would
skip those prompts.

it appears the mount command available inside the initramfs needs different options:
Dropping into the initramfs shell and doing:

 mount -w -o flush,dirsync -t vfat /dev/mmcblk0p1 /dev/sdcard

worked.

But this is with a later version of Raspbian 8 (2017-4) than the 04-30 liwixi release is based on.
Bring full liwixi image up to date...

Also need to delete the "resume" script which with the latest initramfs-tools has the system spinning
waiting for a non-existent resume partition to load (or was that only when mount was failing?)

From B. Noort:

Is there any way to enlarge the Liwixi image, I really like the idea,
but the diskspace is limmited.
I checked the liwixi github page but couldnt find anything about it.

...

I would like install monitoring tooling, so I can be alerted if anything
goes wrong.

The file pliwixi can be modified at line 98 to increase the ratio of free space created in the image:

export IMAGE_MB=$(( `df -BM --output=used / | tail -1l | tr -d 'M'` * 5 / 4))

The fraction 5 / 4 means the image will contain enough space for the operating system plus an additional 25% free disk space. You could change that to e.g. 2 / 1 to reserve 100% additional
free space, etc. You could also just calculate the number of megabytes you want
for the entire image, and replace line 98 with

export IMAGE_MB=2150

for example, which would create an image of size 2.15 GB

Note: I think the liwixi script is broken (see #6) with the most recent raspbian distributions
that are needed for using the Pi 3B+ or Pi Zero Wireless, though. This needs some debugging.

• flush; probably; we had always mounted FAT partitions with this option on beaglebone SGs, to minimize
  data loss on unclean shutdown. Enabling this might make the FAT filesystem backing the looped-back
  extfs behave more like the real hardware that extfs is expecting, without too much additional wear (?)

• sync: too drastic; much write wear on VFAT?

• dirsync?: good for keeping structure uncorrupted?

/dev/mmcblk0p1 is now mounted on /dev/sdcard by initramfs, so to prevent double-mounting
that device, we should do the above and make a symlink

/boot -> /dev/sdcard

• fix README.md to reflect this

Goals

• something combining buildroot and a distro; want a curated set of
  packages, some unpackaged code run from onboard git repos, plus
  random hits to config and other files.

• no surprises: once blob is unpacked, space used on SD card and
  bootability should be guaranteed, so that a card taken into the
  field for swapping out, possibly without the chance to test it,
  works - right away

• ability to reset running system or SD card alone (i.e. when
  mounted in a laptop,rather than in target) to "factory" blob

• easy ability to check digests of blob, initramfs,etc. to verify
  install, integrity

• create a clone of running system (including local changes) or just
  of factory blob into archive on external storage

• one-step conversion to/from "developer" blob (which includes all
  tools); from presumably requires network access

• single card that can boot in either beaglebone or Pi?

• creation of either blob type from the other, with user->developer
  again requiring net access

Improvements

• smaller image for user to download and unpack

• track overall system setup in git + scripts, to allow reconstruction
  and validation:

  • base is existing distribution e.g. Raspbian or debian Jessie armhf

  • a text file records any changes made to:

    • on-board git repos

    • distro package removal / install / update

    • changes to any other text files in filesystem are tracked as if
      one big repo, with a separate file to track perms, ownership,
      and other attributes, using lines like: "path" USER:GROUP MODE
      [extented attributes, if necessary]

    • something similar for binaries, except just track SHA digest?

maybe-howtos

• squashfs for factory image with overlain ext4fs to track local
  changes?

• overlain ext4fs in a separate looped-back image file on vfat;
  if that image file is deleted, initramfs generates overlay
  in small ramfs.

• web interface gives user option to create another vfat image
  file as the ext4 overlay for making local changes persistent;
  this can be initialized to current contents of ramfs overlay