• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Freshly received netPI cannot boot - Invalid partition 2
#1
Hello

I've received two netPIs NOIT-E-NPI3-EN. Taken fresh from the box one of the pis did not want to boot up properly and cannot find the kernel image

The boot screen message is:
    Wrong Image Format for bootm command
    Error: can't get kernel image!
    SCRIPT FAILED: continuing...
    ** Invalid partition 2 **


I tried the recovery tipps found in the forum with the recovery image from the USB Stick.
It results in a verification error:
    initrd[1]: Running device_data ...
    WARNING: Failed to connect to lvmetad. Falling back to device scanning.
    Reading all physical volumes. This may take a while...
    WARNING: Failed to connect to lvmetad. Falling back to device scanning.
    mount: mounting /dev/mapper/rootfs-BACKUP on /mnt failed: No such file or directory
    mount: mounting on /tmp/nvdsrc/ failed: Invalid argument
    cp: can't stat '/tmp/nvdsrc/nvd/device_data': No such file or directory
    initrd[1]: Verifying device data...
    initrd[1]: Device data not present / failed to verify device! Reboot may recover data.
    Error - device verification not possible. Device data need to be restored! Please contact distributor. Boot process stopped!


Further data of the affected Pi
  • Part No: 1321.510
  • MAC B827EBA9E8E6
  • Date code 20/16
  • Data Matrix inhalt: 1321510220453
 
Can it be recovered by myself at this point? And how? Or does it need servicing / replacement?


Best regards
  Reply
#2
Hi there,

an end customer has no possibility other than to restore the device back to factory settings using the system software from https://www.netiot.com/netpi/industrial-raspberry-pi-3/ along with an USB stick following this instruction here https://www.netiot.com/netpi/industrial-...-on-netpi/.

But you described you did exactly the same thing I mentioning above and it did not work, right? The log file you printed out is the one during the usage of the recovery stick?

Each netPI and software on the SD card is bound to the serial number of the Raspberry Pi processor. Any modifications on the file system or the partitions will usually be detected by the high assurance boot mechanism we have implemented. And it seems to me that this is happening right now and a malfunction has been detected. A root source is not clear to me even with the log file you sent.

So my first proposal is to try again the USB stick one more time. On the HDMI output you should see normally that a stick was detected and it tries to boot from this stick and the update is started then afterwards.

If this still does not work the only chance I see is to send this device back for repair. I would generate then a return ticket for you so that finally the device can be examined by myself personally to analyse what excatly happened. I would clone the SD card for example and try to reboot the device and I will check all the files that should be on the SD card with the real existing ones.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
Hi Armin,

so I did as you asked me or rather tried - the second link you posted is shortened down and then leads no where.
So I followed the HOWTO again. Wink

The outcome changed a bit to the last time:
This time a "Firmware Recovery" started but then failed to make a fat32 filesystem

This time I am adding the screenshots.

So this is the boot sequence recognizing the recovery stick
   

And this is the point the second attempt to recover fails.
   

It is different to the first time. And this time the act led is still flashing long past the HDMI port inactivity.

Best regards
  Reply
#4
I corrected the link, thank you for this hint.

As next to your screen shot ... to be honest this is the first time I saw an update procedure hanging like this.

During the update process there are just standard Linux commands called from the USB stick to access the netPI SD card's file system and I assume the SD card has indeed a malfunction. I see not even the simplest commands are working based on your screen shot.

This device needs to be sent back to us. Do you agree?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
(September-25th-2020, 03:40 PM)Armin@netPI Wrote: I corrected the link, thank you for this hint.

As next to your screen shot ... to be honest this is the first time I saw an update procedure hanging like this.

During the update process there are just standard Linux commands called from the USB stick to access the netPI SD card's file system and I assume the SD card has indeed a malfunction. I see not even the simplest commands are working based on your screen shot.

This device needs to be sent back to us. Do you agree?

Is the user using a USB 2.0 stick?  Maybe a USB 3.0 would work?
  Reply
#6
Hi Steve,

I see in the screen shots that the USB stick is not the root cause of the problem. The log file points me to the destination mmcblk device which is the SD card having a problem.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
Hi Armin,

I think in this case I will require a return ticket, so you may receive the PI for examination.

Could you please supply the return ticket.

Best regards
  Reply
#8
See private message.

Update 10/07/2020:

Device examination showed the device's SD card was not loaded with the system software at all by us. The SD card itself - as suspected - was not the root cause. It was definitively a production problem.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  [SOLVED] Boot from usb stick Jonas.Sellmann@outlook.de 1 315 November-21st-2018, 04:11 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)