# Resizing kernel images for Edgerouter X **URL:** \ **Category:** For Developers\ **Created:** [April 16, 2024, 9:02am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968 "2024-04-16T09:02:16Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [April 16, 2024, 9:02am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/1 "2024-04-16T09:02:17Z")
I noticed builds for Edgerouter X have been disabled in [commit](https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=362f9c41a4690964a77afef5216f6e23bc265611) due to 3MB kernel size limits with the OEM layout. I thought I would take a look at resolving this issue so this device can continue to work with newer kenels. However wondering if anyone has any hints on the best way forward to resize the partitions. Can't simply resize in dts as some other device have done recently, since the kernel partitions are consecutive here. I guess that leaves a couple of options - Convert layout to a single kernel allowing 6MB and disable the code that sets kernel flag on flash upgrades. - Resize both kernel partitions and move ubi start offset, subsequently override load addresses within uboot. Any hints on the best option would be appreciate or let me know if there is a better way. I do have some experience working with uboot, but never anything as ancient as the uboot Ubuitiy choose! OEM layout ```plaintext root@OpenWrt:/proc# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00020000 "u-boot" mtd1: 00060000 00020000 "u-boot-env" mtd2: 00060000 00020000 "factory" mtd3: 00300000 00020000 "kernel1" mtd4: 00300000 00020000 "kernel2" mtd5: 0f7c0000 00020000 "ubi" root@OpenWrt:/proc# ubinfo -a UBI version: 1 Count of UBI devices: 1 UBI control device major/minor: 10:127 Present UBI devices: ubi0 ubi0 Volumes count: 2 Logical eraseblock size: 126976 bytes, 124.0 KiB Total amount of logical eraseblocks: 1972 (250396672 bytes, 238.7 MiB) Amount of available logical eraseblocks: 0 (0 bytes) Maximum count of volumes 128 Count of bad physical eraseblocks: 10 Count of reserved physical eraseblocks: 30 Current maximum erase counter value: 3 Minimum input/output unit size: 2048 bytes Character device major/minor: 250:0 Present volumes: 0, 1 Volume ID: 0 (on ubi0) Type: dynamic Alignment: 1 Size: 22 LEBs (2793472 bytes, 2.6 MiB) State: OK Name: rootfs Character device major/minor: 250:1 ----------------------------------- Volume ID: 1 (on ubi0) Type: dynamic Alignment: 1 Size: 1916 LEBs (243286016 bytes, 232.0 MiB) State: OK Name: rootfs_data Character device major/minor: 250:2 ``` uboot env, although this seems to be for recovery, so I guess uboot is configured dynamically via the menu system. ```plaintext oot@OpenWrt:/proc# fw_printenv bootcmd=tftp bootdelay=1 baudrate=57600 stdin=serial stdout=serial stderr=serial ethaddr=ac:8b:a9:a4:45:42 bootargs=console=ttyS1,57600n8 ubi.mtd=7 root=ubi0_0 rootfstype=ubifs rootsqimg=squashfs.img rootsqwdir=w rw model=e50 BootType=3 filesize=44ee27 fileaddr=80A00000 ipaddr=172.16.3.211 serverip=172.16.3.210 autostart=no bootfile=vme50 ``` ---
**Author:** ![sandberg](https://forum.openwrt.org/letter_avatar/sandberg/32/5_5575768a8748004e209b776fc1b2916d.png) [@sandberg](https://forum.openwrt.org/u/sandberg)\ **Post date:** [April 16, 2024, 7:21pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/2 "2024-04-16T19:21:01Z")
> [@darkxst](#): > > Convert layout to a single kernel allowing 6MB and disable the code that sets kernel flag on flash upgrades. This seems like the most obvious thing. > [@darkxst](#): > > Resize both kernel partitions and move ubi start offset, subsequently override load addresses within uboot. The addresses for `kernel1` and `kernel2` are not being kept in the u-boot env variables. I do not see an obvious way to change them. Then there is the problem of flashing this bigger image to existing 3MiB slot. I am not sure but I assume that `dd` in nand.sh respects the size limit of existing mtd partitions. So how do we upgrade from smaller kernel slots to combined one? One way is to boot using an initramfs image. Another option is via kernel v6.1 snapshop image, which seems to fit in 3MiB still, but then all device owners would have to be really alert to update when main is still in 6.1. Moreover, thanks to kernel slot toggling, you'd have to booted using `kernel2` in order to get new image to flash in `kernel1`. Tricky. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [April 17, 2024, 12:48am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/3 "2024-04-17T00:48:07Z")
> [@sandberg](#): > > The addresses for `kernel1` and `kernel2` are not being kept in the u-boot env variables. I do not see an obvious way to change them. yeh I suspect they are being set dynamically in the boot script > [@sandberg](#): > > I am not sure but I assume that `dd` in nand.sh respects the size limit of existing mtd partitions. I dont think this is the case, some other boards resize kernel just by moving the rootfs start address in dts, so that the kernel itself can overrun the kernel mtd slot. Also in nand.sh, kernel length seems to defined based on file size not mtd size. > [@sandberg](#): > > Moreover, thanks to kernel slot toggling, you'd have to booted using `kernel2` in order to get new image to flash in `kernel1`. Kernel toggling is handled in custom implementation specific to edgerouter (X and X-sfp), seems easy enough to override this to always flash to kernel1. However I presume there must be some failover logic in uboot also that flips the kernel to point after boot failures? ---
**Author:** ![sandberg](https://forum.openwrt.org/letter_avatar/sandberg/32/5_5575768a8748004e209b776fc1b2916d.png) [@sandberg](https://forum.openwrt.org/u/sandberg)\ **Post date:** [April 17, 2024, 4:29am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/4 "2024-04-17T04:29:37Z")
I was thinking about the case that how does the existing sysupgrade in branches 22.x and 23.x handle the new image with updated DTS. They are aware of two slots only and will install the new kernel+dtb accordingly in one of them. For the next boot it would have to boot from where kernel1 was, right? Yes, no? I am thinking about using the DEVICE\_COMPAT\_VERSION and lay out the way for combined kernel slot while main is still in 6.1. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [April 17, 2024, 5:10am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/5 "2024-04-17T05:10:05Z")
So as a first attempt, I made the following changes to Edgerouter X build: - patch dts to make `kernel1` 6MB and drop `kernel2` - patch `mt7621.mk` to set kernel size to 6MB - patch `ubnt.sh` to always flash to `kernel1` (and update kernel index flag to match) Then using serial console - select \<1\> from uboot menu - tftpboot the new initramfs - sysupgrade to the new sysupgrade.bin The system rebooted successfully into new build from flash with kernel 6.1 (size ~3.8MB) and new layout: ```plaintext root@OpenWrt:/# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00020000 "u-boot" mtd1: 00060000 00020000 "u-boot-env" mtd2: 00060000 00020000 "factory" mtd3: 00600000 00020000 "kernel1" mtd4: 0f7c0000 00020000 "ubi" ``` Obviously all this is dependent on having a serial console. Not sure that flashing factory file from OEM OS would work, given its now over 3MB? and how would select correct kernel slot in the case. Perhaps it might be possible to do a direct upgrade to the new layout from existing openwrt install, by overwriting `ubnt.sh` before sysupgrade? ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [April 17, 2024, 5:31am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/6 "2024-04-17T05:31:09Z")
> [@sandberg](#): > > I was thinking about the case that how does the existing sysupgrade in branches 22.x and 23.x handle the new image with updated DTS. They are aware of two slots only and will install the new kernel+dtb accordingly in one of them. For the next boot it would have to boot from where kernel1 was, right? Yes, no? maybe replacing [ubnt.sh](https://github.com/darkxst/openwrt/commit/a2dae0903ed0fd1a2b33c3ca555102a1deecbd60) on the live filesystem before running sysupgrade might work? that way can force the new kernel to flash into kernel1 slot and ensure this slot is active. I will roll back to 23.05 and see if that works. EDIT: The above does work, by updating `./lib/upgrade/ubnt.sh` prior to sysupgrade from 23.05 and reboots into new layout. > [@sandberg](#): > > I am thinking about using the DEVICE\_COMPAT\_VERSION and lay out the way for combined kernel slot while main is still in 6.1. Is the use of COMPAT\_VERSION to force the new layout? ---
**Author:** ![sandberg](https://forum.openwrt.org/letter_avatar/sandberg/32/5_5575768a8748004e209b776fc1b2916d.png) [@sandberg](https://forum.openwrt.org/u/sandberg)\ **Post date:** [April 17, 2024, 3:19pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/7 "2024-04-17T15:19:33Z")
> [@darkxst](#): > > maybe replacing [ubnt.sh](https://github.com/darkxst/openwrt/commit/a2dae0903ed0fd1a2b33c3ca555102a1deecbd60) on the live filesystem before running sysupgrade might work? that way can force the new kernel to flash into kernel1 slot and ensure this slot is active. I will roll back to 23.05 and see if that works. > > EDIT: The above does work, by updating `./lib/upgrade/ubnt.sh` prior to sysupgrade from 23.05 and reboots into new layout. Ok good. I may have been too hasty in thinking it must land on kernel1. U-boot is not aware of mtd partitions and just loads what it finds at given address, right? Suppose we introduce a patch where we update DTS to join slots `kernel1` and `kernel2` and we also modify ubnt.sh to always use kernel1 slot. Should this kernel+dtb land on `kernel2`, u-boot would load it as normal and proceed without problems. Then we would have a situation where kernel is being loaded from middle of mtd3 and we'd have the updated ubnt.sh in place. A subsequent sysupgrade would drop the new kernel in place of `kernel1` and allow 6MiB kernel size from there onwards. (Also, I think we can go back and forth between releases as rolling back from 24.x to 23.x or earlier should not be a problem. It'll just land on kernel1 and then it would start toggling again. Is my logic sound enough? Dunno if we need any COMPAT\_VERSION.) Edit: on a second thought, I am inclined to think that we'll have to introduce the new DTS and ubnt.sh also in 22.x and 23.x so that they'll be able to update a kernel that's bigger than 3MiB, which will be the situation in 24.x. And for that we'll might need COMPAT\_VERSION message telling users to update latest of 22.x or 23.x first. How does it sound now? ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [April 18, 2024, 12:15am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/8 "2024-04-18T00:15:44Z")
> [@sandberg](#): > > U-boot is not aware of mtd partitions and just loads what it finds at given address, right? U-boot selects kernel parition to boot based on flag stored in factory mtd. ```plaintext MT7621 # ubntw dump Reading NAND flash factory partition 0x000E0000 size 393216 UBNT BD type=e50, mac=AC8BA9A44542, s/n=AC8BA9A44542, mrev=22, k_idx=1 ``` The patched ubnt.sh always sets the flag to boot kernel1 > [@sandberg](#): > > Should this kernel+dtb land on `kernel2`, u-boot would load it as normal and proceed without problems. Then we would have a situation where kernel is being loaded from middle of mtd3 and we'd have the updated ubnt.sh in place. A subsequent sysupgrade would drop the new kernel in place of `kernel1` and allow 6MiB kernel size from there onwards. With the patches applied on a existing stable release where kernel is \< 3MB this would work as you describe. 6.1 is probably already over 3MB hence why the builds have been disabled in master. > [@sandberg](#): > > (Also, I think we can go back and forth between releases as rolling back from 24.x to 23.x or earlier should not be a problem. It'll just land on kernel1 and then it would start toggling again. Yes, I can confirm that rolling back to 23.x works fine without any special steps. > [@sandberg](#): > > I am inclined to think that we'll have to introduce the new DTS and ubnt.sh also in 22.x and 23.x so that they'll be able to update a kernel that's bigger than 3MiB, which will be the situation in 24.x. Yes I think that would be best, if we can backport this to stable releases, they will get the new layout on subsequent sysupgrade with no other interaction required. EDIT: ~~not sure if we should or need to backport the DTS change to stable releases. Just having the updated `ubnt.sh` there should be enough.~~ Flashed kernel image gets truncated at 3MB if new dts is not loaded I have created a draft PR with changes for main: > > > The OEM layout on the Edgerouter X has two kernel slots that are 3MB each. Start…ing with Linux 6.1 the kernel images no longer fit into this layout. Currently the Edgerouter-X image builds are disabled due to this issue. > > This PR will convert the Edgerouter X to use a single kernel slot that is 6MB, this is achieved with the following changes: > \* Adjust dts to make \`kernel1\` 6MB and drop \`kernel2\` slot > \* Patch \`ubnt.sh\` to always flash to \`kernel1\` slot (Likewise set the flag in factory partition to make sure kernel1 slot is active) > \* Set compat version to 2.0, to ensure the system has the updated \`ubnt.sh\` providing support for the new layout. > > Ideally a subset of these changes would be backported to the 23.x and 22.x stable branches, in preparation for the larger kernels in 24.x. After this the compat message can be updated asking user to upgrade to latest 23.05.x to get the changes required for moving directly to 24.x without any further user intervention. > > I have also confirmed there is no issue downgrading back to 23.05 from this updated layout, where it will just go back to toggling kernel slots as per normal. > > OEM layout: > \`\`\` > root@OpenWrt:/proc# cat /proc/mtd > dev: size erasesize name > mtd0: 00080000 00020000 "u-boot" > mtd1: 00060000 00020000 "u-boot-env" > mtd2: 00060000 00020000 "factory" > mtd3: 00300000 00020000 "kernel1" > mtd4: 00300000 00020000 "kernel2" > mtd5: 0f7c0000 00020000 "ubi" > \`\`\` > > New layout: > \`\`\` > root@OpenWrt:/# cat /proc/mtd > dev: size erasesize name > mtd0: 00080000 00020000 "u-boot" > mtd1: 00060000 00020000 "u-boot-env" > mtd2: 00060000 00020000 "factory" > mtd3: 00600000 00020000 "kernel1" > mtd4: 0f7c0000 00020000 "ubi" > \`\`\` And a branch for backports here: > **[GitHub - darkxst/openwrt at er-x-backport-23](https://github.com/darkxst/openwrt/tree/er-x-backport-23)** > > er-x-backport-23 ---
**Author:** ![sandberg](https://forum.openwrt.org/letter_avatar/sandberg/32/5_5575768a8748004e209b776fc1b2916d.png) [@sandberg](https://forum.openwrt.org/u/sandberg)\ **Post date:** [April 19, 2024, 9:42pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/9 "2024-04-19T21:42:05Z")
Tested: OpenWrt 23.x -\> main with 6MB slot. It gave a warning as expected. OpenWrt 23.x -\> 23.x with 6MB slot landing on 'kernel2'. Works as expected. 23.x with 6MB slot -\> main (6.6) with 6MB slot. Works as expected main with 6MB slot -\> OpenWrt 23.x. Forced, but was able to downgrade. Worked as expected. ---
**Author:** ![oops](https://forum.openwrt.org/letter_avatar/oops/32/5_5575768a8748004e209b776fc1b2916d.png) [@oops](https://forum.openwrt.org/u/oops)\ **Post date:** [April 30, 2024, 7:02pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/10 "2024-04-30T19:02:54Z")
Is there any chance that what you are trying to do and the resulting OpenWrt images would be able to be used for an initilal OpenWrt install via the stock edgeOS or perhaps via the bootlader of an Edgerouter X? Currently, as far as I can tell, it is still necessary to use a special, customized, years old, unofficial OpenWrt image first because of the size limit. I am very new to OpenWrt and not experienced with the command line, so having to use that old unofficial OpenWrt image, as well as reading several posts about problems with that install process, makes me hesitant to try it. I'd happily wait if there is a chance for a simpler and easier initial install method. Thanks. ---
**Author:** ![mk24](https://forum.openwrt.org/letter_avatar/mk24/32/5_5575768a8748004e209b776fc1b2916d.png) [@mk24](https://forum.openwrt.org/u/mk24)\ **Post date:** [April 30, 2024, 8:17pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/11 "2024-04-30T20:17:09Z")
I think you could also use an old _official_ factory image for initial install then upgrade freely. Loading and booting an intramfs through serial means the image is never stored in flash, so it is free of the size limit. I have found this the simplest way to install. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [May 1, 2024, 12:44am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/12 "2024-05-01T00:44:13Z")
> [@oops](#): > > Is there any chance that what you are trying to do and the resulting OpenWrt images would be able to be used for an initilal OpenWrt install via the stock edgeOS or perhaps via the bootlader of an Edgerouter X? No there is nothing here that fixes the factory images. Once my PR's are merged and there are images available you would have two options. Web based with multiple steps: - Install the old custom 22.03 factory image through edgeos - Sysupgrade (via webui) to a 23.05 image containing the new changes for kernel size - Sysupgrade to snapshot or future 24.x release Serial (as mk24 mentions): - Boot 24.x initramfs via serial console + tftp - sysupgrade directly to the new release ---
**Author:** ![oops](https://forum.openwrt.org/letter_avatar/oops/32/5_5575768a8748004e209b776fc1b2916d.png) [@oops](https://forum.openwrt.org/u/oops)\ **Post date:** [May 1, 2024, 7:48am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/13 "2024-05-01T07:48:36Z")
darkxst and mk24, thanks for the replies. For the first method via edgeOS: 1. Are you sure there will be a webUI after installation of the custom image? I understood that luci is not installed there, though I might well be wrong. 2. Do the current 23.05 images already include the kernel size changes and if not, how would I be able to know when they do? As for the serial installation method, it looks even more intimidating to me than the other one, though I do like that it only uses the current official OpenWrt images. I'll think about which method, if any, I might try. In any case, I appreciate the time and effort that you and others put into making OpenWrt work. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [May 1, 2024, 8:41am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/14 "2024-05-01T08:41:34Z")
> [@oops](#): > > Are you sure there will be a webUI after installation of the custom image? I understood that luci is not installed there, though I might well be wrong. Yes the builds from the stman repo include Luci > [@oops](#): > > Do the current 23.05 images already include the kernel size changes and if not, how would I be able to know when they do? Not yet, my PR's still need to be merged, but then hopefully they make it into the next official release i.e 23.05.4 later in the year. ---
**Author:** ![sandberg](https://forum.openwrt.org/letter_avatar/sandberg/32/5_5575768a8748004e209b776fc1b2916d.png) [@sandberg](https://forum.openwrt.org/u/sandberg)\ **Post date:** [May 1, 2024, 10:25am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/15 "2024-05-01T10:25:50Z")
> [@darkxst](#): > > Not yet, my PR's still need to be merged, but then hopefully they make it into the next official release i.e 23.05.4 later in the year. I wonder if an issue needs to be created for 23.05 saying that it's not possible to upgrade to 24.x as it looks now. I didn't find one yet. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [May 1, 2024, 11:12am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/16 "2024-05-01T11:12:43Z")
Probably at some point, but perhaps it should wait until the changes are in main first? ---
**Author:** ![oops](https://forum.openwrt.org/letter_avatar/oops/32/5_5575768a8748004e209b776fc1b2916d.png) [@oops](https://forum.openwrt.org/u/oops)\ **Post date:** [May 1, 2024, 12:52pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/17 "2024-05-01T12:52:02Z")
OK. Thanks for the information. ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [May 9, 2024, 12:17am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/18 "2024-05-09T00:17:33Z")
So it seems like patches to sysupgrade wont be accepted for backport to 23.05 ☹ This PR now instead provides migration script that can be run on 23.05 (or older) and will install the new layout. > > > UPDATE: I have reworked this PR to instead include a migration script that can b…e run to upgrade from 23.05.x -\> 24.x, since the below method was not suitable for inclusion in a stable release. > > > This PR backports required parts from PR #15194, to allow for direct sysupgrade to builds from main or future 24.x where the kernels are greater than 3MB. > > The OEM layout on the Edgerouter X has two kernel slots that are 3MB each. Starting with Linux 6.1 the kernel images no longer fit into this layout. > > This PR will prepare the Edgerouter X towards using a single kernel slot that is 6MB, this is achieved with the following changes: > > \- Adjust dts to make kernel1 6MB and drop kernel2 slot > \- Patch ubnt.sh to always flash to kernel1 slot (Likewise set the flag in factory partition to make sure kernel1 slot is active) > \- Set compat version to 2.0, to ensure the system has the updated ubnt.sh providing support for the new layout. > > This backport pre-seeds the dts layout and \`ubnt.sh\` changes, so that on a subsequent sysupgrade the system will be fully converted to single slot 6MB kernel layout. This will allow to directly sysupgrade to builds with larger kernels with no further manual intervention for user. > > \- The first sysupgrade to this version will switch dts layout to 6MB kernel slot and preintstall \`ubnt.sh\` change. (kernel could land in either kernel1 or kernel2 slot) > \- On the subsequent sysupgrade, kernel will be installed installed to kernel1 slot and system will have been converted to 6MB kernel slot. Hoping this can be accepted for backport. ---
**Author:** ![Deto](https://forum.openwrt.org/user_avatar/forum.openwrt.org/deto/32/130227_2.png) [@Deto](https://forum.openwrt.org/u/Deto)\ **Post date:** [June 18, 2024, 9:41pm UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/19 "2024-06-18T21:41:21Z")
Done root@OpenWrt:~# cat /proc/mtd dev: size erasesize name mtd0: 00080000 00020000 "u-boot" mtd1: 00060000 00020000 "u-boot-env" mtd2: 00060000 00020000 "factory" mtd3: 00600000 00020000 "kernel" mtd4: 0f7c0000 00020000 "ubi" I didn't find snapshot with kernel 6.6 Do you know where I can download it? Thanks ---
**Author:** ![darkxst](https://forum.openwrt.org/letter_avatar/darkxst/32/5_5575768a8748004e209b776fc1b2916d.png) [@darkxst](https://forum.openwrt.org/u/darkxst)\ **Post date:** [June 19, 2024, 12:06am UTC](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968/20 "2024-06-19T00:06:34Z")
Hi Deto, Snapshot builds are disabled until my PR can be merged, until that happens you will need to build your own images if you want to test with Linux 6.6. [Next page](https://forum.openwrt.org/t/resizing-kernel-images-for-edgerouter-x/194968.md?page=2)