Need to enlarge the filesystem/partition on first boot

On SD-Cards we should enlarge the filesystem / partition to take up all the space on first boot, scripts could be take from the raspberry pi. This would also help users using the qemu image sine they'd only need to resize the qcow2.

• enlarge partition
• grow filesystem
• use initramfs on the ~~armhf/~~arm8 boards

mentioned in issue Apps_Issues#34 (closed)

Don't know where to touch to do that. I will try this project locally and see if I figure out

mentioned in commit guido.gunther/image-builder@ca88d560

mentioned in commit guido.gunther/image-builder@17f36705

mentioned in issue #9 (closed)

There should be a script that runs on first boot inside the image that allows to grow the image to the entire disk. S.th. like what the rpi does:

https://github.com/asb/raspi-config/blob/master/raspi-config#L36

The rpi script is really old but helpful. I tried the fdisk steps manually but am not getting the disk to resize after a reboot. Here's what I have done:

purism@pureos:~$ lsblk      
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda    254:0    0 31.4G  0 disk 
|-vda1 254:1    0  181M  0 part /boot
`-vda2 254:2    0 31.2G  0 part /
purism@pureos:~$ sudo fdisk /dev/vda
[sudo] password for purism: 

Welcome to fdisk (util-linux 2.32).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/vda: 31.4 GiB, 33664771072 bytes, 65751506 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x888b203e

Device     Boot  Start      End  Sectors  Size Id Type
/dev/vda1  *      2048   372735   370688  181M 83 Linux
/dev/vda2       372736 65751505 65378770 31.2G 83 Linux

Command (m for help): d
Partition number (1,2, default 2): 2

Partition 2 has been deleted.

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (372736-65751505, default 372736): 
Last sector, +sectors or +size{K,M,G,T,P} (372736-65751505, default 65751505): 

Created a new partition 2 of type 'Linux' and of size 31.2 GiB.
Partition #2 contains a ext4 signature.

Do you want to remove the signature? [Y]es/[N]o: N

Command (m for help): w

The partition table has been altered.
Syncing disks.

It doesn't matter if I say "Y" or "N" to the question about removing the ext4 signature. Either way, after a reboot, the /dev/vda2 partition is still 3.1GB:

purism@pureos:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            481M     0  481M   0% /dev
tmpfs            99M  820K   99M   1% /run
/dev/vda2       3.1G  2.2G  746M  75% /
tmpfs           495M     0  495M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           495M     0  495M   0% /sys/fs/cgroup
/dev/vda1       172M   44M  116M  28% /boot
tmpfs            99M  1.3M   98M   2% /run/user/1000

What am I doing wrong to have the disk resized after a reboot?

Check Apps_Issues#34 (closed). fdisk is like parted. I think you miss resize2fs step

The rpi script works on thousands of machines, that's why it's IMHO a good source. For the qcow2 image we could resize during the build with guestfish but since that won't help for the SD cards it would be better to fix with a resize. If that's too much of a hazzle a single guestfish/virt-resize call would do the trick:

virt-resize --expand /dev/<foo> infile outfile

@albfan you are right, I was missing the resize2fs :)

@bob.ham mentioned an initiative in Debian to and there's indeed cloud-initramfs-growroot. We should look into adjusting that (if it doesn't work out of the box).

clout-initramfs-growroot works nicely. The only thing left is to do a

resize2fs /dev/vda

after an initial boot (which we could put into a systemd unit). @heather.ellsworth can you verify that it works for you too? If so we can just add it to the image.

For the nitrogen boards we need to switch to an initramfs to make that work but that's fine and a separate issue.

I haven't done anything with cloud-initramfs-growroot... but I can tell you that resize2fs /dev/vda works after doing the above fdisk steps I've listed.

@guido.gunther Do you want to add a modified version of the rpi script to the image? Or did you want to just add something simpler like just the fdisk steps + resize2fs? Do we want this to be done automatically for the user on like a first boot? Or do we want to just have a script on the image and tell users about it so they can choose to resize or not?

@heather.ellsworth you just need to install cloud-initramfs-growroot , no additional script needed. The only thing we then need to do is to run resize2fs, the hard part of reliable partition resizing can be taken from Debian.

So here's what I did on a new qcow2:

purism@pureos:~$ sudo apt-get install cloud-initramfs-growroot
purism@pureos:~$ sudo reboot
purism@pureos:~$ sudo resize2fs /dev/vda2
purism@pureos:~$ sudo reboot

Note that the resize2fs is on /dev/vda2 and not just /dev/vda (as we said in earlier comments). Also, the I'm not sure if the final reboot is even required since df -h shows that /dev/vda2 is at 31G immediately after the resize2fs.

@guido.gunther How does this sound... We can add the cloud-initramfs-growroot to the list of packages for qemu-x86_64 builds and we could just provide the resize2fs command to users via documentation. Since it's just oneline, we don't really need a script for it and can just tell folks the command to execute.

The reboot after the resize2fs is not required (we want cloud-initramfs-growroot exactly to avoid a reboot at all)

I'm fine with only documenting the resize2fs.

Ok I've included cloud-initramfs-growroot in !39 (merged) and then I can add the resize2fs to the developer docs.

changed the description

changed the description

mentioned in issue developer.puri.sm#47 (closed)

As mentioned this should go into a systemd unit that lives in librem5-base. @angus.ainslie even provided a good starting point for that: librem5-devkit-tools!1 (diffs)

changed the description

assigned to @dorota.czaplejewicz

added important label

Progress: with any version past 0.22ubuntu1 , cloud-initramfs-growroot seems to be working. The current Debian version is 0.18, bug report sent. It doesn't seem to trigger reliably, but when it did, I got:

growpart --dry-run /dev/mmcblk0 2
GROWROOT: CHANGED: partition=2 start=380928 old: size=6649856 end=7030784 new: size=59387871,end=59768799

The filesystem is not resized yet, I still have to find a way to somehow place resizing code inside initramfs.

The Debian bug was submitted and resolved.

Status update: https://source.puri.sm/dorota.czaplejewicz/librem5-devkit-tools/commits/resize_initrd

I tried to resize in the initrd, after cloud-initramfs-growroot does its thing. Ideally, growroot acts, then resizefs, and then we mount the rootfs and ride into the sunset.

Unfortunately, growroot is in the local-bottom phase, when the rootfs is mounted read only, presumably in order to check for the presence of a file indicating it's not needed. When trying to resize root, resize2fs will fail, because it's mounted and it's read-only.

I came up with a solution that unmounts and mounts it back again, but initrd's mount balks, making me think that this is too fragile.

Growroot could be moved to an earlier phase when the rootfs is not mounted at all, but I doubt it would be accepted upstream, because it's a large change. Forking another package doesn't sound fun.

Next attempt is going to be a systemd unit.

@guido.gunther : it would be cool if you could check that I didn't overlook something silly above

Unfortunately, growroot is in the local-bottom phase, when the rootfs is mounted read only, presumably in order to check for the presence of a file indicating it's not needed. When trying to resize root, resize2fs will fail, because it's mounted and it's read-only.

You can do this way after the rootfs has been mounted read write since resize2fs can do that while the filesystem is mounted. A tiny systemd unit invoking resize2fs after the rootfs is mounted is all that's needed.

Done. librem5-devkit-tools!37 (merged)

This will only work right when the cloud-initramfs-growroot copy from sid is installed. What's the best way to make it happen?

Also, what enables services by default?

removed helpwanted label

Done.

closed