Porteus

With Porteus-Kiosk 4.9.0, the built-in "Burn kiosk ISO on selected device" succeeds, but then the kiosk device does not boot.

Affected kiosk systems (x86_64 with touchscreen):

• ASLAN-W719 device (configured for legacy boot)
• DFI-AL051 (EFI configuration).

This works:

1. "Save kiosk ISO on removable device" on a USB stick with another Linux distribution (e.g., Porteus-Desktop)
2. boot the kiosk system(s) into a live system from this USB stick
3. use "dd if=/path/to/porteus-kiosk.iso of=/dev/the_flash_device bs=16M" to write the ISO to the flash disk of the kiosk system

As far as I understand, the "Burn kiosk ISO on selected device" mechanism is also required for remote configuration updates (at least with the standard mechanism).

Hello tagon,

Seems the GRUB bootloader is to blame as isolinux works (its used for initial booting and when you save the ISO on removable media, burning with wizard switches the bootloader to GRUB).

Unfortunately its not possible to fix this issue remotely so you would need to ship the hardware to me.
If this is not an option then please try booting Ubuntu on these PCs and check if it works.

Thanks

Hello fanthom,

Interesting detail, thanks for letting me know! (So it's not a 'sync' issue, e.g. when using 'cat' instead of 'dd'.)

Sorry, shipping a device is not an option. From our tests I know for sure that Ubuntu 18.x works fine on the DFI-AL051.
As I am not at work at the moment, earliest Monday I could check if it also boots from the ASLAN-W719 built-in flash disk.

Hm... I need to check if the platform boots, when writing a new ISO image via SSH from within a running PK instance. :-)

Thanks & regards,
Hagen

tagon wrote: ↑

08 Nov 2019, 11:32

Hm... I need to check if the platform boots, when writing a new ISO image via SSH from within a running PK instance. :-)

Verified: this works:

• copy a new ISO image with scp into /root (= in RAM)
• use 'dd' to write it into the boot device (e.g., /dev/sda)

Nice! Saves a few steps during development. :-)

Our Aslan platform unfortunately does not properly 'reboot' (it halts, then you need a power cycle to reboot).
But this is not a porteus-kiosk issue, Ubuntu and other distributions behave the same.

Today I found a way to reboot the ASLAN-W719 platform (using Kiosk 5.x).
It is a little weird, because everything else - reboot, reboot -f, init 6 - did NOT work.

This finally did the trick: Even weirder: the rc.6 script does a lot of cleanup and uses 'reboot' at the end...

Added: Funny enough, this method does NOT work with Porteus Desktop 5.x. (Ubuntu also has problems and does not reboot the platform.)

Edit: typofix, mention PK5 is current platform

@fanthom: Sorry, could not find how to edit the post topic to add [Solved] at the start of the subject line - how do I do that?
On the other hand - this solves _only_ the problem of non-rebooting, not the complete Burn kiosk ISO and reboot.

tagon,

You need to edit the title of the first post in this thread.
Just did it for this thread.

FYI Users can not edit postings older than 2 or 3 weeks.

I'm not sure if this is a good idea.
Anyway - good to know.

fanthom wrote: ↑

29 Apr 2020, 10:44

I'm not sure if this is a good idea.
Anyway - good to know.

Well, the problem when trying to debug this is that Porteus Kiosk runs almost completely from RAM (except the persistent partition), so there are no shutdown logs to check for a possible reason why the reboot does not work. Or is there an option to redirect all logs to a persistent partition?

Ed_P wrote: ↑

28 Apr 2020, 16:30

FYI Users can not edit postings older than 2 or 3 weeks.

At least now I know why I could not change it (the 'edit' button was missing).

The limit is to stop SPAMmers from posting innocent postings then returning a week or two later and editing the text to include links to their site or sites. It also stops disgruntled members from deleting their old postings.