66 replies to this topic

[betacentauri]

I already wanted to give up. BUT IT WORKS

et9x00 login: root
root@et9x00:~# init 2
root@et9x00:~# killall smbd
root@et9x00:~# killall nmbd
root@et9x00:~# mount -r -o remount /
root@et9x00:~# mount -r -o remount /media/hdd/
root@et9x00:~# cd /hdd
root@et9x00:/media/hdd# cat /proc/cmdline
 bmem=216M ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs console=null consoleblank=0
root@et9x00:/media/hdd# kexec -l vmlinux.gz --append="bmem=216M ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs consoleblank=0 console=ttyS0,115200"
root@et9x00:/media/hdd# kexec -e

After some seconds I could see output in the console and then e2 started. I can now watch TV!!

The first tries I have used a running kernel with kexec enabled. The new kernel which should be loaded with kexec was an old kernel without kexec support. I thought only the currently running kernel needs it. The last time I loaded a kernel with kexec support (so both had kexec support) and it works!
Nice!

Edited by betacentauri, 3 November 2013 - 00:15.

[athoik]

That gives us fresh multiboot air! So both kernels need kexec in order to work right?

[betacentauri]

I didn't test what happens if the currently running kernel has no kexec support.

But I can say that it don't works 2 successive times right after the other without reboot. I mean
1. kexec -l ...
2. kexec -e ...
-> new kernel boots
now no reboot!
3. kexec -l ...
4. kexec -e ...
Nothing happens. I see nothing in the console. I have tested this 2 times and in both cases it didn't work.

So not perfect. And to have a real multiboot you'll need a second rootfs. Can the second rootfs be stored on a usb stick (can the kernel load it)?

Edited by betacentauri, 3 November 2013 - 00:40.

[athoik]

Why not? If you extract data on a usb partition then you can boot by specifying root=/dev/sdX

(At least it supposed to work like that)

[betacentauri]

It was too late yesterday I thought about direct boot from USB stick and that that wasn't possible on some PCs in the past. But this is different. Kernel is loaded and if the kernel can read the fs it should work.

[pieterg]

Just use the 'bootdelay' cmdline option when you use an usb rootfs

[athoik]

On Dreambox with 3.2 kernel (with patches 303 and 330 from https://dev.openwrt....1904&order=name) i get the following:

/ # mount /dev/sdb1  /media/sdb1/
/ # kexec -l /media/sdb1/sdb4.gz --append="root=/dev/sdb4 rootdelay=10 rw"
/ # umount /media/sdb1/
/ # mount -r -o remount /
[   82.254000] EXT4-fs (sdb4): re-mounted. Opts: barrier=1,data=ordered
/ # umount /proc/
/ # kexec -e
[   87.471000] Starting new kernel
[   87.472000] Will call new kernel at 003d5e40
[   87.472000] Bye ...
[   87.472000] ------------[ cut here ]------------
[   87.472000] WARNING: at kernel/smp.c:464 smp_call_function_many+0x118/0x37c()

[   87.472000] Modules linked in:
[   87.472000] Call Trace:
[   87.475000] [<803dcb18>] dump_stack+0x8/0x34
[   87.475000] [<8002e240>] warn_slowpath_common+0x78/0xa4
[   87.475000] [<8002e2f4>] warn_slowpath_null+0x18/0x24
[   87.475000] [<80067150>] smp_call_function_many+0x118/0x37c
[   87.475000] [<800673e0>] smp_call_function+0x2c/0x3c
[   87.475000] [<80011b14>] r4k___flush_cache_all+0x1c/0xa0
[   87.475000] [<8000da5c>] machine_kexec+0x114/0x148
[   87.475000] [<8006ee68>] kernel_kexec+0x84/0x8c
[   87.475000] [<8004306c>] sys_reboot+0x1e8/0x1f8
[   87.475000] [<8000c7e8>] stack_done+0x20/0x44
[   87.475000]
[   87.475000] ---[ end trace 517dc315144d3fd3 ]---
[   87.475000] ------------[ cut here ]------------
[   87.475000] WARNING: at kernel/smp.c:325 smp_call_function_single+0x174/0x224
()
[   87.475000] Modules linked in:
[   87.475000] Call Trace:
[   87.475000] [<803dcb18>] dump_stack+0x8/0x34
[   87.475000] [<8002e240>] warn_slowpath_common+0x78/0xa4
[   87.475000] [<8002e2f4>] warn_slowpath_null+0x18/0x24
[   87.475000] [<80066e04>] smp_call_function_single+0x174/0x224
[   87.475000] [<800673e0>] smp_call_function+0x2c/0x3c
[   87.475000] [<80011b14>] r4k___flush_cache_all+0x1c/0xa0
[   87.475000] [<8000da5c>] machine_kexec+0x114/0x148
[   87.475000] [<8006ee68>] kernel_kexec+0x84/0x8c
[   87.475000] [<8004306c>] sys_reboot+0x1e8/0x1f8
[   87.475000] [<8000c7e8>] stack_done+0x20/0x44
[   87.475000]
[   87.475000] ---[ end trace 517dc315144d3fd4 ]---
[    0.000000] Linux version 3.2-dm800se (athoik@pc) (gcc version 4.8.1 (GCC) )
#1 SMP Sun Nov 3 11:42:12 EET 2013
[    0.000000] Fetching vars from bootloader...
[    0.000000] Early serial console at MMIO32 0x10400b00 (options '1000000n8')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] Options: sata=1 enet=1 emac_1=0 no_mdio=0 docsis=0 pci=1 smp=1 mo
ca=0 usb=1
[    0.000000] Using 256 MB RAM (from straps)
[    0.000000] irq 104, desc: 804a75c0, depth: 1, count: 0, unhandled: 0
[    0.000000] ->handle_irq():  80077a00, handle_bad_irq+0x0/0x2d4
[    0.000000] ->irq_data.chip():   (null), 0x0
[    0.000000] ->action():   (null)

[athoik]

@OpenPLi, @everybody

 

 

Do you think is possible to create a fundraising campaign (kickstarter?) in order to implement multiboot using kexec (or something equal)?

 

Of course the results of this effort must be opensource (in order everyone to benefit). Also having "sponsors" (manufactures) won't hurt either.

 

Did this ever happened in Enigma2 scene? What the funding goal must be?

Edited by athoik, 2 January 2014 - 12:34.

[betacentauri]

Hi athoik,

 

as you can see it works on my xtrend box. So you only need to build a little plugin which makes it simple for a user to execute the command and at best to generate a rootfs on a usb stick. So no magic. Ah I forgot, you'll have to enable it in the kernel config, but that's also easy.

 

If you want to make it runnable on older kernels or want to find out why it's not possible to do it several times right after another (see my posts) you'll need a very experienced kernel hacker. I guess writing to the kernel mailing lists might help more than a fund raising, because also with money you'll need a very good coder....

[athoik]

Hello betacentauri,

 

 

I would like to send email at linux-mips but since brcmstb arch doen't exist on kernel yet would required at least the kernel to officially support brcmstb.

 

Having brcmstb on kernel, most probably you can build latest kernel and report any issues.

 

So i guess the first step is to contact Broadcom?

 

PS. Recently brcmstb for arm arch submitted for inclusion (http://lwn.net/Articles/575099/), <thinking loud>brcmstb for mips why never submitted?</thinking loud>

[betacentauri]

Well, I would nevertheless write to linux-mips mailing list. But I guess the biggest problem is, that we cannot change to another kernel version because of closed source drivers. So you'll perhaps need to backport many many things to make it working. And I guess you won't find anybody who is willing to spend much time to adapt an antiquated kernel (I'm speaking of dreambox and vu+ kernels, xtrend is relativly "new")...

Edited by betacentauri, 7 January 2014 - 21:13.

[Lost in Space]

You are insulting Linus and lot of popular Linux distrubitions by such a statment

 

The Debian on my PC runs a perfectly stable 3.2 Linux Kernel and you can read also on their mailing list why this is the case. So DMM did a very good an wise choice in my opinion, as there is NO major Linux functionality not available on this stable kernel version level..

 

But you are not fully understanding the kecex problem either.

 

Do a simple check what happens to the hardware if you unload and imediately reload their closed Dreambox drivers supporting the interesing hardware parts - the box wil be stuck instantly and/or kernel will be crashing like hell.

 

Which means the whole kexec concept instantly sucks with such drivers as you could only load plain vanilla linux drivers before switching which makes the boot useless.

 

And if based on your argument you can only support same kernel and drivers ... well then suddenly chroot booting is the perfect and working solution

Edited by gutemine, 7 January 2014 - 21:30.

[athoik]

Having (vanilla) kexec kernel as a bootload loader and then the dreambox/vu/xtrend/... kernel booting is the goal.

 

The 1st kernel will only be responsible to recognize boot devices like usb and construct the kexec parameters to boot into 2nd kernel.

 

The "closed" source driver will do the magic work when the 2nd kernel boots.

 

There will be no 2nd kernel to 3rd kernel kexec (so hopefully no problems with drivers).

 

Having an LTS Kernel like 3.2 is not bad, is very good for servers (mainly), but for an STB where new WIFI/DVB-T sticks are pop up like mushroom is not ideal (just take a look how many posts and users requesting new drivers for sticks). Since Dreambox is commited to LTS kernels, it would be nice to switch to next LTS kernel 3.10.

 

(Now regarding VU+, honestly WTF are they thinking releasing 3.1/3.3 kernels, and why not 3.3 for all models, who knows... marketing tricks...)

[betacentauri]

Oh, I was wrong. I really thought that some dreamboxes still use old 2.x kernel.... You see I'm not the right guy here as I'm also not very interested in multiboot...

I don't say that old kernels are generally bad, but I as you can see kexec seems to work on 3.8 kernels much better than on 3.2 kernels. Or the problems are caused by the dreambox drivers. Perhaps athoik you can test without loading these drivers.
But as said before it works here on my box with loading the closed source drivers... but it's only a xtrend :-0

Regarding chroot: You'll need images which use the same kernel, right? I know several images which compile the kernel with different options and I guess that can make problems. Or?

[Lost in Space]

It is not adding any real value to boot one kernel and then just starting the real one. If you don't have human interaction from the first one (like choosing which image vie remote with a menu on the Tv screen) why running it at all ? This is also why the approach to use a bootloader binary (which is also a kind of strange minimal standalone kernel binary to be able to be started by the bios) is limited, because normal bootloades include only access for PC hardware (VGA screen, keyboard,...) . The only way to get access to the TV and remote devices is by loading the real drivers and they load only in a real kernel or have more or less troubles then to switch to another one.

 

And it is not my fault that your boxes have just the dumb standard bios only able to boot a single kernel from the flash rawdevice (and not even jffs2 or ubifs as this would allow multiple kernel as Dreanboxes could do if boot partition is big enough). Using a kernel from flash for chaining  this to a nother kernel somewhere else is an expensive measure as the bios should (and does) support this and a minimal bootloader could do this also, but this is then also struggling where to store his setings if only a raw device is available and you don't have access to the bios settings which get partially passed to the kernel when starting.

 

These problems ARE solvable by the way, but if you are lacking the understanding how the pieces are or should be working together then shouting we need kexec or lets cry for help at the mailing list or blame the drivers will not get you much further.

 

I'm sorry for some hard words, but you asked for feedback.

 

And I will not explain the advantages or disadvantages of chroot booting here, as the board clearly states that multibooting is not needed and not supported and I respect this decision. The only point is that if you need a feature the flash kernel lacks, then put it in the flashkernel and all other images will benefit - like i do for example by having initramfs patch in my OoZooN Images in Flash, or fuse driver included there already. Or if you have latest image in Flash, all chrooted mages will use its lates kernel and drivers (until this breaks their enigma2 from running) You can even run VU or ET/XT Images on Dreamboxes because of this BTW.

Edited by gutemine, 8 January 2014 - 08:33.

[mirakels]

Gutenmine, I dont think it is forbidden to discuss and develop multiboot on this board. 

 

It only is that the openpli core developpers have a feeling they don't need it and have not invested time to analyse and support it, hence it is unsupported.

This does not mean it is forbidden!

When others create a clear, proper and usefull implementation I see no reason why this cannot  be discussed and implemented in some way or another.

 

So if you are in the clear on what is needed and how to do it, please feel free to help betacentauri and athoik is this endeavour.

[Lost in Space]

I have created 12 different ways ob booting dreamboxes (Barry Allen includes 4 of them) and I tried out another handfull of others including kecec btw. 

 

So there is no really need for me to develop anything here or explain how to do it as I'm not even supporting PLi images anymore.

 

And yes, I would like to learn from others or see better solutions too ... and I'm still waiting.

Edited by gutemine, 8 January 2014 - 16:29.

[cobus]

Why not you have the expertise ? support the boys who working on it.

[Lost in Space]

Because for me it would be boring and a waste of time to re-duplicate - come up with NEW Ideas and get me interested.

 

Wishfull thinking and dreaming alone didn't get us to the moon. I will not discourage anybode, but you neeed a sharp eye to see possibilities and roadblocks to find your way.

Edited by gutemine, 8 January 2014 - 18:12.

[mirakels]

Well, learning curves may be high, and take time. If you just gain knowledge and then tell you are bored to help others then what are you doing here anyway?

So while you are here why not help these guys. And who knows they might be clever and come up with good things you did not think about yet. So there is always a chance you get something in return. And I simply won't believe you invented all the wheels you created just by yourself without the knowledgable help from others.

You don't need to support openpli images if you don't want to, but just get these guys on the way. At least in your own words you have the knowlegde and experience.

 

At least it would be very disappointing seeing your're only saying 'been there, done that' and laughing out lout...