66 replies to this topic

[athoik]

Hello,

One of the problem (for simple users) is the absense of real multiboot solution. Current solutions they are mixing the kernels and causing more problems than solving. Also OpenPLi doesn't support them (because of the problems causing).

I read some old discussions and they where mentioning the kexec system call as the ultimate solution to the problem.

Moreover i see the existance of the kexecboot project where mipsel architecture is supported! Additionally kexecboot exists allready under meta-openembedded.

multi machine support: we build for many architectures using OpenEmbedded (tested on arm, mipsel and x86/x86_64)

Do you think it is possible to use above project and provide multiboot for all mipsel boxes?
Did someone tried that and fail?
If someone has hints, ideas or recomendations i would would like to hear them.

http://en.wikipedia.org/wiki/Kexec
http://kexecboot.org/

[Erik Slagter]

My gut feeling says that booting two kernels after each other, without a bootloader and second stage having had it's influence, may not work (properly).

 

OTOH if the final linux kernel would be loaded from an intermediate boot loader, a sort of third stage boot loader, I guess it could work. But then you'd have to develop such a thing and there would be no use for kexec.

[Sjaaky]

OTOH if the final linux kernel would be loaded from an intermediate boot loader, a sort of third stage boot loader, I guess it could work. But then you'd have to develop such a thing and there would be no use for kexec.

A kernel with kexec is supposed to be that third stage loader. One with tremendous flexibility. If the closed driver can be unloaded properly, ie without leaving the hardware in a state that the driver doesn't recover from when it is loaded, there shouldn't be any problem, right?

[Erik Slagter]

That's exactly what I am worried about. That normally never happens so it's probably not foreseen in the drivers. Also even booting a kernel without the drivers may already mess up enough.

[pieterg]

you don't need to unload the driver I think.
However, if you want to use a kernel with the manufacturer driver, you might be out of luck, because most likely kexec only works on very recent kernels.

[mirakels]

kexec has been there at least since linux 2.6.28

[pieterg]

For mips(el) as well?
(mips is usually one of the last platforms to get support for new features)

[athoik]

CONFIG_KEXEC exists but is not set.

 

./recipes-linux/linux/linux-dreambox-3.2/dm7020hd/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-dreambox-3.2/dm500hd/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-dreambox-3.2/dm800se/defconfig:CONFIG_KEXEC=y
./recipes-linux/linux/linux-dreambox-3.2/dm8000/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-xp/xp1000/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-etxx00/et6x00/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-etxx00/et4x00/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-etxx00/et9x00/defconfig:# CONFIG_KEXEC is not set
./recipes-linux/linux/linux-etxx00/et5x00/defconfig:# CONFIG_KEXEC is not set

 

I enabled it for dm800se, there was no compile error. I build kexec-tools no compile error.

 

I am trying to run new kernel with kexec no luck yet.

 

root@dm800se:/var/volatile/tmp# kexec -d -l /boot/vmlinux-3.2-dm800se.gz --append="root=/dev/sdb4 rootdelay=10 rw console=null bmem=1
16M@140M"
kernel: 0x763cd008 kernel_size: 502730
kexec_load: entry = 0x3d5a20 flags = 80000
nr_segments = 2
segment[0].buf   = 0x763ce008
segment[0].bufsz = 501300
segment[0].mem   = 0x1000
segment[0].memsz = 522000
segment[1].buf   = 0x429c50
segment[1].bufsz = 100
segment[1].mem   = 0x523000
segment[1].memsz = 1000
root@dm800se:/var/volatile/tmp# sync; umount -fa ; kexec -e
umount: can't forcibly umount /dev/pts: Device or resource busy
umount: can't forcibly umount /var/volatile: Device or resource busy
umount: can't forcibly umount /dev: Device or resource busy
umount: can't forcibly umount /: Device or resource busy
umount: can't forcibly umount /: Device or resource busy

[Erik Slagter]

You might want to try a mount -o remount,ro instead. I don't think that's the cause though. What does dmesg say?

[athoik]

Remounting / as ro says busy. Without mount point it displays all mounts.

root@dm800se:/var/volatile/tmp# mount -o remount,ro 
rootfs on / type rootfs (rw)
/dev/root on / type ext4 (rw,relatime,barrier=1,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=67888k,nr_inodes=16972,mode=755)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
tmpfs on /media type tmpfs (rw,relatime,size=64k)
/dev/sda1 on /media/usb type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sdb1 on /media/sdb1 type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sdb2 on /media/sdb2 type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sdb3 on /media/sdb3 type ext4 (rw,relatime,barrier=1,data=ordered)
/dev/sdb4 on /media/sdb4 type ext4 (rw,relatime,barrier=1,data=ordered)
tmpfs on /var/volatile type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
root@dm800se:/var/volatile/tmp# kexec -d -l /boot/vmlinux-3.2-dm800se.gz --append="root=/dev/sdb4 rootdelay=10 rw console=null bmem=1
16M@140M"
kernel: 0x76941008 kernel_size: 502730
kexec_load: entry = 0x3d5a20 flags = 80000
nr_segments = 2
segment[0].buf   = 0x76942008
segment[0].bufsz = 501300
segment[0].mem   = 0x1000
segment[0].memsz = 522000
segment[1].buf   = 0x429c50
segment[1].bufsz = 100
segment[1].mem   = 0x523000
segment[1].memsz = 1000
root@dm800se:/var/volatile/tmp# kexec -e

After running the kexec -e nothing happens. Maybe i need to get console in onder to see what is going on!

[Erik Slagter]

Hmm yeah, that was to be expected. If only one process (e.g. enigma) has a file open for writing, a r/o remount won't succeed.

 

What does dmesg say?

[athoik]

After running kexec -l no entry is inserted on dmesg.

[   68.195000] audio_cdb_itb_error_isr! underflow
[   68.197000] ch0: lock
[   68.197000] RAP sampling rate info isr (48000)
[   68.197000] eModeChange Isr.. set source_changed_event!
[   68.589000] VIDEO0: first pts 0xa621e062
[   68.589000] VIDEO0: resolution changed (720 576)
[   68.589000] VIDEO0: aspect changed 2
[   68.589000] set current avs auto aspect to 16:9
[   68.589000] disable wss on display 0
[   68.589000] set wss 7 on display 1
[   68.589000] set sb to 3(1)
[   68.739000] enable tsm0
[   69.109000] VIDEO0: progressive changed (0)

When i run kexec -e i cant execute something beyond that point (it freezes).

[Erik Slagter]

Bummer...

[betacentauri]

You can remount / read only. I do it in my tool ofgwrite (but not for dreamboxes...).

I do something like this:

init 2
killall nmbd
killall smbd
killall rpc.mountd
killall rpc.statd
sync
mount -r -o remount /

Sometimes hddtemp make also problems. To try to kill all "unnecessary" processes until remount works.

[athoik]

Thanks betacentauri,

Remounting now works, but again box freezes. \\

I need to get console. (it is possible from miniusb right?)

[betacentauri]

I tried to umount root via pivot_root. Unfortunately I wasn't successfully.

 

The question is, is really the mounted root the problem or something else. What kernel do you use?

E.g. here are patches for 2.6.32.10:

https://dev.openwrt.org/ticket/7115

[mirakels]

For mips(el) as well?
(mips is usually one of the last platforms to get support for new features)

Hm, ok could be. This was on arm.

[athoik]

The question is, is really the mounted root the problem or something else. What kernel do you use?

I use the same kernel Dreambox have (3.2) with CONFIG_KEXEC=y.

[betacentauri]

Then take a look here:

http://www.spinics.n...s/msg43378.html

 

Or search for other patches...

Edited by betacentauri, 26 October 2013 - 13:17.

[athoik]

Then take a look here:
http://www.spinics.n...s/msg43378.html
 
Or search for other patches...

It think i will try the patch

I've just now checked and the latest kernel.org's stable kernel (3.2.6) does not seem to include this either. Ok, since I know the secret already I'll fix it for myself anytime, but maybe some kind soul could just submit this _one_ line upstream? I'd say this feature is really handy in some cases.