All my configs were reset when I sysupgraded from 21.02.0-snapshot to 21.02-rc1

The size of boot partition is automatic, and there is no need to change it. You can set the size of rootfs but it will take longer time to dd.

1 Like

I forgot about an option : while building an image, you can pass custom files, and so configure settings.

1 Like

tnx a lot I'm gonna try to build my own image and test it.

About the FILES=files/ parameter, how can I pass multiple files to it?

It copies everything that is inside the directory "files/". :sunglasses:

1 Like

I mean, if I wanna set some files on a folder like /etc/config/. And how to set multiple files.

And how to set where they are placed inside the image.

This command copy every files and directories that are inside the files/ directory.

Create a directory files/
Put every files and other directories you need inside, such as etc/, etc/config/ ...
using FILES=files/ will copy everything
Beware of the path

Note: The files/ folder is best in the imagebuilder root folder ( where you issue the make command ) otherwise it is best to use an absolute ( full ) path.

1 Like

oh so what's inside files/ go inside rootfs / including folders in it?

So /etc/config/network will go files/etc/config/network?

oh so what's inside files/ go inside rootfs / including folders in it?

Yes. Very convinient isn't it ?

So /etc/config/network will go files/etc/config/network?

No
files/etc/config/network will go to /etc/config/network
:wink:

1 Like

I made the test.

I restored on a VM my backup from before the sysupgrade, then I ran sysupgrade for RC1 and partition sizes were changed back to img sizes. Oddly, config files weren't lost.

Then I restored it back, and now I created a 200GB ext4 partition on the end of the disk and left some GB free on the middle of it. After sysupgrade, partitions kernel and rootfs were back to default sizes... and the 3rd is gone!!

So, yeah, as it is now, OpenWRT doesn't allow to use the disk for anything else. Neither to increase partitions sizes or to add extra partitions to the disk.

I'm gonna study image builder to learn its features, specially if it supports changing default partitions sizes.

My guess ATM for the best solution is to create a custom image with all the packages I like and use squashfs. I know very little of it yet, it seems it leaves rootfs as readonly and has a 3rd partition where it writes any changes. So, I could add my custom long time configs and packages to the img, hopefully increase the partitions size, and leave on a 3rd partition my scripts and short time configs.

I must confess that on x64, I never use sysupgrade, and always use dd to write image : it allows a clean start. Than I use a partition manager to resize rootfs, and luci to restore the config. I know I can include the config in the image (FILES parameter), but I prefer do it manually so I can use the latest backup.

OpenWRT doesn't allow resizing rootfs because it is mounted. But you can create an extra partition.

Setting a bigger rootfs size means more time to dd it, and most of the content will be empty. It seems faster to use a small size for image, dd it, than increase the size with a partition manager. Also if you use squashfs, you can't resize the partition.
Best thing to do now is to learn the image builder. It's an interesting tool. Look for packages you don't need (ppp, nic kmod drivers ...) and add some fitting your need (vpn ...). Have fun.

1 Like

My issue with partition size is the case of adding too many packages and it becoming too small and don't fit.

It's useless to resize it, what I did, if on next upgrade this extra size is lost.

https://openwrt.org/docs/guide-user/installation/openwrt_x86 says that we can use TARGET_ROOTFS_PARTSIZE to change it. I'm gonna try to find out where it is set.

I'm gonna try image builder now to see how it works :slight_smile:

Update. Well it was pretty easy to build a custom image. It's damn easy to add all packages we need to the image, as long as they fit on the small space of course. I also copied all my configs and scripts directly to it, and once the image is installed they are all there and I just need to ln -s the scripts. Even my vm.network which I use when installed/restored on a VM is immediatelly available.

Once I have everything configured I'll hardly change anything, so it will be a set and forget and upgrade will be easy. Of course, I'll try on VM before and will have backup rdy if needed :slight_smile:

Ok, I almost did it! Here's what I did:

  1. built image for 19.07.7
  2. used dd to write openwrt-19.07.7-x86-64-combined-ext4.img on sdb
  3. booted and everything working
  4. created sdb3 with 200GB on the end of the disk, leaving some free GB on the middle
  5. built image for 21.02.0-rc1
  6. used dd to write openwrt-21.02.0-rc1-x86-64-generic-kernel.bin on sdb1 and openwrt-21.02.0-rc1-x86-64-generic-ext4-rootfs.img on sdb2

Because I wrote images to partitions and not to disk, sdb3 wasn't lost and remained available. I'm able to mount sdb2 (on Parted Magic) and all files are there.

But sdb1 failed and I lost boot. It stays on the basic shell waiting for commands, which I guess is on MBR special area. I'm unable to mount sdb1.

It looks that kernel.bin isn't a image file and isn't meant to be written on a partition. So, what to do with it? And what to do on the boot partition when we use ext4-rootfs.img?

I also noticed that 19.07.7 uses GRUB2 1.02 and 21.02.0 uses 1.04, so it's not only the kernel that needs to be upgraded.

If I find out how to write the boot partition, then it will be solved!

Building a custom image is indeed easy. How much diskspace do you need for your packages ?
Some tips:

  • include kmod-ata-ahci for disk access.
  • tools to handle, mount partitions (see using storage page)
  • include CPU microcode (intel or AMD) for updating
  • remove unnecessary nic drivers

kernel.bin is obviously not an image and you can't dd it.

1 Like

Tnx a lot for the tips! :smiley: I haven't noticed there's a amd64-microcode

I noticed that 21.02 uses much more storage than 19.07, and kept the same partition size.

As I said, for now the default size is enough. ATM I'm considering use the spare 250GB on a 3rd partition. That would help in storing backups in example.

In the future I'm gonna use Yamon or some other tool to measure traffic consumption. On my EdgeRouter I had to place it on my NAS and use cifs to access it from the router. Now I wanna keep it on a nice local safe partition.

It seems it's possible to set custom rootfs size, but that requires menuconfig, which is available only for compiling the whole thing including kernel. I had tried it but am not comfortable to use it on production.

It's the only file resembling boot partition. How to build and dd it?

I have not tested to create custom sized rootfs. I need a few packages, so it always fits in the default size.
About kernel.bin ... good question ! I haven't figured out yet how to use this. If it is provided, it obviously fit a need.

1 Like

My bet ATM is to install combined-ext4 on a VM and use dd to extract boot partition. It's a lot of trouble sadly, at least it's only needed each few months.

I'm developing a monitor for IPv6 global prefix based on parsing ifstatus. After it's finished I'll build another image including some new packages then see how much free storage remains and try to extract boot partition.

I'm rly glad how OpenWRT and apps cleanly set themselves only from plain text files. That makes it very easy to hold them all on a Subversion repo and sync them with rsync. This also allows to easily store them all on an image.

I was exactly reading about if we can update a package like openvpn.. and saw few min ago the new version. As written in wiki : for a vm it's a fresh install. no upgrade or anything. very easy, you install fresh and do snapshoot . no upgrade needed.

1 Like

It worked! Sorry for the long delay, here's what I did:

Extracing boot partition:

  1. installed openwrt-21.02.0-rc1-x86-64-generic-ext4-combined.img.gz in a clean never used drive, custom image with original size partitions
  2. used dd to extract sdb1 to openwrt-21.02.0-rc1-x86-64-generic-ext4-boot.img

Then, to test if this image works:

  1. installed openwrt-19.07.7-x86-64-combined-ext4.img.gz custom image
  2. resized boot and rootfs partitions using gparted to 512MB and 10GB
  3. created a 240GB at the end of drive leaving 6,5GB free before it
  4. installed openwrt-21.02.0-rc1-x86-64-generic-ext4-rootfs.img.gz into sdb2, custom image with original partitions size: OpenWRT 21.02 booted even with kernel 4.x
  5. installed openwrt-21.02.0-rc1-x86-64-generic-ext4-boot.img into sdb1: OpenWRT failed to boot unable to mount rootfs
  6. booted Parted Magic, mounted sdb1 and fixed grub.cfg with root=/dev/sdb2 (very sadly /dev/disk/by-label/ doesn't work, so we gotta make sure that sdX must always be the same letter, I'm also unable to find correct partuuid)
  7. OpenWRT boots with kernel 5.4.111
  8. GParted and fdisk both report partitions with sizes 512MB and 10GB, I haven't tested filling them but they mount without errors on OpenWRT and Parted Magic

I also followed How to set root filesystem partition size on x86 ImabeBuilder? - #6 by Hikari where @jow teaches how to build image with custom partitions sizes. But at some point it seems to store the whole image on RAM, so we need enough RAM for the size we want on them. I was alrdy using 10GB and this frustrated me, so I just gave up again and continued with images I had before with original sizes.

Surprisingly, after dding both partitions separately, having images on default sizes and partitions resized, resulted partitions remained with bigger sizes. I didn't even have to resize them back. I guess that partitions sizes are stored on MBR, then since MBR wasn't rewritten, their size didn't change and sdb3 also wasn't lost. GRUB also remained on 19.07's v2.02, so it wasn't updated.

The more important anyway is to be able to have the 3rd partition where data, logs, backups and Yamon are stored, and be able to install new releases without losing it. And that worked! Of course, to do it on production we must backup the whole disk and partitions and test the upgrade on VM.

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.