Package Installation error

Hi all,

I have tried the commands on my board (Custom board + Nano)
sudo apt update and sudo apt upgradeto change from L4T32.4.3 to L4T32.4.4.

But after installation i am facing this issue,

dpkg: error processing package nvidia-l4t-bootloader (–configure):
installed nvidia-l4t-bootloader package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

And i am not able to install anymore packages. How can i fix this issue?

Ann R.

What was your board name flashed on to this custom carrier board?

sudo ./flash <board_name > mmcblk0p1?


Thanks for the response.

We have taken the reference of jetson nano and updated the board name.

And for board name instead of the jetson-nano-emmc we have used our custom board name-emmc,

sudo ./ <custom_board_name-emmc> mmcblk0p1

Updating the board name is probably the reason that causes this error.

Actually, when you use custom carrier board, you should not use nvidia’s OTA upgrade anymore. It may cause your board not able to work after you use official OTA again.

Thanks for the response.

We have the changed the file name of custom board to the reference board and flashed the image.

The issue is not reproduced after doing

apt upgrade

Will it cause any issues in the future for the rootfs or bootloader changes we have done?

This is from a question someone else asked, but it might be useful as some sort of temporary fix for people who do not want a particular package to attempt update…

I found this on marking a package for hold:

I’d use the the “sudo apt-mark hold ...” version of this. Use the name of the package from boot which would break: nvidia-l4t-bootloader.

If you need to upgrade, then this won’t help, but if you want a safety mechanism to prevent accidental upgrade of a package which would break boot, then this should be useful.

Thanks for the response.

We tried holding the upgrade of nvidia-l4t-bootloader package, keeping our custom config file and this issue is not seen.

But is there any possibility some other issue will come since we are not upgrading this package while the rest of packages are upgrading?

The idea behind a hold is to refuse update. If no other package has a dependency on this package, then there will be no interference with anything else updating. If there is something depending on the held package, then that package would also be held back from update until the hold is released. So it depends on the chain of dependencies.

An interesting idea is to have a custom Ubuntu package which has only the action of holding a particular package (versus marking hold on command line). Then, if the package update mechanism sees an update of the package for holding (such that the custom package has a new version and releases the old hold, but creates a new hold on the replacement of the previous hold), then keeping things working would become both safe and automated through apt (there would still need to be someone creating the package which marks and releases holds).

There is an interesting command for exploring this if you know the name of a package. To find what packages depend upon a given package, run this command (I’m using package “bash” just to illustrate):
apt-cache rdepends bash