I have ChaosCalmer15 and wanted to change cmdline.txt but it is not inside /boot
Where is it??
ChaosCalmer is very outdated, is now considered vulnerable to me threats and shouldn't be used.
What the router booted with should be at /proc/cmdline if chaos calmer is similar to current in that regard.
It was not a question. I have milion small and one BIG reason to use it. Not to go to the newest openwrt
Thsnx, i will check it
I believed I know already "a lot" about linux but reality is completely different, I am going crazy...
Yes, cmdline is inside /proc folder, I can even type "cat cmdline" and I can see what I expect
But, size of cmdline is 0 and opening it with vi it is really empty! How is it possible cat shows it but it is not really there?!?!
Where the f**k it is? I need to change it. Is is packed somewhere? Or something else?
It is not even link to something real....
which router you are talking about?
Note that for most routers there is u-boot bootloader or something similar.
Not everything works like with desktop X86 Linuxes with grub.
1 Like
The usual way to change the kernel cmdline is via kconfg in the build system.
The other way is (as mentioned already) to extract/modify/rewrite the bootloader that starts the kernel (with the corresponding cmdline). That's more for experts though.
I use orange pi zero. Already modified/added my script to initramfs. Now I need to modify cmdline to execute it. (gunzip, cpio, added script, cpio, gzip)
I am shocked why "cat" can see cmdline, but vi editor not. Also its size is 0.
Ok, I will try to modify u-boot. Do you know which file is it for opizero?
Some (most?) files in proc actually link to pieces of code in kernel modules or binaries. When a read attempt is made to them, code is triggered to print the latest information. This way the file always contains the latest. It's like a real-time window into the kernel or application.
Sorry if I knew you wanted to modify the cmdline I would have mentioned the bootloader earlier. This is much easier with grub (/boot/grub/grub.conf I think). Other devices sometimes can modify the uboot boot parameter.
Anything else is beyond me.
the file "cmdline.txt" in boot partition (shown as folder in a booted system) is a Raspberry Pi thing and is NOT a linux standard (that file is read by Raspberry Pi's bootloader, that is unique to Raspberry boards). Text files in Linux don't have any ".txt" extension, that's a Windows thing.
/proc/cmdline is a READ-ONLY and VIRTUAL file created by the kernel to communicate data in a simple way to applications, like all other stuff in /proc and /sys, editors can't read it, you can't change it.
All different devices and boards boot Linux in a different way, and yes it's a huge pain in the ass even for experts. PC and servers all follow a standard and there it's at least somewhat sane.
By looking at the installation process for Allwinner devices like your Orange Pi Zero here https://openwrt.org/docs/techref/hardware/soc/soc.allwinner.sunxi#installing_openwrt
it seems the u-boot configuration that sets the kernel commandline is in the first partition of the SD card, and called boot.scr
I don't know if this first partition is even mounted in OpenWrt (as this is just for bootloader configuration), nor if OpenWrt on the Orange Pi has the tools to edit the file (as it is usually generated by the build system and never changed), so you probably need to remove the MicroSD card and read it from a PC or virtual machine with Linux/Ubuntu/whatever.
boot.scr file is NOT a text file and must be generated from a Linux system with the commands explained here https://github.com/linux-sunxi/u-boot-sunxi/wiki#bootscr-support
To know the current contents of the boot.scr file (needed if you want to generate a new working boot.scr) you can open it with a text editor. It will probably complain and refuse to allow edits to the file. You will see some garbage text at the beginning (binary information, this is not a true text file as I said) and then the uboot configuration in plain text.
For example I opened the boot.scr of Orange Pi Zero from the current download images:
'V\B2\AF\92O^X/\00\009\00\00\00\00\00\00\00\00\91?\B3\B8\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\001\00\00\00\00setenv fdt_high ffffffff
setenv loadkernel fatload mmc 0 \$kernel_addr_r uImage
setenv loaddtb fatload mmc 0 \$fdt_addr_r dtb
setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r - \$fdt_addr_r
run uenvcmd
and therefore if you create a new boot scr you need to create a text file with the following contents
setenv fdt_high ffffffff
setenv loadkernel fatload mmc 0 \$kernel_addr_r uImage
setenv loaddtb fatload mmc 0 \$fdt_addr_r dtb
setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r - \$fdt_addr_r
run uenvcmd
Any "kernel command line" argument you want to add, must be added in this line, after the "setenv bootargs" (usually at the end of the line is OK)
setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
Then use the commands explained in the link above to convert the text file into a boot.scr file, then you can place this in your SD card boot partition to replace the other file.
2 Likes
Thank you for your extensive explanation!
In a meantime I found a workaround for this: I did not change cmdline but I changed function local_mount_root() in /scripts/local in initrd.img (I wanted to overrule this function with new script)
But it is not a problem I am facing. I try to explain:
The raspbian system now has got a new function they call "overlayFS". If I activate it it makes in /boot a new initrd.img file and from then on everyting runs exlusively in RAM. I can even lock SD card with sdtool aplication. This means SD can not be changed in no way. It is LOCKED. But system is normally booting and working.Of course, any change I make is lost after reboot. All changes are made only in RAM.
The OpenWrt has got also and even by default this overlay and file initrd.img. They say, it is running in RAM.
BUT (capital BUT) if I make changes they are saved in overlay which is in flash. Permanent. I do not need to make more changes, so I tried also to lock SD card. But OWrt is not booting anymore. It crashes on root fsck test.
Here is fragment of log with failing boot process (SD locked):
Begin: Will now check root file system ... fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1
/dev/mmcblk0p1: recovering journal
/dev/mmcblk0p1: Superblock needs_recovery flag is clear, but journal has data.
/dev/mmcblk0p1: Run journal anyway
/dev/mmcblk0p1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck exited with status code 4
done.
Failure: File system check of the root filesystem failed
Here is the fragment of the same card but unlocked:
Begin: Will now check root file system ... fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1
/dev/mmcblk0p1: clean, 6727/89584 files, 82807/358144 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.
Definitely the local_mount_root() was executed. Now I do not know how they do it in raspbian.
Do they simly not perform fsck check? Or ignore results? Or mount root with some different flags?
Any idea will be deeply appreciated. (I want to try to look inside raspbian initrd.img......)
One more question:
it is clear that overlay systems behave different for raspbian and for OpenWrt.
But, it would be "the same" if this is true:
OpenWrt is running in RAM and all changes are made in RAM, but later, seconds, minutes (or by sync command) are these changes also stored in overlay in flash?? Is it possible?
Because I noticed strange behaviour with SoftEther VPN server - if I make any change in VPN configuration, I have to wait some time (seems 5 minutes) to get these changes permanently stored. If it reboot OpenWrt immediatelly the changes are not stored, they are lost?! I tried also sync but the only safe way to store them permanently is to wait........
No. That is not true (for most routers). Normally flash is written pretty quickly.
For most routers, the overlayfs serves as a read/write extension to the read-only ROM ( =flashed firmware). overlayfs makes that as a transparent combination of RO /rom and RW /overlay as one root "/". That makes is possible to reset all changes to revert back to the flashed clean firmware with defaults.
(But your Raspberry with SDcard may be one of the exceptions, I think. So most of the OpenWrt documentation may be a bit misleading for you.)
It seems you locked the sdcard while the filesystem was still writing things.
So on boot it sees it is "dirty" and tries to fix it with fsck, but the sdcard refuses writes as it is locked. So fsck fails.
Try making the changes you want, rebooting, and then lock the card.
SoftEther VPN server
OpenWrt writes to flash as soon as possible. Any wait is more likely to be SoftetherVPN's fault, it's a very "independent" application doing plenty of things on its own.
I removed fsck from /scripts/functions and now openwrt starts
Problem was I was playing with initrd but it is not used at all!! Instead uInitrd is used. Both have the same gzip body but uInitrd has got header made by mkimage apk
I deleted initrd and no problem, i do not understand what for it is distributed?
initrd is converted in uInitrd to be booted by the board's bootloader. If you make changes that cause the system to generate a new initrd you must generate a new uInitrd too.
I don't know about OpenWrt updating the initrd in a normal system (on x86 aka PC hardware) where it actually uses initrd on boot, I thought the only way to update it was doing a firmware upgrade.
I have no idea why it's shipped in a release image, I guess that none cared much about wasting a tiny bit of space on a multiGB SDcard system anyway.
Now I can see a bit more light into the problem:
The OpenWrt I use for OrangePiZero I downloaded a long long time ago from Sunxi Orange Pi site. It was not downloaded from openwrt site. Surprisingly they compiled it somehow on armbian distribution. So it has got that "uInitrd system". But genuine openwrt does not have it. I found it also on Sunxi Armbian for Orange Pi disrtibution.
So I was lucky to remove fsck and now I copy all VPN files into /tmp/vpn a run it from there. The SD is locked and it works! No wear out of SD card, no power failure problem.
But I do not know how differ those systems with /boot folder with uInitrd and those systems even without /boot folder and no uInitrd???? what are their "names" I can reffer to them?
OpenWrt is optimized for flash usage. It does not write anything to root partition unless you are changing configuration, there was no need to lock sdcard.
Maybe some packages from package feed write, but that's something that should be fixed in the package, it should not do that.
To be fair, also Armbian/Debian does not write that much to sdcard by default, just disable logging or set it to log in RAM only, and check the packages you install for things that are written constantly.
Surprisingly they compiled it somehow on armbian distribution.
It's more likely the old OpenWrt build system was fixed in the 3 years or so after Chaos Calmer release.
OpenWrt build system does NOT work on ARM, it's only designed for x86 PCs, because of performance reasons.
I found it also on Sunxi Armbian for Orange Pi disrtibution.
Armbian is a small modification of Debian Linux to run on some ARM devices, many things work the same as on PC Linux (so it is is easier to find documentation to use it).
Like Debian it does modify initrd depending on what packages you install, so it re-generates the initrd, and then converts it into uInitrd for booting. I think it does not care about removing the initrd file because it assumes you have a lot of space in a SDcard.
But I do not know how differ those systems with /boot folder with uInitrd and those systems even without /boot folder and no uInitrd???? what are their "names" I can reffer to them?
I'm not sure I understand the question. I try to answer.
There is no "name", and you can boot the same device in both ways.
An initrd is an intermediate optional step in boot process. It is a little temporary "root" partition with some applications and tools needed to actually mount the real root from disk. Boot without initrd goes like this:
Kernel is loaded and executed, it will search for root filesystem set in command line or dts, mount it and start executing the programs there to start the system.
If you have initrd it is like this:
Kernel is loaded and executed, it starts executing the programs in initrd, these programs do something to find real root filesystem, and mount it, then start executing programs there to start the system
Using an initrd allows to add support for new hardware or file systems to the kernel without recompiling the kernel, it is also used if you want to enable encrypted partitions, RAID or LVM.
This is most common for Linux distributions on PC, like Debian, Ubuntu, OpenSUSE, ecc because they must support a lot of hardware and possibilities without using a huge kernel.
On an embedded device this isn't important for boot process. All hardware and filesystem support for booting is compiled in the kernel and never changes. You can't add additional cards to a router, so you always know what hardware it has. You don't usually need encrypted filesystems, RAID or LVM.
Openwrt was born on embedded devices so they don't really need to use initrd/uInitrd. All hardware needed to boot is compiled in the kernel.
They just make these files if the bootloader wants them, or if the person adding support for the device is lazy or not very experienced and is just copying code from Armbian or other places where they use initrd.
1 Like