Hi bodhi, I use your kernels on several Zyxel NAS326 (MVEBU) and one Medion P89626 (oxnas). The MVEBU kernel is the one I need CONFIG_USER_NS for. As said before, with your configs and patches, I can build a kernel for myself. Of course, it would be more convenient to have the config included in your kernels. Thank you for your effort Alanby kralan - Debian
Thank you, Bodhi! This will make my life easier and avoid problems with standard Debian packages.by kralan - Debian
Hi Bodhi, Debian have turned on CONFIG_USER_NS in their kernels and depend on it in some of their userspace. See the Debian discussion here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898446 Thank you for pointing out the risks, I was not aware of all of them. I can compile a modified kernel for myself if I can not find a way of working around the redis-server requirement. Alanby kralan - Debian
To be more specific: CONFIG_USER_NS is needed for service files setting PrivateUsers=true, which is the case for redis-server or uidd, for instance.by kralan - Debian
Hi Bodhi, please include CONFIG_USER_NS in your kernel builds, it is needed for newer versions of Debian's systemd. Thanks Alanby kralan - Debian
bodhi Wrote: ------------------------------------------------------- > The potential problem with using flash-kernel is > for less eperienced users. If the rootfs > was not created by using my release rootfs, then > it is possible that the user is installing my > customed build kernel from a mainline Debian > debootstrap rootfs, therefore there is a mainline > Debiaby kralan - Debian
Hi bodhi, in the Linux Kernel 5.2.9 MVEBU package and Debian armhf rootfs installation instructions, you state: QuoteRemove flash-kernel first to avoid potential problem. Is this still valid? I use flash-kernel to simplify/automate the uboot image creation. I installed flash-kernel from the Debian buster archives and added /etc/flash-kernel/db like this: Machine: Zyxel NAS326 U-Boot-Kernby kralan - Debian
bodhi, thank you for your detailed explanation. I probably won't trace the traces on the board, but I'll go and review the sources to gain more insight. kralanby kralan - Debian
hi bodhi, I have a question regarding the installation instructions: Section A (USB with serial console) calls for GPIO setup like this: setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start' Section B (USB without serial console) proposes: setenv usb_init 'mw.l f1018100 20420000; mw.l f1018140 003E8800; sleep 3; usb start' Section C (HDby kralan - Debian
bodhi, if you go try it, I should point out: * The Kconfig logic for selecting the boot source could need some love. The mutually exclusive choice would not cover all use cases, as I gather from the code in include/configs/ox820.h, so I made them individual choices. * CONFIG_BOOT_FROM_FAT and CONFIG_BOOT_FROM_EXT4 depend on CONFIG_BOOT_FROM_SATA. * If CONFIG_BOOT_FROM_SATA is selected, butby kralan - Debian
bodhi, I forked your u-boot-oxnas and made it build the SPL, for nand or block device, with gcc up to 7. There may be cleanup to do but I didn't put much effort into that. Hope you can use it. Find it at github. I should probably add I am not sure I have done everything "the right way"(tm) and I haven't tested it yet. thanks kralanby kralan - Debian
You can use newer compilers by taking patches 410 and 420 from openwrt. But the rest of the oxnas integration is quite a mess: the board Kconfig (are the choices really mutually exclusive?) is included twice, the u-boot SPL infrastructure is not used, the ext4 function signatures have changed, etc. Is it really worth the effort getting this old u-boot right? regards kralanby kralan - Debian
I found this usable version of encode.py. Find attached 750Mhz versions of the ox820 SPL for NAND and SATA boot.by kralan - Debian
bodhi, thank your for the follow-up. I have my Medion running stable. Here's what I did: Setting up as described in this post and preparing the HDD as described here, make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820 yielded no SPL make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820_sata would build a SPL, which would reset at IDE detection, make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 oxby kralan - Debian
Following instructions here I cloned the oxnas branch from here. After editing the APLL frequency as described in bodhi's post and installing gcc-4.9 I built u-boot like this: make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 ox820_config make CC=gcc-4.9 CPP=cpp-4.9 CXX=g++-4.9 but I can't find a file resembling a SPL. Do I need extra configuration or build commands? Alternatively, doeby kralan - Debian
Stock firmware on the MEDION runs at 750Mhz, yours appears to run at 850MHz. I'd like to try the slower clock. Can you give a quick pointer where to change it? In the SPL, I guess? kralanby kralan - Debian
My kernel build completed, but I had to restart it 5 times. So, ext3 does not behave any better than ext4.by kralan - Debian
I got round to transferring the rootfs to ext3 and a quick test looked promising in the beginning, but still failed in the end. Just the intervals between occurrences of the problem might have increased a bit. I'll start a kernel compilation task overnight and report back.by kralan - Debian
Thank you for sharing your thoughts, bodhi! The filesystem is ext4, fsck -f does not complain.by kralan - Debian
~# free total used free shared buff/cache available Mem: 121804 29620 3168 720 89016 85104 Swap: 524116 44088 480028 Swap is on the internal hdd driven by sata_oxnas. 128MB is not much RAM, but I would not expect OOM conditions to go away simply by restarting a kernel build. I would expect moreby kralan - Debian
I fit a MEDION P89626 with bodhi's Debian a few days ago and it runs stable - in part. The stable part: * it has been running for four days now and is still reachable by SSH. * it was stable enough to compile its own kernel from source * memtester has been running for several hours without reporting any issues The not so stable part: * the kernel build was interrupted 4 times by aby kralan - Debian
Yes, I will go for the software watchdog. Here is what I found out about the hardware watchdog for reference: The device tree in ox820-stg212.dtb references a mpcore_wdt device: watchdog@47000620 { compatible = "mpcore_wdt"; reg = <0x47000620 0x20>; interrupts = <0x1 0xe 0x304>; clocks = <by kralan - Debian
I'd like to use a watchdog on my MEDION P89626 but cannot find a device in /dev. There is a reference to a watchdog device in ox820-stg212.dtb. Can this be accessed by a watchdog service or should I compile a software watchdog into the kernel? regards kralanby kralan - Debian
Very good! Now that the MEDION reboots, I'd like to use some sort of watchdog. I'll open a new thread for this.by kralan - Debian
I just compiled 4.4.175 (from kernel.org, your patches for 4.4.174 applied) and the problem seems gone. I can reboot again. I couldn't identify the relevant change from a quick glance at the changelog, though.by kralan - Debian
Thank you for looking into this, bodhi! It is not the DTS, the versions shipped with 4.4.54 and 4.4.174 are identical according to dtdiff. I'll adopt your habit of copying with -a, always good to improve procedures. kralanby kralan - Debian
I think my uImage is ok. The {uImage,uInitrd}.{54,174} files are just copies of uImage and and uInitrd in the respective 4.4.54 and 4.4.174 versions. They are obtained by the documented installation procedures (no appended dtb). I keep them to easily switch versions for testing - I just copy the desired version over uImage, uInitrd. As you can see form the matching file sizes, at the time of theby kralan - Debian
> Can you cold boot, i.e. recycle the power and boot the box with kernel 4.4.174? Yes, power cycling works reliably. It is just that reboot has the same effect as poweroff. > And please list your /boot directory this way and post here. total 59520 -rw-r--r-- 1 root root 111194 Mar 19 2017 config-4.4.54-oxnas-tld-1 -rwxr-xr-x 1 root root 4621760 Mar 19 2017 zImage-4.4.54-oxnby kralan - Debian
Hi Bodhi and team, I installed latest u-boot, kernel 4.4.54-oxnas-tld-1 and latest rootfs on a MEDION P89626 and it works very well. Thank you for providing the images and the instructions. After upgrading to latest kernel 4.4.174, the box does not reboot anymore after entering "reboot" at the root prompt, it just stops. Downgrading the kernel to 4.4.54 restores the reboot funby kralan - Debian