Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: helasz on September 25, 2013, 06:34:11 AM
-
Hi All,
I am using Core 5.0 with custom kernel (last longterm one: 3.10) in VirtualBox (4.2.18). In patching the kernel I had to slightly touch the tmpfs-root.patch. Although the kernel works fine in many aspects, it gives
swapon /dev/zram0: Invalid argument
May this caused by manipulated tmpfs-root.patch?
The fact is that same error came up in mounting the cdrom. In that case I needed to load manually the isofs module to solve the problem. Is there some module to load or whatever I am missing for zram?
-
Do you have zram enabled in your config?
-
I have not disabled (nozswap). If I disable it, no error message comes up.
-
In your custom kernel config.
-
I have in kernel config:
CONFIG_ZSMALLOC=y
CONFIG_ZRAM=m
CONFIG_ZCACHE=m
I guess these are the ones needed. Both modules are loaded when I check after booting with lsmod.
-
I do not know is it matter or not, but in piCore with kernel 3.11.1 these are built into the kernel:
CONFIG_ZSMALLOC=y
CONFIG_ZRAM=y
CONFIG_ZCACHE=y
and not modules. Worth to try.
-
Thank you for the suggestion, Béla! I will give it a try and get back with the result (probably only tomorrow).
-
I did recompile my kernel with
CONFIG_ZSMALLOC=y
CONFIG_ZRAM=y
CONFIG_ZCACHE=y
Unfortunately the error message keeps showing up.
I read in aufs-util README that after kernel 3.9 each filesystem needs to appear among aliases as "fs-fsname" (fs-aufs for instance), maybe some similar new restriction applies? I found a known case when swapon returns "invalid argument", if the filesystem it needs to reside on does not support it (btrfs, see: http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem (http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem)).
Since no argumernt was given to swapon other than the mandatory device name, maybe busybox' swapon has some issue with the 3.10 kernel? I will try to inject the one from util-linux, let us see.
Any suggestion is welcome anyway. I will keep investigating further and get back with findings.
-
One step further: by injecting swapon (along with needed libmount) some further details showed up. The error message is now:
swapon: /dev/zram0: read swap header failed: Invalid argument
After trying "sudo mkswap /dev/zram0 2000", "swapon /dev/zram0" returns exactly the same error message.
Does /dev/zram0 need to be initialzed somehow?
-
Does /dev/zram0 need to be initialzed somehow?
It is done by TC automatically if nozswap boot option is not used. zswap works as expected both with TC 5.0 and piCore 5.0 which means that Kernel 3.8.10 supports zswap correctly with busybox. Use the stock TC kernel config as a basis for your custom kernel.
-
I read in aufs-util README that after kernel 3.9 each filesystem needs to appear among aliases as "fs-fsname" (fs-aufs for instance), maybe some similar new restriction applies?
Could you provide a direct link to that please, I couldn't find such a reference.
I found a known case when swapon returns "invalid argument", if the filesystem it needs to reside on does not support it (btrfs, see: http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem (http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem)).
That is totally unrelated to anything else but btrfs.
I'd suggest you test your kernel on bare metal.
-
I read in aufs-util README that after kernel 3.9 each filesystem needs to appear among aliases as "fs-fsname" (fs-aufs for instance), maybe some similar new restriction applies?
Could you provide a direct link to that please, I couldn't find such a reference.
I found a known case when swapon returns "invalid argument", if the filesystem it needs to reside on does not support it (btrfs, see: http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem (http://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem)).
That is totally unrelated to anything else but btrfs.
I'd suggest you test your kernel on bare metal.
It is to be found in the documentation of aufs3.10, and namely:
http://sourceforge.net/p/aufs/aufs3-standalone/ci/aufs3.10/tree/Documentation/filesystems/aufs/ (http://sourceforge.net/p/aufs/aufs3-standalone/ci/aufs3.10/tree/Documentation/filesystems/aufs/)
The text reads:
Note: Since linux-3.9, every filesystem module requires an alias
"fs-<fsname>". You should make sure that "fs-aufs" is listed in your
modules.aliases file if you set CONFIG_AUFS_FS=m.
It is true that the btrfs is unrelated directly to zswap, but at that point of my search it was not clear, whether "Invalid argument" has anything to do with swap "filesystem".
I will give it a try on bare metal and get back with the results. Also Béla's suggestion of using official TCL 3.8 kernel config is reasonable. Thanks for both!
-
Bare metal does not help in anyway.
Let me try the 3.8 config.
-
Using as base the stock TC 3.8 kernel config did give the same result: Invalid argument
I noticed however a new option about BCACHE which is supposed to cache content from slower drives' content. I guess it has nothing to do with my issue, however I did include it (BCACHE=y)
Not having other clue I replaced busybox's mkswap with the util-linux' one. Now the error message claimes that the device size is 0KB although it should be at least 40KB.
-
Using as base the stock TC 3.8 kernel config did give the same result: Invalid argument
I noticed however a new option about BCACHE which is supposed to cache content from slower drives' content. I guess it has nothing to do with my issue, however I did include it (BCACHE=y)
Not having other clue I replaced busybox's mkswap with the util-linux' one. Now the error message claimes that the device size is 0KB although it should be at least 40KB.
Starting point is, that it works in the stock Core 5.0 (5.0.1) which means proper kernel config and BusyBox. First I would make a kernel with the original config in your development environment to verify everything is OK. When it works, you can start changing config and see result.
-
I found it. I did change /almost a year ago/ some lines (for a reason) in /etc/init.d/tc-config. Bad decision bad consequences. With the original tc-config it works without replacement of any part of busybox.
Sorry for having taken so much of your precious time. Thanks for the help curaga, bmarkus and tinypoodle!
[I am using since TC 4.0 the initram put togehter of four parts: base, kernel modules, apps, profile. I put the changed tc-config in the fourth part, that is why I overlooked it while tracking down the issue.]