19.07: Swap doesn't work on D-Link DIR-620 D1 (ramips/rt305x) due to small_flash

Swap no longer works on D-Link DIR-620 D1 (ramips/rt305x):

# swapon -s
block: failed to open /proc/swaps

# ubus call system board
{
	"kernel": "4.14.151",
	"hostname": "vgrouter",
	"system": "Ralink RT3352 id:1 rev:6",
	"model": "D-Link DIR-620 D1",
	"board_name": "dir-620-d1",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.0-rc1",
		"revision": "r10649-c4fdb377a2",
		"target": "ramips/rt305x",
		"description": "OpenWrt 19.07.0-rc1 r10649-c4fdb377a2"
	}
}

If someone else wants to build OpenWrt for this device, here is the config:

tee .config << EOF
CONFIG_TARGET_ramips=y
CONFIG_TARGET_ramips_rt305x=y
CONFIG_TARGET_ramips_rt305x_DEVICE_dlink_dir-620-d1=y
CONFIG_PACKAGE_block-mount=y
CONFIG_PACKAGE_f2fs-tools=y
CONFIG_PACKAGE_kmod-fs-f2fs=y
CONFIG_PACKAGE_kmod-rt2800-usb=y
CONFIG_PACKAGE_kmod-usb2=y
CONFIG_PACKAGE_kmod-usb-storage=y
CONFIG_PACKAGE_zram-swap=y
CONFIG_DROPBEAR_ED25519=y
CONFIG_KERNEL_SWAP=y
CONFIG_PROCD_ZRAM_TMPFS=y
EOF
make -j $(nproc) defconfig download clean world

Does file /proc/swaps exist? Check via ls -l
If it does, what's content?

Do you have /etc/fstab ?

Are any swap files/partitions defined there?

Is there anything new in dmesg, after you perform this command?

# dd if=/dev/zero of=/swap bs=1M count=100
100+0 records in
100+0 records out

# mkswap /swap
Setting up swapspace version 1, size = 104853504 bytes

# uci show fstab.swap
fstab.swap=swap
fstab.swap.device='/swap'

# ls -l -h /swap
-rw-r--r--    1 root     root      100.0M Nov 10 07:27 /swap

# ls -l /proc/swaps
ls: /proc/swaps: No such file or directory

# swapon -a

# swapon /swap
block: failed to swapon /swap (-1)

# swapon -s
block: failed to open /proc/swaps

# free
              total        used        free      shared  buff/cache   available
Mem:          28260       17196        2324         880        8740        7932
Swap:             0           0           0

# dmesg | tail
[  797.015681] br-lan: port 2(wlan0) entered blocking state
[  797.026459] br-lan: port 2(wlan0) entered disabled state
[  797.037784] device wlan0 entered promiscuous mode
[  797.735561] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  797.748727] br-lan: port 2(wlan0) entered blocking state
[  797.759469] br-lan: port 2(wlan0) entered forwarding state
[ 1785.856702] kmodloader: loading kernel modules from /etc/modules.d/*
[ 1786.217736] tun: Universal TUN/TAP device driver, 1.6
[ 1786.731998] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 2380.880974] rt3050-esw 10110000.esw: link changed 0x10

When it did last time work for you in the 19.07 branch?

Well, I try to use stable releases, so the last working is 18.06.4.

According to the error message, swap seems to be disabled in the kernel.
But I don't understand the logic of disabling swap, when this model has enough resources to install and run VPN and has a USB port for extroot/swap.

Well, then we are talking about a 1.5 year regression window since June 2018 :frowning:

Two minutes of git search revealed this conclusion for you:
It has been disabled in July 2018 for your router family (among others) due to the relatively small flash size.

Deduction path:

If you want to enable swap in your own builds, simply

  • edit target/linux/ramips/rt305x/target.mk to remove "small_flash" (and tackle the possible other side effects of that change), or
  • edit config/Config-kernel.in and revert the swap & small_flash related changes
3 Likes

Could you tell whether it is possible to implement one of the following actions by default?

  • Do not disable swap when there is a USB port present.
  • Remove the mark small_flash from D-Link DIR-620 D1.

You can easily do pretty much anything for your own builds.
But getting something accepted to the public code would be much more difficult.

Specifically to your questions:

  • "small_flash" is set for the whole target (as a feature), so you can't easily remove that for just one router. But when you personally build only for your own router type, you can naturally remove that also from the other routers.

  • USB can be present in really resource-limited 4/32 routers, so that does not indicate the wish to bloat the firmware by enabling the swap features in kernel by default. (Using USB based disk for swap is not that optimal performance-wise.) The devs have tried to keep the resource-limited routers (like yours) alive by selectively disabling less-used features.

Note that as your router (DIR-620 D1) only has 32 MB RAM, it is pretty much abandoned from the generic OpenWrt perspective in 19.07. If you want to take special config action to keep it still alive, feel free to do that in your own builds, but do not expect the generic public OpenWrt to accommodate for that.

Just implement one of my proposals for your own build.

4 Likes

I have the same setup and am in the same boat.

tackle the possible other side effects of that change

Could you elaborate on this?

revert the swap & small_flash related changes

Is reverting the config KERNEL_DEBUG_INFO section enough, and then rebuilding? And can't that be overwritten with a normal make menuconfig?

I assume that KERNEL_SWAP would be the critical option...

Might be possible as it looks like a normal config item option. Haven't checked.

Not really. I haven't looked into the other effects of small_flash option, but there may be some other relevant places where it has impact. Squashfs optimization etc.
But as I have no relevant devices, I have never looked into its impact on detailed level.

1 Like

Oops, yeah I meant KERNEL_SWAP.

I couldn't find the option in menuconfig so I just added CONFIG_KERNEL_SWAP=y to my .config and now zram seems to work for swap.

But I have also CONFIG_PROCD_ZRAM_TMPFS=y in my .config (as recommended here) and I'm getting this error in dmesg:

Can't mount /dev/zram0 on /tmp: No such device

Same issue was reported here.

1 Like

It does not work for some reason.
Perhaps it is related to small_flash inside tmp/.targetinfo which is produced by scripts/feeds install -a.

It seems to work, but the result looks identical to simply using CONFIG_KERNEL_SWAP=y which makes the build_dir/target-*/linux-*/linux-*/.vermagic to not match the official build.

Is there a way to build it to be able to use the official repositories?

No, that is not possible as the changed value of CONFIG_SWAP changes the version hash.

1 Like

Did you try deleting everything from tmp and letting that target & package database to get re-created?

Sometimes the old info sticks there, e.g. when a packages moves from one feed to another. Deleting tmp can help.

1 Like

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