eMMC devices being probed inconsistently by kernel driver

Guthrie Hamish

unread,

Sep 10, 2025, 4:19:41 AMSep 10

to swup...@googlegroups.com

Hi,

We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.

For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.

Any ideas?

Hamish Guthrie
Senior Embedded Software Engineer

Kistler Instrumente AG

Eulachstrasse 22, 8408 Winterthur, Switzerland

Direct +41 52 2241 642, Main Office +41 52 224 11 11
hamish....@kistler.com, www.kistler.com, myKistler, Contact Service

Stefano Babic

unread,

Sep 10, 2025, 4:35:24 AMSep 10

to Guthrie Hamish, swup...@googlegroups.com

Hi Hamish,

On 9/10/25 10:19, 'Guthrie Hamish' via swupdate wrote:
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same
> device driver and normally, the eMMC device comes up on /dev/mmcblk1 and
> the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed
> first and as a result is associated with /dev/mmcblk0.

It is common, it depends which controller has finished the probe first,
and this happens.

>
> For our regular update mechanism I use the /dev/disk/by-partlabel/
> <partition-label> device, so this does not effect us, however, we also
> provision our devices in production using swupdate and our .swu image
> contains partitioning information, and for that I have a partitions
> section which needs to know the device to partition, and there I use /
> dev/mmcblk1, but if the devices are probed incorrectly, this does not
> work, and of course there is no similar symlink to reliably find the
> real device.
>
> Any ideas?

Well, you can set an udev rule for set up a link, or you could detect
the device inside swupdate using a hook:

...

embedded_script = "

function dectect_emmc(image)
.....
end";

....

partitions: (
{
type = "diskpart";
device = "dummy";
hook = "detect_emmc";
....

and generally it is enough a check inside /sys to know which is the
correct one.

Best regards,
Stefano Babic

>
>
>
> Hamish Guthrie
> Senior Embedded Software Engineer
>

> *Kistler Instrumente AG*

>
> Eulachstrasse 22, 8408 Winterthur, Switzerland
>
> Direct +41 52 2241 642, Main Office +41 52 224 11 11

> hamish....@kistler.com <mailto:hamish....@kistler.com>,
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/
> AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

Fabio Estevam

unread,

Sep 10, 2025, 6:43:11 AMSep 10

to Guthrie Hamish, swup...@googlegroups.com

Hi Hamish,

On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
<swup...@googlegroups.com> wrote:
>
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>
> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>
> Any ideas?

There is no guarantee of the probe order in the kernel.

This is a common problem, and there are some solutions:

1. You can pass aliases in the devicetree so that the SDHC controller
associated with the SD card is mmc0 and the one with the eMMC is mmc1.

Example:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15

or

2. You can use the UUID mechanism to distinguish between the SD card and eMMC.

(Search for "run finduuid" inside U-Boot)

Stefano Babic

unread,

Sep 10, 2025, 7:17:06 AMSep 10

to swup...@googlegroups.com

On 9/10/25 12:42, Fabio Estevam wrote:
> Hi Hamish,
>
> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
> <swup...@googlegroups.com> wrote:
>>
>> Hi,
>>
>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>
>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>
>> Any ideas?
>
> There is no guarantee of the probe order in the kernel.
>
> This is a common problem, and there are some solutions:
>
> 1. You can pass aliases in the devicetree so that the SDHC controller
> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>

Sure.

> Example:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15
>
> or
>
> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>
> (Search for "run finduuid" inside U-Boot)
>

This doesn't help if you need the device for partitioning.

Stefano

Guthrie Hamish

unread,

Sep 10, 2025, 11:36:36 PMSep 10

to Stefano Babic, swup...@googlegroups.com

Hi Fabio and Stefano,

Thanks for the feedback!

>On 9/10/25 12:42, Fabio Estevam wrote:
>> Hi Hamish,
>>
>> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
>> <swup...@googlegroups.com> wrote:
>>>
>>> Hi,
>>>
>>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>>
>>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>>
>>> Any ideas?
>>
>> There is no guarantee of the probe order in the kernel.
>>
>> This is a common problem, and there are some solutions:
>>
>> 1. You can pass aliases in the devicetree so that the SDHC controller
>> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>>

>Sure.

What I omitted to mention is the device is an x86 platform, so there is no devicetree

>> Example:

>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15

>>
>> or
>>
>> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>>
>> (Search for "run finduuid" inside U-Boot)
>>

>This doesn't help if you need the device for partitioning.

It also doesn't help that we are not using u-boot!

Ulrich Teichert

unread,

Sep 11, 2025, 8:07:06 AMSep 11

to swupdate

Hi,

>> There is no guarantee of the probe order in the kernel.
>> This is a common problem, and there are some solutions:
>>
>> 1. You can pass aliases in the devicetree so that the SDHC controller
>> associated with the SD card is mmc0 and the one with the eMMC is mmc1.

Ah, that's something I'll will try as soon as I can, because....

>Sure.

What I omitted to mention is the device is an x86 platform, so there is no devicetree

>> Example:

>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15

>>
>> or
>>
>> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>>
>> (Search for "run finduuid" inside U-Boot)
>>

>This doesn't help if you need the device for partitioning.

It also doesn't help that we are not using u-boot!

...there's a third option, depending on the kernel version and the MMC kernel driver, but there's no

configuration option for it, you have to patch your kernel: you can force synchronous probing if the

driver supports it. I was lucky, it just worked with the arasan-SD driver:

--------------------- drivers/mmc/host/sdhci-of-arasan.c ----------------------
index ff90331468a1..6edf25e1db5a 100644
@@ -1720,7 +1720,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
static struct platform_driver sdhci_arasan_driver = {
.driver = {
.name = "sdhci-arasan",
- .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .probe_type = PROBE_FORCE_SYNCHRONOUS,
.of_match_table = sdhci_arasan_of_match,
.pm = &sdhci_arasan_dev_pm_ops,
},

HTH,

Uli

Nicholas Clark

unread,

Sep 11, 2025, 10:00:55 AMSep 11

to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com

Can you solve it with udev rules? Maybe you can detect by manufacturer or some other field that differentiates the two, and use it to create a symlink. Then you can target the device by symlink.

--
You received this message because you are subscribed to the Google Groups "swupdate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/swupdate/AS1P190MB17760E65894BAAF44D318FD18309A%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM.

Guthrie Hamish

unread,

Oct 9, 2025, 6:07:10 AM (13 days ago) Oct 9

to Stefano Babic, swup...@googlegroups.com

Hi Stefano,

>Well, you can set an udev rule for set up a link, or you could detect
>the device inside swupdate using a hook:
>
>
>...
>
>embedded_script = "
>
>function dectect_emmc(image)
> .....
>end";
>
>....
>
>
>partitions: (
> {
> type = "diskpart";
> device = "dummy";
> hook = "detect_emmc";
> ....
>
>and generally it is enough a check inside /sys to know which is the
>correct one.

I at last managed to implement this (after some holidays), but I am encountering other issues.

So I have the following embedded-script:

embedded-script = "

function file_exists(name)

local f=io.open(name, 'r')

if f~=nil then

io.close(f)

return true

else

return false

end

function detect_emmc(image)

if file_exists('/sys/block/mmcblk0boot0') then

image.device = '/dev/mmcblk0' .. image.device

return true, image

end

if file_exists('/sys/block/mmcblk1boot0') then

image.device = '/dev/mmcblk1' .. image.device

return true, image

end

if file_exists('/sys/block/mmcblk2boot0') then

image.device = '/dev/mmcblk2' .. image.device

return true, image

end

swupdate.error('could not identify eMMC device')

return false, nil

end

";

My partition table of my sw-description file is as follows:

partitions = (

{

type = "diskpart";

device = "";

hook = "detect_emmc";

properties = {

labeltype = "gpt";

nolock = "true";

noinuse = "true";

partition-1 = [ "size=32M", "name=efi", "type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B", "fstype=vfat", "start=2048"];

partition-2 = [ "size=32M", "name=boot0", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-3 = [ "size=32M", "name=boot1", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-4 = [ "size=1024M", "name=root0", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-5 = [ "size=1024M", "name=root1", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-6 = [ "size=256M", "name=data", "type=0FC63DAF-8483-4772-8E79-3D69D8477DE4", "fstype=ext4"];

}

);

Every time I run the update, I see the following message:

FAILURE ERROR diskpart_handler.c : diskpart : 1244 : Just GPT or DOS partition table are supported
RUN [install_single_image] : Installer for diskpart not successful !
FAILURE ERROR stream_interface.c : extract_files : 310 : Error adjusting partition

So I added some debug statements and I see the following:

RUN [install_single_image] : Found installer for stream diskpart

RUN [diskpart] : handler_type: diskpart

RUN [diskpart] : device: /dev/mmcblk1

RUN [diskpart] : is_partitioner: 1

RUN [diskpart_is_gpt] : diskpart_is_gpt: (null)

RUN [diskpart_is_dos] : diskpart_is_dos: (null)

Earlier when the partition table is added we see the following:

RUN [add_properties] : Found properties for :

RUN [add_properties_cb] : Property labeltype: gpt

RUN [add_properties_cb] : Property nolock: true

RUN [add_properties_cb] : Property noinuse: true

RUN [add_properties_cb] : Property partition-1: size=32M

RUN [add_properties_cb] : Property partition-1: name=efi

RUN [add_properties_cb] : Property partition-1: type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B

RUN [add_properties_cb] : Property partition-1: fstype=vfat

RUN [add_properties_cb] : Property partition-1: start=2048

RUN [add_properties_cb] : Property partition-2: size=32M

RUN [add_properties_cb] : Property partition-2: name=boot0

RUN [add_properties_cb] : Property partition-2: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

RUN [add_properties_cb] : Property partition-2: fstype=vfat

RUN [add_properties_cb] : Property partition-3: size=32M

RUN [add_properties_cb] : Property partition-3: name=boot1

RUN [add_properties_cb] : Property partition-3: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

RUN [add_properties_cb] : Property partition-3: fstype=vfat

RUN [add_properties_cb] : Property partition-4: size=1024M

RUN [add_properties_cb] : Property partition-4: name=root0

RUN [add_properties_cb] : Property partition-4: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

RUN [add_properties_cb] : Property partition-5: size=1024M

RUN [add_properties_cb] : Property partition-5: name=root1

RUN [add_properties_cb] : Property partition-5: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

RUN [add_properties_cb] : Property partition-6: size=256M

RUN [add_properties_cb] : Property partition-6: name=data

RUN [add_properties_cb] : Property partition-6: type=0FC63DAF-8483-4772-8E79-3D69D8477DE4

RUN [add_properties_cb] : Property partition-6: fstype=ext4

RUN [lua_parser_fn] : Prepared to run detect_emmc
RUN [lua_parser_fn] : Script returns 0

RUN [_parse_partitions] : Partition: /dev/mmcblk1 new size 0 bytes

So it would appear to me as though the labeltype variable in the array generated is being stomped on by something...

The hook function is certainly working because in the '_parsepartitions' line above we see the correct value for the device.

I have spent a few days trying to debug this and I am not having much success..

Hamish

Stefano Babic

unread,

Oct 9, 2025, 6:38:50 AM (13 days ago) Oct 9

to Guthrie Hamish, swup...@googlegroups.com

Hi Hamish,

Linux stores the type of the device in sysfs.

cat /sys/block/mmcblk0/device/type

you will get SD or MMC

> image.device = '/dev/mmcblk0' .. image.device
> return true, image
> end
> if file_exists('/sys/block/mmcblk1boot0') then
> image.device = '/dev/mmcblk1' .. image.device

Why are you concatenating here ?

Rather I have not printed the device name here, it can help. It is like
the right device is not taken.

I am sure that properties are transferred correctly through the hook -
because here it looks like that properties are reset in some way. Hook
can also access properties, like image.properties.labeltype.

> RUN [install_single_image] : Installer for diskpart not successful !
> FAILURE ERROR stream_interface.c : extract_files : 310 : Error adjusting
> partition
>
> So I added some debug statements and I see the following:
>
> RUN [install_single_image] : Found installer for stream diskpart
> RUN [diskpart] : handler_type: diskpart
> RUN [diskpart] : device: /dev/mmcblk1
> RUN [diskpart] : is_partitioner: 1

Ok

Is this current SWUpdate ?

>
> The hook function is certainly working because in the '_parsepartitions'
> line above we see the correct value for the device.

Agree.

>
> I have spent a few days trying to debug this and I am not having much
> success..

I do not see an error in your configuration, so I guess without
debugging and investigating what is going on I cannot tell something more.

Best regards,
Stefano

Guthrie Hamish

unread,

Oct 9, 2025, 11:12:33 AM (13 days ago) Oct 9

to Stefano Babic, swup...@googlegroups.com

Hi Stefano,

> Linux stores the type of the device in sysfs.
>
> cat /sys/block/mmcblk0/device/type
>
> you will get SD or MMC

Yes, however that is nothing to do with the issue, but I can use that instead

>>                          image.device = '/dev/mmcblk0' .. image.device
>>                          return true, image
>>                  end
>>                  if file_exists('/sys/block/mmcblk1boot0') then
>>                          image.device = '/dev/mmcblk1' .. image.device
>
>Why are you concatenating here ?

I also have a file I need to install in the ESP so I have this snippett:

files = (

{

filename = "bootx64.efi";

path = "EFI/BOOT/bootx64.efi";

device = "p1";

hook = "detect_emmc";

filesystem = "vfat";

properties = {

create-destination = "true";

atomic-install = "true";

};

},

);

So when detect_emmc is called, p1 is passed into the function via the image array and is concatenated to produce /dev/mmcblkNp1 - you will also note in the partition table of the sw-description, I set device = "";, so nothing is concatenated.

If you look at the section below where I say 'So I added debug statements' you will see
that I am specifically printing out the Handler type, device and is_partitioner variables
and the values printed are the values I would expect, and the device value in particular
shows that the result of the hook is correct.

As additional background - we have 3 devices with eMMC which show this unpredictable
mmc device detection, and I am using the hook for device detection and I see the same

result with all 3 boards, however, I also have 1 device which has an SSD, and in that we

do not have unpredictable device detection and for that I do not use the hook function

and that works perfectly well which is why I am suspecting something in the Lua

interface MAY be stomping on this struct.

>>So I added some debug statements and I see the following:
>>
>>RUN [install_single_image] : Found installer for stream diskpart

>>RUN [diskpart] : handler_type: diskpart

>>RUN [diskpart] : device: /dev/mmcblk1

>>RUN [diskpart] : is_partitioner: 1

>>RUN [diskpart_is_gpt] : diskpart_is_gpt: (null)

>>RUN [diskpart_is_dos] : diskpart_is_dos: (null)

>Is this current SWUpdate ?

It is 2025.05

I guess all I can do is to dig a lot deeper!

Hamish

Stefano Babic

unread,

Oct 9, 2025, 11:43:52 AM (13 days ago) Oct 9

to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com

Hallo Hamish,

On 10/9/25 17:12, 'Guthrie Hamish' via swupdate wrote:
> Hi Stefano,
>
> > Linux stores the type of the device in sysfs.
> >
> > cat /sys/block/mmcblk0/device/type
> >
> > you will get SD or MMC
>
> Yes, however that is nothing to do with the issue, but I can use that
> instead

Completely unrelated, yes.

>
> >>                          image.device = '/dev/mmcblk0' .. image.device
> >>                          return true, image
> >>                  end
> >>                  if file_exists('/sys/block/mmcblk1boot0') then
> >>                          image.device = '/dev/mmcblk1' .. image.device
> >
> >Why are you concatenating here ?
>
> I also have a file I need to install in the ESP so I have this snippett:
>
> files = (
> {
> filename = "bootx64.efi";
> path = "EFI/BOOT/bootx64.efi";
> device = "p1";
> hook = "detect_emmc";
> filesystem = "vfat";
> properties = {
> create-destination = "true";
> atomic-install = "true";
> };
> },
> );
>
> So when detect_emmc is called, p1 is passed into the function via the
> image array and is concatenated to produce /dev/mmcblkNp1 - you will
> also note in the partition table of the sw-description, I set device =
> "";, so nothing is concatenated.

Yes, I do not see issue, I was just asking myself why to concatenate a
Null string.

I saw this after writing my comment :-)

> that I am specifically printing out the Handler type, device and
> is_partitioner variables
> and the values printed are the values I would expect, and the device
> value in particular
> shows that the result of the hook is correct.
>
> As additional background - we have 3 devices with eMMC which show this
> unpredictable
> mmc device detection, and I am using the hook for device detection and I
> see the same
> result with all 3 boards, however, I also have 1 device which has an
> SSD, and in that we
> do not have unpredictable device detection and for that I do not use the
> hook function
> and that works perfectly well which is why I am suspecting something in
> the Lua

> interface *MAY* be stomping on this struct.

This seems the reason - but I cannot replicate.

I simply created a very simple example (taking from yours):

software =
{
version = "0.1.0";

embedded-script = "
function file_exists(name)
local f=io.open(name, 'r')
if f~=nil then
io.close(f)
return true
else
return false
end
end

function detect_storage(image)
image.device = '/dev/sde'
return true, image
end
";

pc = {
hardware-compatibility: [ "1.0"];

partitions: (

{
type = "diskpart";
device = "";

hook = "detect_storage"
properties: {
labeltype = "gpt";
partition-1 = ["size=64M", "start=2048", "name=bigrootfs",
"type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B"];
partition-2 = ["size=256M", "name=ldata",
"type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7"];
partition-3 = ["size=512M", "name=log",
"type=0FC63DAF-8483-4772-8E79-3D69D8477DE4"];
partition-4 = ["size=4G", "name=system",
"type=0FC63DAF-8483-4772-8E79-3D69D8477DE4"];
partition-5 = ["size=512M", "name=calib",
"type=0FC63DAF-8483-4772-8E79-3D69D8477DE4"];
}
}
);

};
}

device is assigned, properties are available for the handler, update is
successful.

>
> >>So I added some debug statements and I see the following:
> >>
> >>RUN [install_single_image] : Found installer for stream diskpart
> >>RUN [diskpart] : handler_type: diskpart
> >>RUN [diskpart] : device: /dev/mmcblk1
> >>RUN [diskpart] : is_partitioner: 1
> >>RUN [diskpart_is_gpt] : diskpart_is_gpt: (null)
> >>RUN [diskpart_is_dos] : diskpart_is_dos: (null)
>
> >Is this current SWUpdate ?
>
> It is 2025.05
>
> I guess all I can do is to dig a lot deeper!

There is something related to your environment and I cannot get where
is. I have already tested with lua 5.2 and lua 5.4 (current in OE), both
are working here.

Regards,
Stefano

Guthrie Hamish

unread,

Oct 10, 2025, 1:27:16 PM (12 days ago) Oct 10

to Stefano Babic, swup...@googlegroups.com

Hi Stefano,

OK, I have done a lot more probing into this and I have a much simpler sw-description file which I show here:

software = {

version = "@@DISTRO_VERSION@@";

reboot = false;

bootloader_transaction_marker = false;

bootloader_state_marker = false;

hardware-compatibility: [

"#RE:^X2:03"

];

embedded-script = "

function detect_emmc(image)

image.device = '/dev/mmcblk1'

return true, image

end

";

partitions = (

{

type = "diskpart";

device = "";

hook = "detect_emmc";

properties = {

labeltype = "gpt";

nolock = "true";

noinuse = "true";

partition-1 = [ "size=32M", "name=efi", "type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B", "fstype=vfat", "start=2048"];

partition-2 = [ "size=32M", "name=boot0", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-3 = [ "size=32M", "name=boot1", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-4 = [ "size=1024M", "name=root0", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-5 = [ "size=1024M", "name=root1", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-6 = [ "size=256M", "name=data", "type=0FC63DAF-8483-4772-8E79-3D69D8477DE4", "fstype=ext4"];

}

);

};

I have the following patch:

From 741f980364f127643ad0de6e6a521246eb44bffa Mon Sep 17 00:00:00 2001

From: Hamish Guthrie <hamish....@kistler.com>

Date: Wed, 8 Oct 2025 12:35:39 +0000

Subject: [PATCH] Debug partition elements

---

parser/parser.c | 2 ++

1 file changed, 2 insertions(+)

Index: git/parser/parser.c

===================================================================

--- git.orig/parser/parser.c

+++ git/parser/parser.c

@@ -480,11 +480,13 @@ static int _parse_partitions(parsertype

return 0;

count = get_array_length(p, setting);

+ TRACE("setting array size: %d", count);

/*

* Parse in reverse order, so that the partitions are processed

* by LIST_HEAD() in the same order as they are found in sw-description

*/

for(i = (count - 1); i >= 0; --i) {

+ TRACE("processing element: %d", i);

elem = get_elem_from_idx(p, setting, i);

if (!elem)

@@ -518,6 +520,21 @@ static int _parse_partitions(parsertype

add_properties(p, elem, partition);

+ if (&partition->properties) {

+ TRACE("pre-embscript partition->properties exists");

+

+ if (LIST_EMPTY(&partition->properties)) {

+ TRACE("properties list is empty");

+ }

+

+ struct dict_entry *entry;

+ LIST_FOREACH(entry, &partition->properties, next) {

+ TRACE("key: %s", entry->key);

+ }

+ } else {

+ TRACE("partition->properties is NULL");

+ }

+

skip = run_embscript(p, elem, partition, L, swcfg->embscript);

if (skip < 0) {

free_image(partition);

@@ -528,6 +545,22 @@ static int _parse_partitions(parsertype

continue;

}

+ if (&partition->properties) {

+ TRACE("post-embscript partition->properties exists");

+

+ if (LIST_EMPTY(&partition->properties)) {

+ TRACE("properties list is empty");

+ }

+

+ struct dict_entry *entry;

+ LIST_FOREACH(entry, &partition->properties, next) {

+ TRACE("key: %s", entry->key);

+ }

+ } else {

+ TRACE("partition->properties is NULL");

+ }

+

if ((!strlen(partition->volname) && !strcmp(partition->type, "ubipartition")) ||

!strlen(partition->device)) {

ERROR("Partition incompleted in description file");

I see the following output:

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_thread] : Incoming network request: processing...

Jan 10 03:24:58 localhost user.info swupdate: START Software Update started !

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_initializer] : Software update started

Jan 10 03:24:58 localhost user.debug swupdate: RUN [extract_file_to_tmp] : Found file

Jan 10 03:24:58 localhost user.debug swupdate: RUN [extract_file_to_tmp] : filename sw-description

Jan 10 03:24:58 localhost user.debug swupdate: RUN [extract_file_to_tmp] : size 1374

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parse_cfg] : Parsing config file /tmp/sw-description

Jan 10 03:24:58 localhost user.debug swupdate: RUN [get_common_fields] : Version 5.0.11

Jan 10 03:24:58 localhost user.debug swupdate: RUN [get_common_fields] : Description SWupdate rescue image for Skybase x86 platforms

Jan 10 03:24:58 localhost user.debug swupdate: RUN [get_common_fields] : Setting bootloader state marker: false

Jan 10 03:24:58 localhost user.debug swupdate: RUN [get_common_fields] : Setting bootloader transaction marker: false

Jan 10 03:24:58 localhost user.debug swupdate: RUN [get_common_fields] : reboot_required 0

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parser] : Getting script

Jan 10 03:24:58 localhost user.info swupdate: RUN [lua_handlers_init] : External Lua handler(s) found and loaded.

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parser] : Found Lua Software: function file_exists(name) local f=io.open(name, 'r') if f~=nil then io.close(f) return true else return false end end function detect_emmc(image) image.device = '/de

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parse_hw_compatibility] : Accepted Hw Revision : #RE:^X2:03

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : setting array size: 1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : processing element: 0

Jan 10 03:24:58 localhost user.warn swupdate: RUN [check_field_string] : Configuration Key 'device' is empty!

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties] : Found properties for :

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property labeltype: gpt

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property nolock: true

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property noinuse: true

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: size=32M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: name=efi

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: fstype=vfat

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: start=2048

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: size=32M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: name=boot0

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: fstype=vfat

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: size=32M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: name=boot1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: fstype=vfat

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: size=1024M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: name=root0

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: size=1024M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: name=root1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: size=256M

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: name=data

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: type=0FC63DAF-8483-4772-8E79-3D69D8477DE4

Jan 10 03:24:58 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: fstype=ext4

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : pre-embscript partition->properties exists

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-6

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-5

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-4

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-3

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-2

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: noinuse

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: nolock

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : key: labeltype

Jan 10 03:24:58 localhost user.debug swupdate: RUN [lua_parser_fn] : Prepared to run detect_emmc

Jan 10 03:24:58 localhost user.debug swupdate: RUN [lua_parser_fn] : Script returns 0

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : post-embscript partition->properties exists

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : properties list is empty

Jan 10 03:24:58 localhost user.debug swupdate: RUN [_parse_partitions] : Partition: /dev/mmcblk1 new size 0 bytes

Jan 10 03:24:58 localhost user.debug swupdate: RUN [compare_versions] : Comparing old-style versions '5.0.11' <-> '3.0.0'

Jan 10 03:24:58 localhost user.debug swupdate: RUN [compare_versions] : Parsed: '1407374884274176' <-> '844424930131968'

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parse] : Number of found artifacts: 1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parse] : Number of scripts: 0

Jan 10 03:24:58 localhost user.debug swupdate: RUN [parse] : Number of steps to be run: 1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [check_hw_compatibility] : Hardware industry Revision: X2:03

Jan 10 03:24:58 localhost user.debug swupdate: RUN [hwid_match] : hwrev X2:03 matched by regexp ^X2:03

Jan 10 03:24:58 localhost user.debug swupdate: RUN [check_hw_compatibility] : Hardware compatibility verified

Jan 10 03:24:58 localhost user.debug swupdate: RUN [preupdatecmd] : Running Pre-update command

Jan 10 03:24:58 localhost user.debug swupdate: RUN [extract_padding] : Expecting up to 512 padding bytes at end-of-file

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_initializer] : Note: Setting EFI Boot Guard's 'in_progress' environment variable cannot be disabled.

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_initializer] : Note: EFI Boot Guard environment transaction will not be auto-committed.

Jan 10 03:24:58 localhost user.warn swupdate: RUN [network_initializer] : EFI Boot Guard environment modifications will not be persisted.

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_initializer] : Valid image found: copying to FLASH

Jan 10 03:24:58 localhost user.info swupdate: RUN Installation in progress

Jan 10 03:24:58 localhost user.debug swupdate: RUN [install_single_image] : Found installer for stream diskpart

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart] : handler_type: diskpart

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart] : device: /dev/mmcblk1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart] : is_partitioner: 1

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart] : img->properties exists

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart] : properties list is empty

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart_is_gpt] : diskpart_is_gpt: (null)

Jan 10 03:24:58 localhost user.debug swupdate: RUN [diskpart_is_dos] : diskpart_is_dos: (null)

Jan 10 03:24:58 localhost user.err swupdate: FAILURE ERROR diskpart_handler.c : diskpart : 1259 : Just GPT or DOS partition table are supported

Jan 10 03:24:58 localhost user.debug swupdate: RUN [install_single_image] : Installer for diskpart not successful !

Jan 10 03:24:58 localhost user.err swupdate: FATAL_FAILURE Installation failed !

Jan 10 03:24:58 localhost user.debug swupdate: RUN [network_initializer] : Main thread sleep again !

Jan 10 03:24:58 localhost user.info swupdate: IDLE Waiting for requests..

If I adjust the sw-description file as follows:

software = {

version = "@@DISTRO_VERSION@@";

reboot = false;

bootloader_transaction_marker = false;

bootloader_state_marker = false;

hardware-compatibility: [

"#RE:^X2:03"

];

embedded-script = "

function detect_emmc(image)

image.device = '/dev/mmcblk1'

return true, image

end

";

partitions = (

{

type = "diskpart";

device = "/dev/mmcblk1";

//hook = "detect_emmc";

properties = {

labeltype = "gpt";

nolock = "true";

noinuse = "true";

partition-1 = [ "size=32M", "name=efi", "type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B", "fstype=vfat", "start=2048"];

partition-2 = [ "size=32M", "name=boot0", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-3 = [ "size=32M", "name=boot1", "type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7", "fstype=vfat"];

partition-4 = [ "size=1024M", "name=root0", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-5 = [ "size=1024M", "name=root1", "type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE"];

partition-6 = [ "size=256M", "name=data", "type=0FC63DAF-8483-4772-8E79-3D69D8477DE4", "fstype=ext4"];

}

);

};

In other words hard coding the device instead of using the Lua script to detect it.

It works just fine and the data is not corrupted.

I also tried the identical configuration except replacing the /dev/mmcblk1 with /dev/sda on our other device with SSD as opposed to eMMC and if I use the lua script I see the identical failure, but if I hard-code the device it works just fine.

I am using poky tag yocto-5.0.11 with swupdate 2025.05 (with no local patches) - this build has lua 5.4.6 (with no local patches)

I believe that this testing shows that there is an issue in the lua glue somewhere, but I am not sure where.

The issue is also reproducable with the --dry-run option of swupdate.

Hamish

Kistler Instrumente AG

Eulachstrasse 22, 8408 Winterthur, Switzerland

Direct +41 52 2241 642, Main Office +41 52 224 11 11

hamish....@kistler.com, www.kistler.com, myKistler, Contact Service

Office address:

Kistler Instrumente AG
Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland

Confidentiality Notice: This e-mail is privileged and confidential and for the use of the addressee only. Should you have received this e-mail in error please notify us by replying directly to the sender or by sending a message to in...@kistler.com. Unauthorised dissemination, disclosure or copying of the contents of this e-mail, or any similar action, is prohibited.

Stefano Babic

unread,

Oct 10, 2025, 3:52:34 PM (12 days ago) Oct 10

to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com

Hi Hamish,

I assume you run with the maximum log level (-l 5), but I am missing a
lot of traces. The function lua_dump_table() transfers back all modified
attributes including the properties to the parser, and I do not see the
output, and from your analyses it seems that for some reason the
function stops working.

The output (taken with the derived sw-description from yours) is
something like (just around the embedded script):

[TRACE] : SWUPDATE running : [lua_parser_fn] : Prepared to run
detect_storage
[TRACE] : SWUPDATE running : [notify_helper] : Partition type is gpt
[TRACE] : SWUPDATE running : [notify_helper] : Handler is diskpart
[TRACE] : SWUPDATE running : [LUAstackDump] : (1) [bool ] true
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] size = 0.0
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] compressed
= false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] data =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] version =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] sha256 =
0000000000000000000000000000000000000000000000000000000000000000
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] aes-key =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] read()
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
install_if_higher = false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] copy2file()
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] ivt =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] encrypted
= false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] volume =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-1: 1 = type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-1: 2 = name=bigrootfs
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-1: 3 = start=2048
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-1: 4 = size=64M
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-5: 1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-5: 2 = name=calib
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-5: 3 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-3: 1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-3: 2 = name=log
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-3: 3 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-4: 1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-4: 2 = name=system
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-4: 3 = size=4G
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: labeltype = gpt
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-2: 1 = type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-2: 2 = name=ldata
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
properties: partition-2: 3 = size=256M
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
installed_directly = false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] filesystem =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
install_if_different = false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] type =
diskpart
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] checksum = 0.0
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] offset = 0.0
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ]
preserve_attributes = false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] filename =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] name =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] device =
/dev/sde
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] mtdname =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] path =
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] partition
= true
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] script = false
[TRACE] : SWUPDATE running : [lua_dump_table] : (2) [table ] skip = 0.0
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-1:
1 = type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-1 = type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B

==> the "Inserting property" trace logs the transfer of a property from
Lua to C. We should see the same on yours.

I do not see why these traces should't be appear, but I do not see them
in your log.

Best regards,
Stefano

[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-1:
2 = name=bigrootfs
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-1 = name=bigrootfs
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-1:
3 = start=2048
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-1 = start=2048
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-1:
4 = size=64M
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-1 = size=64M
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-5:
1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-5 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-5:
2 = name=calib
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-5 = name=calib
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-5:
3 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-5 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-3:
1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-3 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-3:
2 = name=log
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-3 = name=log
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-3:
3 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-3 = size=512M
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-4:
1 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-4 = type=0FC63DAF-8483-4772-8E79-3D69D8477DE4
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-4:
2 = name=system
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-4 = name=system
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-4:
3 = size=4G
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-4 = size=4G
[TRACE] : SWUPDATE running : [lua_dump_table] : properties labeltype = gpt
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
labeltype = gpt
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-2:
1 = type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-2 = type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-2:
2 = name=ldata
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-2 = name=ldata
[TRACE] : SWUPDATE running : [lua_dump_table] : properties partition-2:
3 = size=256M
[TRACE] : SWUPDATE running : [lua_dump_table] : Inserting property
partition-2 = size=256M
[TRACE] : SWUPDATE running : [lua_parser_fn] : Script returns 0

Guthrie Hamish

unread,

Oct 10, 2025, 4:01:51 PM (12 days ago) Oct 10

to Stefano Babic, swup...@googlegroups.com

Hi Stefano,

I had disabled the LUAStackDump because with it enabled, the update simply stalled before I saw any log messages, which is what led me to suspect that there is a memory leak or corruption somewhere.

I will re-enable it and attempt to re-create the logs.

Also, unfortunately my company insists on using this useless Outlook piece of rubbish, so it is impossible to reply to emails correctly in the way I would like to, but our ICT believe that if you do not have to pay for software it must be rubbish!!!! What a bunch of losers.

Hamish Guthrie
Senior Embedded Software Engineer

Kistler Instrumente AG

Eulachstrasse 22, 8408 Winterthur, Switzerland
Direct +41 52 2241 642, Main Office +41 52 224 11 11
hamish....@kistler.com, www.kistler.com, myKistler, Contact Service

Office address:

Kistler Instrumente AG

Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland

Confidentiality Notice: This e-mail is privileged and confidential and for the use of the addressee only. Should you have received this e-mail in error please notify us by replying directly to the sender or by sending a message to in...@kistler.com. Unauthorised dissemination, disclosure or copying of the contents of this e-mail, or any similar action, is prohibited.

From: Stefano Babic <stefan...@swupdate.org>

Sent: Friday, October 10, 2025 9:52 PM
To: Guthrie Hamish <Hamish....@kistler.com>; Stefano Babic <stefan...@swupdate.org>; swup...@googlegroups.com <swup...@googlegroups.com>
Subject: Re: [swupdate] eMMC devices being probed inconsistently by kernel driver

Achtung: Dies ist ein externes Mail. Vorsicht bei Links und Anhängen.

Guthrie Hamish

unread,

Oct 10, 2025, 4:22:48 PM (12 days ago) Oct 10

to Stefano Babic, swup...@googlegroups.com

Hi Stefano,

The ps output shows swupdate being run as follows:

root 362 317 0 20:16 ? 00:00:00 /usr/bin/swupdate -v -L -N 3.0.0 -H industry X1:01 -e stable module_X101 -w -r /www -p 8080

I now see the following (reduced) output

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : pre-embscript partition->properties exists

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-6

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-5

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-4

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-3

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-2

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-1

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: noinuse

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: nolock

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : key: labeltype

Oct 10 20:17:25 localhost user.debug swupdate: RUN [lua_parser_fn] : Prepared to run detect_emmc

Oct 10 20:17:25 localhost user.debug swupdate: RUN [LUAstackDump] : (1) [bool ] true

Oct 10 20:17:25 localhost user.debug swupdate: RUN [lua_parser_fn] : Script returns 0

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : post-embscript partition->properties exists

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : properties list is empty

Oct 10 20:17:25 localhost user.debug swupdate: RUN [_parse_partitions] : Partition: /dev/sda new size 0 bytes

Is this any help?

Hamish

Hamish Guthrie
Senior Embedded Software Engineer

Kistler Instrumente AG
Eulachstrasse 22, 8408 Winterthur, Switzerland
Direct +41 52 2241 642, Main Office +41 52 224 11 11
hamish....@kistler.com, www.kistler.com, myKistler, Contact Service

Office address:

Kistler Instrumente AG
Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland

Confidentiality Notice: This e-mail is privileged and confidential and for the use of the addressee only. Should you have received this e-mail in error please notify us by replying directly to the sender or by sending a message to in...@kistler.com. Unauthorised dissemination, disclosure or copying of the contents of this e-mail, or any similar action, is prohibited.

From: Stefano Babic <stefan...@swupdate.org>
Sent: Friday, October 10, 2025 9:52 PM
To: Guthrie Hamish <Hamish....@kistler.com>; Stefano Babic <stefan...@swupdate.org>; swup...@googlegroups.com <swup...@googlegroups.com>
Subject: Re: [swupdate] eMMC devices being probed inconsistently by kernel driver

Achtung: Dies ist ein externes Mail. Vorsicht bei Links und Anhängen.

Guthrie Hamish

unread,

Oct 10, 2025, 4:29:35 PM (12 days ago) Oct 10

to Stefano Babic, swup...@googlegroups.com, Guthrie Hamish

The full output is:

Oct 10 20:24:55 localhost user.info swupdate: START Software Update started !

Oct 10 20:24:55 localhost user.debug swupdate: RUN [network_initializer] : Software update started

Oct 10 20:24:55 localhost user.debug swupdate: RUN [extract_file_to_tmp] : Found file

Oct 10 20:24:55 localhost user.debug swupdate: RUN [extract_file_to_tmp] : filename sw-description

Oct 10 20:24:55 localhost user.debug swupdate: RUN [extract_file_to_tmp] : size 1093

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parse_cfg] : Parsing config file /tmp/sw-description

Oct 10 20:24:55 localhost user.debug swupdate: RUN [get_common_fields] : Version 5.0.11

Oct 10 20:24:55 localhost user.debug swupdate: RUN [get_common_fields] : Setting bootloader state marker: false

Oct 10 20:24:55 localhost user.debug swupdate: RUN [get_common_fields] : Setting bootloader transaction marker: false

Oct 10 20:24:55 localhost user.debug swupdate: RUN [get_common_fields] : reboot_required 0

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parser] : Getting script

Oct 10 20:24:55 localhost user.info swupdate: RUN [lua_handlers_init] : External Lua handler(s) found and loaded.

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parser] : Found Lua Software: function detect_emmc(image) image.device = '/dev/sda' return true, image end

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parse_hw_compatibility] : Accepted Hw Revision : #RE:^X1:01

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : setting array size: 1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : processing element: 0

Oct 10 20:24:55 localhost user.warn swupdate: RUN [check_field_string] : Configuration Key 'device' is empty!

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties] : Found properties for :

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property labeltype: gpt

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property nolock: true

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property noinuse: true

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: size=32M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: name=efi

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: type=C12A7328-F81F-11D2-BA4B-00A0C93EC93B

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: fstype=vfat

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-1: start=2048

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: size=32M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: name=boot0

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-2: fstype=vfat

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: size=32M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: name=boot1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-3: fstype=vfat

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: size=1024M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: name=root0

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-4: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: size=1024M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: name=root1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-5: type=B921B045-1DF0-41C3-AF44-4C6F280D3FAE

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: size=256M

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: name=data

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: type=0FC63DAF-8483-4772-8E79-3D69D8477DE4

Oct 10 20:24:55 localhost user.debug swupdate: RUN [add_properties_cb] : Property partition-6: fstype=ext4

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : pre-embscript partition->properties exists

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-6

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-5

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-4

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-3

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-2

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: partition-1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: noinuse

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: nolock

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : key: labeltype

Oct 10 20:24:55 localhost user.debug swupdate: RUN [lua_parser_fn] : Prepared to run detect_emmc

Oct 10 20:24:55 localhost user.debug swupdate: RUN [LUAstackDump] : (1) [bool ] true

Oct 10 20:24:55 localhost user.debug swupdate: RUN [lua_parser_fn] : Script returns 0

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : post-embscript partition->properties exists

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : properties list is empty

Oct 10 20:24:55 localhost user.debug swupdate: RUN [_parse_partitions] : Partition: /dev/sda new size 0 bytes

Oct 10 20:24:55 localhost user.debug swupdate: RUN [compare_versions] : Comparing old-style versions '5.0.11' <-> '3.0.0'

Oct 10 20:24:55 localhost user.debug swupdate: RUN [compare_versions] : Parsed: '1407374884274176' <-> '844424930131968'

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parse] : Number of found artifacts: 1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parse] : Number of scripts: 0

Oct 10 20:24:55 localhost user.debug swupdate: RUN [parse] : Number of steps to be run: 1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [check_hw_compatibility] : Hardware industry Revision: X1:01

Oct 10 20:24:55 localhost user.debug swupdate: RUN [hwid_match] : hwrev X1:01 matched by regexp ^X1:01

Oct 10 20:24:55 localhost user.debug swupdate: RUN [check_hw_compatibility] : Hardware compatibility verified

Oct 10 20:24:55 localhost user.debug swupdate: RUN [preupdatecmd] : Running Pre-update command

Oct 10 20:24:55 localhost user.debug swupdate: RUN [extract_padding] : Expecting up to 512 padding bytes at end-of-file

Oct 10 20:24:55 localhost user.debug swupdate: RUN [network_initializer] : Note: Setting EFI Boot Guard's 'in_progress' environment variable cannot be disabled.

Oct 10 20:24:55 localhost user.debug swupdate: RUN [network_initializer] : Note: EFI Boot Guard environment transaction will not be auto-committed.

Oct 10 20:24:55 localhost user.warn swupdate: RUN [network_initializer] : EFI Boot Guard environment modifications will not be persisted.

Oct 10 20:24:55 localhost user.debug swupdate: RUN [network_initializer] : Valid image found: copying to FLASH

Oct 10 20:24:55 localhost user.info swupdate: RUN Installation in progress

Oct 10 20:24:55 localhost user.debug swupdate: RUN [install_single_image] : Found installer for stream diskpart

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart] : handler_type: diskpart

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart] : device: /dev/sda

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart] : is_partitioner: 1

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart] : img->properties exists

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart] : properties list is empty

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart_is_gpt] : diskpart_is_gpt: (null)

Oct 10 20:24:55 localhost user.debug swupdate: RUN [diskpart_is_dos] : diskpart_is_dos: (null)

Oct 10 20:24:55 localhost user.err swupdate: FAILURE ERROR diskpart_handler.c : diskpart : 1259 : Just GPT or DOS partition table are supported

Oct 10 20:24:55 localhost user.debug swupdate: RUN [install_single_image] : Installer for diskpart not successful !

Oct 10 20:24:55 localhost user.err swupdate: FATAL_FAILURE Installation failed !

Oct 10 20:24:55 localhost user.debug swupdate: RUN [network_initializer] : Main thread sleep again !

Oct 10 20:24:55 localhost user.info swupdate: IDLE Waiting for requests...

Hamish Guthrie
Senior Embedded Software Engineer

Kistler Instrumente AG
Eulachstrasse 22, 8408 Winterthur, Switzerland
Direct +41 52 2241 642, Main Office +41 52 224 11 11
hamish....@kistler.com, www.kistler.com, myKistler, Contact Service

Office address:

Kistler Instrumente AG
Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland

Confidentiality Notice: This e-mail is privileged and confidential and for the use of the addressee only. Should you have received this e-mail in error please notify us by replying directly to the sender or by sending a message to in...@kistler.com. Unauthorised dissemination, disclosure or copying of the contents of this e-mail, or any similar action, is prohibited.

From: 'Guthrie Hamish' via swupdate <swup...@googlegroups.com>
Sent: Friday, October 10, 2025 10:22 PM
To: Stefano Babic <stefan...@swupdate.org>; swup...@googlegroups.com <swup...@googlegroups.com>

--
You received this message because you are subscribed to the Google Groups "swupdate" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/swupdate/AS1P190MB17766C715AA4C2266F03E5D583EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM.

Stefano Babic

unread,

Oct 10, 2025, 5:07:13 PM (12 days ago) Oct 10

to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com

Hi Hamish,

On 10/10/25 22:01, 'Guthrie Hamish' via swupdate wrote:
> Hi Stefano,
>

> I had disabled the LUAStackDump because with it enabled, the update
> simply stalled before I saw any log messages, which is what led me to
> suspect that there is a memory leak or corruption somewhere.
>
> I will re-enable it and attempt to re-create the logs.
>
> Also, unfortunately my company insists on using this useless Outlook
> piece of rubbish, so it is impossible to reply to emails correctly in
> the way I would like to, but our ICT believe that if you do not have to
> pay for software it must be rubbish!!!!

Well, if thy can feel better... I do n ot want they think that SWUpdate
is bad, and I would like to helpo them to feel better....just tell them
to send me money for SWUpdate ! :-D

> What a bunch of losers.
>

Indeed.

Stefano

>
>
> Hamish Guthrie
> Senior Embedded Software Engineer
>

> *Kistler Instrumente AG*

>
> Eulachstrasse 22, 8408 Winterthur, Switzerland
> Direct +41 52 2241 642, Main Office +41 52 224 11 11

> hamish....@kistler.com <mailto:hamish....@kistler.com>,
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>

> Office address:
>
> *Kistler Instrumente AG*

>
> Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland
>
>
>

> <https://www.linkedin.com/company/kistler> <https://www.youtube.com/
> KistlerGroup>

>
> Confidentiality Notice: This e-mail is privileged and confidential and
> for the use of the addressee only. Should you have received this e-mail
> in error please notify us by replying directly to the sender or by

> sending a message to in...@kistler.com <mailto:in...@kistler.com>.

> Unauthorised dissemination, disclosure or copying of the contents of
> this e-mail, or any similar action, is prohibited.
>
>
>

> ------------------------------------------------------------------------
> *From:* Stefano Babic <stefan...@swupdate.org>
> *Sent:* Friday, October 10, 2025 9:52 PM
> *To:* Guthrie Hamish <Hamish....@kistler.com>; Stefano Babic
> <stefan...@swupdate.org>; swup...@googlegroups.com
> <swup...@googlegroups.com>
> *Subject:* Re: [swupdate] eMMC devices being probed inconsistently by

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/

> AS1P190MB17763739E56B4EE03F32238583EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17763739E56B4EE03F32238583EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

Stefano Babic

unread,

Oct 10, 2025, 5:11:27 PM (12 days ago) Oct 10

to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com

Hi Hamish,

what I do not understand is:

https://github.com/sbabic/swupdate/blob/master/corelib/lua_interface.c#L105

I do not see this TRACE in your output (and it should be with -l 5). It
is inside lua_dump_table() when a property is passed back to the parser.

It is like the function is skipped, do you have some other change ? See
my output, there are a lot of traces in with lua_dump_table.

Stefano

> *Kistler Instrumente AG*

> Eulachstrasse 22, 8408 Winterthur, Switzerland
> Direct +41 52 2241 642, Main Office +41 52 224 11 11

> hamish....@kistler.com <mailto:hamish....@kistler.com>,
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>

> Office address:
>
> *Kistler Instrumente AG*

> Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland
>
>
>

> <https://www.linkedin.com/company/kistler> <https://www.youtube.com/
> KistlerGroup>
>

> Confidentiality Notice: This e-mail is privileged and confidential and
> for the use of the addressee only. Should you have received this e-mail
> in error please notify us by replying directly to the sender or by

> sending a message to in...@kistler.com <mailto:in...@kistler.com>.

> Unauthorised dissemination, disclosure or copying of the contents of
> this e-mail, or any similar action, is prohibited.
>
>

> ------------------------------------------------------------------------
> *From:* 'Guthrie Hamish' via swupdate <swup...@googlegroups.com>
> *Sent:* Friday, October 10, 2025 10:22 PM
> *To:* Stefano Babic <stefan...@swupdate.org>;
> swup...@googlegroups.com <swup...@googlegroups.com>
> *Subject:* Re: [swupdate] eMMC devices being probed inconsistently by

> *Kistler Instrumente AG*

> Eulachstrasse 22, 8408 Winterthur, Switzerland
> Direct +41 52 2241 642, Main Office +41 52 224 11 11

> hamish....@kistler.com <mailto:hamish....@kistler.com>,
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>

> Office address:
>
> *Kistler Instrumente AG*

> Else-Züblin-Strasse 17, 8404 Winterthur, Switzerland
>
>
>

> <https://www.linkedin.com/company/kistler> <https://www.youtube.com/
> KistlerGroup>
>

> Confidentiality Notice: This e-mail is privileged and confidential and
> for the use of the addressee only. Should you have received this e-mail
> in error please notify us by replying directly to the sender or by

> sending a message to in...@kistler.com <mailto:in...@kistler.com>.

> Unauthorised dissemination, disclosure or copying of the contents of
> this e-mail, or any similar action, is prohibited.
>
>

> ------------------------------------------------------------------------
> *From:* Stefano Babic <stefan...@swupdate.org>

> *Sent:* Friday, October 10, 2025 9:52 PM
> *To:* Guthrie Hamish <Hamish....@kistler.com>; Stefano Babic
> <stefan...@swupdate.org>; swup...@googlegroups.com
> <swup...@googlegroups.com>
> *Subject:* Re: [swupdate] eMMC devices being probed inconsistently by

> <mailto:swupdate+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/

> AS1P190MB17766C715AA4C2266F03E5D583EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17766C715AA4C2266F03E5D583EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com

> <mailto:swupdate+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/

> AS1P190MB17763FFF3C7DE4659B72BFE883EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17763FFF3C7DE4659B72BFE883EFA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.

Reply all

Reply to author

Forward