Recovering previous save due to the limitations of the former jetpack install methods

Robotics & Edge Computing Jetson Systems Jetson Nano
1

Used a ‘chroot’ method to be able to use my Nano like normal after booting via the SD card.

Unfortunately, about 6 weeks ago, I had a nice little stroke and some of my brain got wiped, including the understanding of how and what method I had used to make the Nano work like a normal computer -while- allowing me to use the full terabyte of the disk on my development system. Here is the boot extlinux config file that I used:

TIMEOUT 30
DEFAULT primary

MENU TITLE L4T boot options

LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd-xusb.img
APPEND ${cbootargs} root=UUID=(long UUID string) rootwait rootfstype=ext4

At least, this is what is on the Nano SD card boot in /extlinux now.

I remember doing the 4.4 upgrade via the “new” apt capability and was EXTREMELY happy that we could now do that and not lose all our previous code yet again.

However, then I rebooted Nano SD card after the apt update/upgrade, it looks as if I missed something, something that allowed me to ‘chroot’ from the SD card to the harddrive. And now, with the stroke, I can’t remember how I did it. So when I boot from the SD card now, the boot process hangs deep into the boot process and I can’t figure out where I need to be, I think the /boot/ or /extlinux/ is not switching over to the hard drive during the init process but I just can’t remember how to get there.

Btw also, instead of steady stream of typing that was very fast with few errors, now I have to stop and fix typing errors about every third word. I’m sure I can relearn it but it’s tedious in the meantime. :)

Do you guys think I can recover all my previous work and get the 4.4 running properly? Or must I start from scratch yet again? (Lord, I hope not!)

Thank you.

3

Unfortunately I do not know which packages are updated through apt. Possibilities are changes to device tree (the “chosen->bootargs” can provide arguments to the kernel at boot, thus this might matter), changes to the APPEND key/value pair of extlinux.conf, and to the initrd might be related. Some non-rootfs partitions may also be related, but it is hard to say without the log. Can you provide a full boot log via serial console? This would help narrow it down.

FYI, you might be able to use QEMU on the host PC and examine and manipulate packages. If you were to use dd or other tools to clone the rootfs partition, then you could experiment on rootfs on the SD, and then restore it to your clone if you don’t like the results. The entire SD card could in fact be cloned as a file (just make sure you have lots of free space on the host PC).

4

I think the “chroot” is a little bit confusing here.

Are you talking about putting rootfs on external storage but it does not work anymore after you apt upgrade?

Actually, it is possible because OTA does not support customization yet. Could you paste your full boot up log now?

Boot up log means the serial console log from uart because the booloader logs are there.