Welcome! Log In Create A New Profile

Advanced

SOLVED: Can't write uboot env after upgrade to Debian Buster

Posted by tsunulukai 
Forum List Message List New Topic
tsunulukai
SOLVED: Can't write uboot env after upgrade to Debian Buster
August 03, 2019 03:34PM
*** SOLVED *** --> See https://forum.doozan.com/read.php?3,87849,87959#msg-87959

The mtdparts definition syntax differs when the corresponding driver is loaded as a module instead of being directly embedded in the kernel. When updating to buster with the debian vanilla kernel, the corresponding is not embedded in the kernel anymore, but loaded as a module. As a consequence you must update your uboot mtdparts variable like this: 

setenv mtdparts 'cmdlinepart.mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'

The new syntax seems to work wether the driver is embedded in the kernel or loaded as a module, so the change should be backward compatble, at least to some extent.... I've tested it to work with the current Debian Stretch and Buster vanilla kernels. It also works on an old Debian Jessie with Bodhi's linux-image-4.2.0-kirkwood-tld-1 kernel.


*** INITIAL PROBLEM DESCRIPTION BELOW ***


I have a strange issue since upgrading to Debian Buster... The MTD setup by the kernel is messed up. It doesn't match the definition passed by uboot from the command line. And the partitions are set as RO. Therefore, it's impossible to use fw_printenv anymore to configure the bootloader form the OS.

I confirmed the discrepency going from Debian Stretch (9) with the official debian kernel package "linux-image-marvell" to Debian Buster (10) with the same updated official kernel package.

I have the same issue both with my dockstars and goflexnets (of course loaded with the corresponding dtb file).


Here's the initial uboot output which is identical wether I boot to Stretch or to Buster: 

U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:17:19 -0700)
Seagate GoFlex Net

SoC:   Kirkwood 88F6281_A1
DRAM:  128 MiB
WARNING: Caches not enabled
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Net:   egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot:  0
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
*** Unhandled DHCP Option in OFFER/ACK: 42
*** Unhandled DHCP Option in OFFER/ACK: 42
DHCP client bound to address 192.168.1.14 (3921 ms)

** Getting IP Settings by DHCP (net_dhcp_c = 1):
** IP Address: 192.168.1.14
** Subnet Mask: 255.255.255.0
** Def Gateway: 192.168.1.254

** Getting NFS Boot Server by DHCP (net_dhcp_s and net_dhcp_c = 1):
** NFS Boot Server: 192.168.1.1

** Kernel Boot Arguments:
** console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)

NFS loading uImage :192.168.1.1:/srv/nfs/hosts/goflex-263BA8/boot/uImage ...
done
Bytes transferred = 2043544 (1f2e98 hex)

NFS loading uInitrd :192.168.1.1:/srv/nfs/hosts/goflex-263BA8/boot/uInitrd ...
done
Bytes transferred = 14739343 (e0e78f hex)

NFS loading DTB :192.168.1.1:/srv/nfs/hosts/goflex-263BA8/boot/dts/kirkwood-goflexnet.dtb ...
###
done
Bytes transferred = 11397 (2c85 hex)

## Booting kernel from Legacy Image at 00800000 ...
   Image Name:   Linux-4.19.0-5-marvell
   Created:      2019-07-27  19:14:38 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2043480 Bytes = 1.9 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 01100000 ...
   Image Name:   initramfs-4.19.0-5-marvell
   Created:      2019-07-27  19:14:38 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    14739279 Bytes = 14.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02000000
   Booting using the fdt blob at 0x2000000
   Loading Kernel Image ... OK
   Loading Ramdisk to 06cff000, end 07b0d74f ... OK
   Loading Device Tree to 06cf9000, end 06cfec84 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.19.0-5-marvell (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 Debian 4.19.37-5 (2019-06-19)

uboot config and kernel cmdline (Debian version independant) : 
# fw_printenv
arcNumber=3089
autoload=no
bootargs=console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/dockstar/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
bootcmd=run net_bootcmd
bootcmd_exec=run load_uimage; if run load_initrd; then if run load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
bootcmd_uenv=run uenv_load; if test $uenv_loaded -eq 1; then run uenv_import; fi
bootdelay=3
bootdev=usb
bootfile=gpxelinux.0
console=ttyS0,115200
def_bootcmd=run bootcmd_uenv; run scan_disk; run set_bootargs; run bootcmd_exec
device=0:1
devices=usb ide mmc
disks=0 1 2 3
dnsip=192.168.1.254
dtb_file=/boot/dts/kirkwood-goflexnet.dtb
ethact=egiga0
ethaddr=00:10:75:26:3B:A8
gatewayip=192.168.1.254
hostname=Goflex-Test
if_netconsole=ping $serverip
ipaddr=192.168.1.14
led_error=orange blinking
led_exit=green off
led_init=green blinking
load_dtb=echo loading DTB $dtb_file ...; load $bootdev $device $load_dtb_addr $dtb_file
load_dtb_addr=0x02000000
load_initrd=echo loading uInitrd ...; load $bootdev $device $load_initrd_addr /boot/uInitrd
load_initrd_addr=0x1100000
load_uimage=echo loading uImage ...; load $bootdev $device $load_uimage_addr /boot/uImage
load_uimage_addr=0x800000
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
net_bootcmd=run net_check_dhcp_c; run net_check_dhcp_s; run net_set_bootargs; run net_bootcmd_exec
net_bootcmd_exec=run net_load_uimage; if run net_load_initrd; then if run net_load_dtb; then bootm $load_uimage_addr $load_initrd_addr $load_dtb_addr; else bootm $load_uimage_addr $load_initrd_addr; fi; else if run load_dtb; then bootm $load_uimage_addr - $load_dtb_addr; else bootm $load_uimage_addr; fi; fi
net_check_dhcp_c=if test $net_dhcp_c -eq 1 ; then run net_set_c_ip_dhcp; else run net_set_c_ip_stat; fi;echo ** IP Address:  $ipaddr; echo ** Subnet Mask: $netmask; echo ** Def Gateway: $gatewayip
net_check_dhcp_s=if test $net_dhcp_s -eq 1 && test $net_dhcp_c -eq 1 ; then run net_set_s_ip_dhcp; else run net_set_s_ip_stat; fi; echo ** NFS Boot Server: $net_nfs_server; echo
net_dhcp_c=1
net_dhcp_s=1
net_load_dtb=echo NFS loading DTB     :$net_nfs_server:$net_nfs_path/$net_nfs_dtb ...   ; nfs $load_dtb_addr    $net_nfs_server:$net_nfs_path/$net_nfs_dtb; echo
net_load_initrd=echo NFS loading uInitrd :$net_nfs_server:$net_nfs_path/$net_nfs_initrd ...; nfs $load_initrd_addr $net_nfs_server:$net_nfs_path/$net_nfs_initrd; echo
net_load_uimage=echo NFS loading uImage  :$net_nfs_server:$net_nfs_path/$net_nfs_kernel ...; nfs $load_uimage_addr $net_nfs_server:$net_nfs_path/$net_nfs_kernel; echo
net_nfs_dtb=boot/dts/kirkwood-goflexnet.dtb
net_nfs_initrd=boot/uInitrd
net_nfs_kernel=boot/uImage
net_nfs_path=/srv/nfs/hosts/goflex-263BA8
net_nfs_server=192.168.1.1
net_set_bootargs=setenv serverip $net_nfs_server; setenv bootargs console=$console root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=$net_nfs_server:$net_nfs_path/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=$ipaddr:$net_nfs_server:$gatewayip:$netmask:dockstar:eth0:off $mtdparts $custom_params; echo ** Kernel Boot Arguments:; echo ** $bootargs; echo
net_set_c_ip_dhcp=dhcp; echo; echo ** Getting IP Settings by DHCP (net_dhcp_c = 1):
net_set_c_ip_stat=setenv ipaddr $net_c_ipaddr; setenv netmask $net_c_netmask; setenv gatewayip $net_c_gatewayip; echo; echo ** Using static IP Settings (net_dhcp_c = 0):
net_set_s_ip_dhcp=setenv net_nfs_server $serverip;echo; echo ** Getting NFS Boot Server by DHCP (net_dhcp_s and net_dhcp_c = 1):
net_set_s_ip_stat=echo; echo ** Using static NFS Boot Server (net_dhcp_s or net_dhcp_c = 0) :
netmask=255.255.255.0
partition=nand0,2
preboot_nc=run if_netconsole start_netconsole
scan_disk=echo running scan_disk ...; scan_done=0; setenv scan_usb "usb start";  setenv scan_ide "ide reset";  setenv scan_mmc "mmc rescan"; for dev in $devices; do if test $scan_done -eq 0; then echo Scan device $dev; run scan_$dev; for disknum in $disks; do if test $scan_done -eq 0; then echo device $dev $disknum:1; if load $dev $disknum:1 $load_uimage_addr /boot/uImage 1; then scan_done=1; echo Found bootable drive on $dev $disknum; setenv device $disknum:1; setenv bootdev $dev; fi; fi; done; fi; done
serverip=192.168.1.1
set_bootargs=setenv bootargs console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params
start_netconsole=setenv ncip $serverip; setenv bootdelay 10; setenv stdin nc; setenv stdout nc; setenv stderr nc; version;
stderr=serial
stdin=serial
stdout=serial
uenv_addr=0x810000
uenv_import=echo importing envs ...; env import -t $uenv_addr $filesize
uenv_init_devices=setenv init_usb "usb start";  setenv init_ide "ide reset";  setenv init_mmc "mmc rescan"; for devtype in $devices; do run init_$devtype; done;
uenv_load=run uenv_init_devices; setenv uenv_loaded 0; for devtype in $devices;  do for disknum in 0; do run uenv_read_disk; done; done;
uenv_read=echo loading envs from $devtype $disknum ...; if load $devtype $disknum:1 $uenv_addr /boot/uEnv.txt; then setenv uenv_loaded 1; fi
uenv_read_disk=if test $devtype -eq mmc; then if $devtype part; then run uenv_read;  fi; else if $devtype part $disknum; then run uenv_read; fi;  fi
usb_ready_retry=15

# cat /proc/cmdline
console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)

# cat /etc/fw_env.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid; in this case the redundant
# environment sector is assumed present.
# Note that "Number of sectors" is ignored on NOR.

# MTD device name       Device offset   Env. size       Flash sector size       Number of sectors
/dev/mtd0               0xc0000         0x20000         0x20000

Expected behavior as visible in Debian Stetch: 

# cat /etc/debian_version
9.9

# uname -a
Linux dockstar 4.9.0-9-marvell #1 Debian 4.9.168-1 (2019-04-12) armv5tel GNU/Linux

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "rootfs"
mtd3: 0db00000 00020000 "data"

# dmesg | grep -e mtd -e boot -e 0x000
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boo ),4M(uImage),32M(rootfs),-(data)
[    1.914595] 0x000000000000-0x000000100000 : "u-boot"
[    1.920794] 0x000000100000-0x000000500000 : "uImage"
[    1.926926] 0x000000500000-0x000002500000 : "rootfs"
[    1.933162] 0x000002500000-0x000010000000 : "data"

# ls -l /dev/mtd*
crw------- 1 root root 90, 0 2019-08-03 18:30 /dev/mtd0
crw------- 1 root root 90, 1 2019-08-03 18:30 /dev/mtd0ro
crw------- 1 root root 90, 2 2019-08-03 18:30 /dev/mtd1
crw------- 1 root root 90, 3 2019-08-03 18:30 /dev/mtd1ro
crw------- 1 root root 90, 4 2019-08-03 18:30 /dev/mtd2
crw------- 1 root root 90, 5 2019-08-03 18:30 /dev/mtd2ro
crw------- 1 root root 90, 6 2019-08-03 18:30 /dev/mtd3
crw------- 1 root root 90, 7 2019-08-03 18:30 /dev/mtd3ro
brw-rw---- 1 root disk 31, 0 2019-08-03 18:30 /dev/mtdblock0
brw-rw---- 1 root disk 31, 1 2019-08-03 18:30 /dev/mtdblock1
brw-rw---- 1 root disk 31, 2 2019-08-03 18:30 /dev/mtdblock2
brw-rw---- 1 root disk 31, 3 2019-08-03 18:30 /dev/mtdblock3


# fw_setenv test 1

# fw_printenv | grep test=
test=1

#


Observed issue in Debian Buster: 
# cat /etc/debian_version
10.0

# uname -a
Linux goflexnet 4.19.0-5-marvell #1 Debian 4.19.37-5 (2019-06-19) armv5tel GNU/Linux

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "pogoplug"
mtd3: 0d800000 00020000 "root"

# dmesg | grep -e mtd -e boot -e 0x000
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boo ),4M(uImage),32M(rootfs),-(data)
[   20.049178] 0x000000000000-0x000000100000 : "u-boot"
[   20.070147] 0x000000100000-0x000000500000 : "uImage"
[   20.104547] 0x000000500000-0x000002500000 : "pogoplug"
[   20.138798] 0x000002500000-0x00000fd00000 : "root"

# ls -l /dev/mtd*
crw------- 1 root root 90, 0 2019-08-03 16:10 /dev/mtd0
crw------- 1 root root 90, 1 2019-08-03 16:10 /dev/mtd0ro
crw------- 1 root root 90, 2 2019-08-03 16:10 /dev/mtd1
crw------- 1 root root 90, 3 2019-08-03 16:10 /dev/mtd1ro
crw------- 1 root root 90, 4 2019-08-03 16:10 /dev/mtd2
crw------- 1 root root 90, 5 2019-08-03 16:10 /dev/mtd2ro
crw------- 1 root root 90, 6 2019-08-03 16:10 /dev/mtd3
crw------- 1 root root 90, 7 2019-08-03 16:10 /dev/mtd3ro

# fw_setenv test 2
Can't open /dev/mtd0: Permission denied
Error: can't write fw_env to flash

# fw_printenv | grep test=
test=1

#

I can't help but think it's a bug in the official kernel package... but I'd like a second opinion on this :)



Edited 4 time(s). Last edit at 08/05/2019 03:57PM by tsunulukai.
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 12:41AM
tsunulukai,

> I can't help but think it's a bug in the official
> kernel package... but I'd like a second opinion on
> this :)

Yes. On the surface it seems so! but I'll take a closer look to see where that problem is.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 02:41AM
Bodhi,

just as a confirmation that it's a kernel issue, I upgraded my Buster image with your kernel package (https://forum.doozan.com/read.php?2,12096) and, sure enough, the problem is then solved...

Still, I'd like to figure out a way to have it work with the mainline debian kernel because I don't want to loose automatic security updates for it...

I tried using the buster kernel with the squeeze or your dtb file, with no luck. (It boots, but the issue is still there...)

You can find the offending kernel package here: https://packages.debian.org/buster/linux-image-marvell, which is currently a meta package for this one: https://packages.debian.org/buster/linux-image-4.19.0-5-marvell

Thanks !
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 05:04AM
tsunulukai,

> Still, I'd like to figure out a way to have it
> work with the mainline debian kernel because I
> don't want to loose automatic security updates for
> it...

Sure! understood.

> You can find the offending kernel package here:
> https://packages.debian.org/buster/linux-image-marvell,
> which is currently a meta package for this one:
> https://packages.debian.org/buster/linux-image-4.19.0-5-marvell

If you can find the original Debian kernel package source files, it would speed up the investigation! I can install that source, but it would polute my x86 Linux VM (I'm on the road and only have access to my laptop). Debian surely have linux-4.19.0-5-marvell source tarball somewhere.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
1000001101000
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 07:43AM
Looks like the mainline dtb marks it as read-only.
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-goflexnet.dts 

partition@0 {
		label = "u-boot";
		reg = <0x0000000 0x100000>;
		read-only;
	};

Looks like it has for a long time, but if you changed to the dtb distributed by debian recently it might explain it.
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 08:27AM
1000001101000 Wrote:
-------------------------------------------------------
> Looks like the mainline dtb marks it as
> read-only.
> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-goflexnet.dts
>
> 
> partition@0 {
> 		label = "u-boot";
> 		reg = <0x0000000 0x100000>;
> 		read-only;
> 	};
>
>
> Looks like it has for a long time, but if you
> changed to the dtb distributed by debian recently
> it might explain it.

Not that reason. The whole MTD definition from bootargs was ignored.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 08/04/2019 08:28AM by bodhi.
Reply Quote
1000001101000
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 09:27AM
I think ignoring the cmdline partition info is normal for the vanilla Debian kernel: 

~# cd /boot
/boot# grep -i parts config-4.19.0-5-armmp 

# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=m
CONFIG_MTD_AR7_PARTS=m

Wouldn’t that cause it to use the partitions defined in the dtb?

The armada 370/xp based buffalo devices all have mtd partitions passed from uboot via the cmdline and the Debian kernel ignores those too and instead follows the partitions in the dtb, and enforces the read-only setting.
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 09:48AM
> # CONFIG_MTD_CMDLINE_PARTS is not set

>
> Wouldn’t that cause it to use the partitions
> defined in the dtb?
>

Now the above is the reason!

That very likely means the previous Debian stretch kernel did have this config set to Yes. And now Debian buster has this configured as No.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
1000001101000
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 10:10AM
Those config options are all the same on the stretch kernel. I assume @tsunulukai was running a different kernel (maybe one of yours?) last time they were able to make changes.

In any case, removing that read-only; attribute in the dts and making a new dtb should get it working again.
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 01:15PM
This was Debian mainline stretch kernel for Kirkwood. 

# uname -a
Linux dockstar 4.9.0-9-marvell #1 Debian 4.9.168-1 (2019-04-12) armv5tel GNU/Linux

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 02000000 00020000 "rootfs"
mtd3: 0db00000 00020000 "data"

But the DTB was from my released tarball.

@tsunulukai,
Try using my released DTB for GoflexNet with the buster kernel.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 08/04/2019 01:19PM by bodhi.
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 04:45PM
@1000001101000: I'm using Debian vanilla kernel AND DTB files in both the Squeeze and Buster distro I used while performing the tests to isolate the issue.

@bodhi: I was not using your DTB files with the debian Kernels

The DTB file provided by the Debian package are located in 
/usr/lib/linux-image-${LINUXVER}/kirkwood-dockstar.dtb or 
/usr/lib/linux-image-${LINUXVER}/kirkwood-goflexnet.dtb

In Debian Stretch, the kernel was configured to read the MTD configuration from the kernel cmdline: 
# grep -i parts goflex-263BA8.debian9/boot/config*
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
CONFIG_MTD_AR7_PARTS=m

In the Debian Buster, the setting is set to m(odule). 
# grep -i parts goflex-263BA8.debian10/boot/config*
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=m
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=m
CONFIG_MTD_AR7_PARTS=m

So it might indeed be the source of the problem, the kernel ignoring the mtdparts argument in its command line...
Although I don't get how reading the mtdparts from the command line makes them read-write... unless RW is the default when read from the cmdline ?

@1000001101000 
> partition@0 {
> 		label = "u-boot";
> 		reg = <0x0000000 0x100000>;
> 		read-only;
> 	};
I fetched the debian kernel source for Stretch (linux-source-4.9_4.9.168-1+deb9u4_all.deb) & Buster (linux-source-4.19_4.19.37-5+deb10u1_all.deb), the goflexnet partition definition is the same in both and matches the one you provided from Linus' github.


Now let's do the test Bodhi suggested...

Using the Buster vanilla kernel and DTB file: 
# uname -a
Linux goflexnet 4.19.0-5-marvell #1 Debian 4.19.37-5 (2019-06-19) armv5tel GNU/Linux

# md5sum /usr/lib/linux-image-4.19.0-5-marvell/kirkwood-goflexnet.dtb
c665de1049fc547761e2466c94c31701  /usr/lib/linux-image-4.19.0-5-marvell/kirkwood-goflexnet.dtb

# md5sum /boot/dts/kirkwood-goflexnet.dtb
c665de1049fc547761e2466c94c31701  /boot/dts/kirkwood-goflexnet.dtb

# dmesg | grep -ie mtd -e 0x000
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
[   20.346396] 4 fixed-partitions partitions found on MTD device orion_nand
[   20.353177] Creating 4 MTD partitions on "orion_nand":
[   20.383129] 0x000000000000-0x000000100000 : "u-boot"
[   20.395002] 0x000000100000-0x000000500000 : "uImage"
[   20.402591] 0x000000500000-0x000002500000 : "pogoplug"
[   20.412498] 0x000002500000-0x00000fd00000 : "root"

# fw_setenv test 2
Can't open /dev/mtd0: Permission denied
Error: can't write fw_env to flash

# fw_printenv | grep test=
test=1

Using Bodhi's DTB file with the Buster vanilla kernel: 
# uname -a
Linux goflexnet 4.19.0-5-marvell #1 Debian 4.19.37-5 (2019-06-19) armv5tel GNU/Linux

# md5sum /root/bodhi/dts/kirkwood-goflexnet.dtb
4921e765a003be6a0d104138f18c3484  bodhi/dts/kirkwood-goflexnet.dtb

# md5sum /boot/dts/kirkwood-goflexnet.dtb
4921e765a003be6a0d104138f18c3484  /boot/dts/kirkwood-goflexnet.dtb

# dmesg | grep -ie mtd -e 0x000
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 ip=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
[   19.838046] 4 fixed-partitions partitions found on MTD device orion_nand
[   19.844822] Creating 4 MTD partitions on "orion_nand":
[   19.867901] 0x000000000000-0x000000100000 : "u-boot"
[   19.886798] 0x000000100000-0x000000500000 : "uImage"
[   19.899049] 0x000000500000-0x000002500000 : "pogoplug"
[   19.917017] 0x000002500000-0x00000fd00000 : "root"

# fw_setenv test 2

# fw_printenv | grep test=
test=2

So using Bodhi's DTB solves the issue for the MTD partition being read-only... but not the mtdparts definition in the cmdline being ignored...

Diffing all the MTD settings between the stretch and the buster kernel gives the following output: 

# diff goflex-263BA8.deb9/boot/config-4.9.0-9-marvell goflex-263BA8.deb10/boot/config-4.19.0-5-marvell | grep -i mtd
< CONFIG_MTD=y
> CONFIG_MTD=m
< CONFIG_MTD_CMDLINE_PARTS=y
> CONFIG_MTD_CMDLINE_PARTS=m
< CONFIG_MTD_OF_PARTS=y
> CONFIG_MTD_OF_PARTS=m
< CONFIG_MTD_BLKDEVS=y
< CONFIG_MTD_BLOCK=y
> CONFIG_MTD_BLKDEVS=m
> CONFIG_MTD_BLOCK=m
> CONFIG_MTD_BLOCK_RO=m
< CONFIG_MTD_CFI=y
< CONFIG_MTD_JEDECPROBE=y
< CONFIG_MTD_GEN_PROBE=y
> CONFIG_MTD_CFI=m
> CONFIG_MTD_JEDECPROBE=m
> CONFIG_MTD_GEN_PROBE=m
< CONFIG_MTD_CFI_INTELEXT=y
< CONFIG_MTD_CFI_AMDSTD=y
> CONFIG_MTD_CFI_INTELEXT=m
> CONFIG_MTD_CFI_AMDSTD=m
< CONFIG_MTD_CFI_UTIL=y
> CONFIG_MTD_CFI_UTIL=m
< CONFIG_MTD_PHYSMAP=y
> CONFIG_MTD_PHYSMAP=m
< CONFIG_MTD_PHYSMAP_OF=y
> CONFIG_MTD_PHYSMAP_OF=m
> # CONFIG_MTD_MCHP23K256 is not set
< CONFIG_MTD_NAND_ECC=y
> # CONFIG_MTD_ONENAND is not set
> CONFIG_MTD_NAND_ECC=m
< CONFIG_MTD_NAND=y
< CONFIG_MTD_NAND_BCH=y
> CONFIG_MTD_NAND=m
> CONFIG_MTD_NAND_BCH=m
< # CONFIG_MTD_NAND_OMAP_BCH_BUILD is not set
< CONFIG_MTD_NAND_IDS=y
< # CONFIG_MTD_NAND_PXA3xx is not set
> # CONFIG_MTD_NAND_MARVELL is not set
< CONFIG_MTD_NAND_ORION=y
< # CONFIG_MTD_NAND_HISI504 is not set
< # CONFIG_MTD_NAND_MTK is not set
< # CONFIG_MTD_ONENAND is not set
> CONFIG_MTD_NAND_ORION=m
> # CONFIG_MTD_SPI_NAND is not set
> CONFIG_SFC_MTD=y
> CONFIG_SFC_FALCON_MTD=y
< CONFIG_SFC_MTD=y

So I guess I should fill a bug report to have those changes reverted in buster marvell kernels because they break the proper working of the fw_setenv tool provided in the u-boot-tools package.



Edited 2 time(s). Last edit at 08/04/2019 04:59PM by tsunulukai.
Reply Quote
1000001101000
Re: Can't write uboot env after upgrade to Debian Buster
August 04, 2019 05:52PM
Hmm, I was looking at the armmp kernel rather than the marvell kernel, that changes things a bit.

@tsunulukai if it’s set to m you probably just have to load the module.

Try adding cmdlinepart to /etc/modules and reboot
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 12:33AM
@1000001101000, nope, no luck... :(
The cmdlinepart module is already loaded by default without being specified in /etc/modules.... 

# lsmod | grep mtd
mtd                    44525  9 nand_bch,ofpart,nand,cmdlinepart,orion_nand

# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.



# cat /etc/modules-load.d/modules.conf
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.



# find /usr/lib/modules/4.19.0-5-marvell/ | grep mtd
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/ubi
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/ubi/ubi.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/ar7part.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/lpddr
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/lpddr/qinfo_probe.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/lpddr/lpddr_cmds.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/mtdblock_ro.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/cfi_cmdset_0001.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/cfi_cmdset_0002.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/gen_probe.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/cfi_util.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/cfi_cmdset_0020.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/cfi_probe.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/chipreg.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/chips/jedec_probe.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/ftl.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/mtd.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/ofpart.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/devices
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/devices/sst25l.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/devices/m25p80.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/devices/mtd_dataflash.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/nandsim.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/nand_bch.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/nand.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/r852.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/sm_common.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/orion_nand.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nand/raw/nand_ecc.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/mtdswap.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/spi-nor
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/spi-nor/spi-nor.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/maps
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/maps/physmap_of.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/maps/physmap.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/mtdblock.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/cmdlinepart.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/mtd_blkdevs.ko
/usr/lib/modules/4.19.0-5-marvell/kernel/drivers/mtd/nftl.ko

And I don't see directly which other module I could load to have the kernel read the mtdparts variable...
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 12:39AM
tsunulukai,

> So I guess I should fill a bug report to have
> those changes reverted in buster marvell kernels
> because they break the proper working of the
> fw_setenv tool provided in the u-boot-tools
> package.

Yes. That is a "bug". Or we might say the removal of mtdparts bootarg as kernel build-in capability is a regression in mainline kernel.

It's hard to believe that bootargs behavior would be changed like that in Debian mainline :)

You can add the early module loading in /etc/modules, as 1000001101000 suggested. But the fact that you need to do this in an embedded Linux system is just a very wrong, a big regression to me.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 12:43AM
tsunulukai,

> The cmdlinepart module is already loaded by
> default without being specified in
> /etc/modules....

It is being loaded too late to be enable during boot.


Try modify the /etc/modules like (add all seemingly relevant modules): 

> # cat /etc/modules
> # /etc/modules: kernel modules to load at boot
> time.
> #

nand
cmdlinepart
orion_nand

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 2 time(s). Last edit at 08/05/2019 01:45AM by bodhi.
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 03:45AM
Tried it already, doesn't change a thing. Rebuilding the initramsfs after changing the /etc/modules file to ensure the modules are loaded as early as possible didn't help either: 

# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
nand
cmdlinepart
orion_nand
nand_bch
ofpart

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.19.0-5-marvell

#cd /boot
# LINUXVER=$(basename /boot/vm* | head -n 1| sed 's/[\/a-z]*-//') && echo $LINUXVER
4.19.0-5-marvell

#mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-${LINUXVER} -d /boot/initrd.img-${LINUXVER}  /boot/uInitrd
Image Name:   initramfs-4.19.0-5-marvell
Created:      Mon Aug  5 08:28:09 2019
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    14738344 Bytes = 14392.91 KiB = 14.06 MiB
Load Address: 00000000
Entry Point:  00000000

# reboot

# dmesg | grep -ie mtd -e 0x000 -ie nand -ie orion
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfstype=nfs rootwait nfsroot=192.168.1.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,wsize=32768,hard,intr,udp,v3 i
p=192.168.1.14:192.168.1.1:192.168.1.254:255.255.255.0:dockstar:eth0:off mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
[    0.000000] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns
[    0.021114] clocksource: Switched to clocksource orion_clocksource
[    2.488165] libphy: orion_mdio_bus: probed
[    2.732101] ehci-orion: EHCI orion driver
[    2.751887] orion-ehci f1050000.ehci: EHCI Host Controller
[    2.757519] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1
[    2.767642] orion-ehci f1050000.ehci: irq 29, io mem 0xf1050000
[    2.789133] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[   23.564249] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[   23.570678] nand: Micron MT29F2G08AAD
[   23.574374] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[   24.813065] 4 fixed-partitions partitions found on MTD device orion_nand
[   24.819845] Creating 4 MTD partitions on "orion_nand":
[   24.849181] 0x000000000000-0x000000100000 : "u-boot"
[   24.869418] 0x000000100000-0x000000500000 : "uImage"
[   24.885597] 0x000000500000-0x000002500000 : "pogoplug"
[   24.901599] 0x000002500000-0x00000fd00000 : "root"
[   26.228906] orion_wdt: Initial timeout 21 sec

# fw_setenv test 2
Can't open /dev/mtd0: Permission denied
Error: can't write fw_env to flash


I'll file this issue to the debian bugtracker

The bug is filed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933971



Edited 4 time(s). Last edit at 08/05/2019 11:34AM by tsunulukai.
Reply Quote
1000001101000
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 11:41AM
I took another look at that mainline device tree as well as the documentation for MTD partition bindings. Since that device tree hasn't been updated in many years it still uses the older style of binding for fixed partitions. According to the bindings documentation using the older type is not recommended though it doesn't way anything specific on how they would be handled differently.

https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/mtd/partition.txt

Looking at the code for the kernel module I can see they added code when the binding changes were added but it's not obvious to me what difference that makes if any.

https://github.com/torvalds/linux/blob/master/drivers/mtd/cmdlinepart.c
https://github.com/torvalds/linux/blob/master/drivers/mtd/mtdpart.c

I would imagine you can solve the immediate problem by removing the partition definitions from the DTB to see if that allows cmdline to supersede them or just adjust the DTB definitions to what you want, possibly including updating them to the current binding scheme.
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 12:09PM
Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931852

The mtdparts definition syntax differs when the corresponding driver is loaded as a module instead of being directly embedded in the kernel. When updating to buster with the debian vanilla kernel, the corresponding is not embedded in the kernel anymore, but loaded as a module. As a consequence you must update your uboot mtdparts variable like this 

setenv mtdparts 'cmdlinepart.mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'

instead of 
setenv mtdparts 'mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)'

The new syntax seems to work wether the driver is embedded in the kernel or loaded as a module, so the change should be backwards compatible, at least to some extent.... I've tested it to work fine with the current Debian Stretch and Buster vanilla kernels.


The result: 
# dmesg | grep -ie mtd -e 0x000 -ie nand -ie orion
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/nfs rw rootfs
type=nfs rootwait nfsroot=172.20.20.1:/srv/nfs/hosts/goflex-263BA8/,rsize=32768,
wsize=32768,hard,intr,udp,v3 ip=172.20.20.14:172.20.20.1:172.20.20.254:255.255.2
55.0:dockstar:eth0:off cmdlinepart.mtdparts=orion_nand:1M(u-boot),4M(uImage),32M
(rootfs),-(data)
[    0.000000] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xff
ffffff, max_idle_ns: 9556302233 ns
[    0.021131] clocksource: Switched to clocksource orion_clocksource
[    2.476246] libphy: orion_mdio_bus: probed
[    2.717748] ehci-orion: EHCI orion driver
[    2.730525] orion-ehci f1050000.ehci: EHCI Host Controller
[    2.742342] orion-ehci f1050000.ehci: new USB bus registered, assigned bus nu
mber 1
[    2.762963] orion-ehci f1050000.ehci: irq 29, io mem 0xf1050000
[    2.785154] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00
[   16.474003] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[   16.480422] nand: Micron MT29F2G08AAD
[   16.484124] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB siz
e: 64
[   17.613657] 4 cmdlinepart partitions found on MTD device orion_nand
[   17.620072] Creating 4 MTD partitions on "orion_nand":
[   17.637206] 0x000000000000-0x000000100000 : "u-boot"
[   17.718203] 0x000000100000-0x000000500000 : "uImage"
[   17.729629] 0x000000500000-0x000002500000 : "rootfs"
[   17.753268] 0x000002500000-0x000010000000 : "data"
[   19.173492] orion_wdt: Initial timeout 21 sec

# fw_setenv test 3

# fw_printenv | grep test=
test=3



Edited 3 time(s). Last edit at 08/05/2019 12:59PM by tsunulukai.
Reply Quote
bodhi
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 01:32PM
tsunulukai,

Glad you’ve found a work around!

But I don’t think it is good final solution. Kernel mtdparts arg should not behave differently when its driver is configured as module or built-in. This is going to break many embedded devices that use mainline kernel during their buster upgrade.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Reply Quote
tsunulukai
Re: Can't write uboot env after upgrade to Debian Buster
August 05, 2019 01:40PM
Bodhi,

Exactly what I answered on the debian mailing list : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933971#15 

It is indeed the same bug and the proposed workaround works fine.

Still, I think that the choice of compiling the corresponding driver
as a module instead of embedding it in the kernel is a decision that
will impact many users when they upgrade their plug device from Debian
Stretch to Buster.

Most of them are bound to meet the same issue.

Any chance this choice would be reconsidered?

Le lun. 5 août 2019 à 18:42, Ben Hutchings <ben@decadent.org.uk> a écrit :
>
> This appears to be the same as bug #931852, where you will find a
> workaround: https://bugs.debian.org/931852.
>
> Ben.
>
> --
> Ben Hutchings
> Beware of programmers who carry screwdrivers. - Leonard Brandwein

I hope they fix it. But at least we have workaround in the meantime...

I encourage everyone who thinks the same way to rise their voice on the debian bug tracking system.

Either on my submission here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933971
or on the original one there:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931852



Edited 1 time(s). Last edit at 08/05/2019 01:45PM by tsunulukai.
Reply Quote
rhemberger
Re: SOLVED: Can't write uboot env after upgrade to Debian Buster
August 12, 2019 01:51PM
Hello,
Debian Kernel Team changed a lot of NAND related stuff to modules to reduce kernel size.
e.g:
https://salsa.debian.org/kernel-team/linux/commit/c55043a43eaacb9f876dabd71273b084cb024441
https://salsa.debian.org/kernel-team/linux/commit/d7f8738db2f9a1dfb7490492d59d6f907803cff8

You can force the necessary modules in the initramfs (/etc/initramfs-tools/modules), rebuild the initramfs and after reboot the old behavior should be restored.
This worked for me with an orion5x QNAP.

The debian marvell-kernel is extremely stripped down, lacks also a lot security settings to fit in 2097080.
Better to stay with the Bodhi-kernel imo

Cheers
Ralf
Reply Quote
Newer Topic Older Topic
Author:

Your Email:


Subject:
Spam prevention:
Please, enter the code that you see below in the input field. This is for blocking bots that try to post this form automatically. If the code is hard to read, then just try to guess it right. If you enter the wrong code, a new image is created and you get another chance to enter it right.
Message: