boot failed after change the extlinux.conf

Autonomous Machines Jetson & Embedded Systems Jetson TX1
#1

I run into a problem about booting when I follow the tutorial to install the SSD as the internal storage (https://www.jetsonhacks.com/2017/08/05/develop-on-ssd-nvidia-jetson-tx1-and-jetson-tx2/#mh-comments)
after change the extlinux.conf
as
TIMEOUT 30
DEFAULT primary
MENU TITLE p2371-2180 eMMC boot options
LABEL primary
MENU LABEL primary kernel SSD
LINUX /boot/Image
INITRD /boot/initrd
APPEND {cbootargs} root=/dev/sda1 rw rootwait LABEL eMMC MENU LABEL eMMC kernel LINUX /boot/Image INITRD /boot/initrd APPEND {cbootargs} root=/dev/mmcblk0p1 rw rootwait

my tx1 failed to boot.
It shows
tegra-pcie 1003000.pcie-controller: PCIE: Disable power rails
random: nonblocking pool is initialized
…

I know I mistakenly write the PCIE or sata boot in the extlinux.conf. Actually what I have is a usb 3.0 ssd.

Can anybody help me with that, please.
Now I need to recover the original extlinux.conf (which I have saved before the change) and modified the extlinux.conf file in the correct way. Thanks very much

#2

You may use a serial console. It will allow you to select in uboot which config you want. It is useful when playing with extlinux.conf for trying a config and set it as default only when it works.

If you don’t have a serial adapter, you can also clone the rootfs partition from Jetson to your host, then loopback mount the clone image on host, edit your extlinux.conf, and reflash your fixed rootfs partition into Jetson. This may take a couple of hours.

#3

Thanks very much, but I don’t have that serial adapter, is there any easier method to recover the extlinux.conf? Thanks very much

#4

I’m sorry, but I can’t think about another way from the two above mentioned… Someone else may know another method.

Anyway, the serial adapter is only a few dollars and is for sure a good investment if you plan to try various extlinux.conf configs.

#5

Other than clone/edit/restore (or having a serial console…about $20) the only way I can think of is if you have a rescue SD card. In that case, if and only if the default search path for extlinux is able to find and use the SD card version of extlinux.conf before finding the eMMC version, then the SD system would boot and you’d be free to edit extlinux.conf after mounting mmcblk0p1 as a non-root partition.

Btw, cloning the rootfs onto an SD card makes a good rescue system. You’d basically clone it onto the first partition with the partition being an exact size match to the running TX1’s rootfs…then edit the extlinux.conf. You don’t have to do it this way, but there are a lot of advantages to your rescue being a full and exact match. It becomes its own backup.

You can clone to a PC and then use dd to write the raw clone to the SD card’s first partition. As mentioned, the trick is that the partition must be the exact size of the raw clone.

#6

Thanks very much for your reply, what is the tool dd to write the raw clone? Now I follow the second recommend from @Honey_Patouceul to clone the rootfs partition from Jetson to your host and try to edit the raw clone and edit my extlinux.conf, and reflash my fixed rootfs partition into Jetson.
BTW, what kind of serial console should I buy, my friend tell me there is special type TTL one ? right?

#7

You may buy this one or similar.

#8

FYI, when the cable says it is “TTL”, or when it says “3.3V”, the cables are the same and are what the TX1 uses. If it mentions an FTDI chipset, then it is better because each serial USB cable potentially has a different driver, but FTDI is almost always there by default (sometimes other brands are as well…sometimes not, though drivers can almost always be added…but you will likely want to avoid adding a driver to your host PC).

If extlinux.conf is correctly modified to add a boot entry, and does not replace the existing boot entry, then you’d just pick the working entry during boot and be done. If not, read on.

“dd” is a command line Linux tool. This tool directly reads the bytes of data from a disk based on offset, and does not need a file system. For example, it can recover some parts of a failed partition which is too damaged to be mounted or read as ext4. If you use dd to create an exact copy of a partition at the correct offset, then it can be called a clone.

The “driver package” (which JetPack downloads) has some similar abilities if the Jetson is connected to the host in recovery mode. The “flash.sh” script, given the right arguments, can also determine the correct offsets of the rootfs partition (“mmcblk0p1”), and make an exact copy to your host PC. Same thing, but dd requires a rescue disk to run on the Jetson, whereas flash.sh runs on the PC and talks to a recovery mode Jetson over the micro-B USB cable. The exact instructions for using flash.sh to clone depends on which version of L4T you use.

FYI, when you flash a Jetson you will generate (within the “Linux_for_Tegra/” directory) file “bootloader/system.img.raw”. “system.img.raw” is 100% an exact duplicate for the backup.img.raw created from clone under flash.sh, and is also an exact match for using dd to read the rootfs partition while using a rescue disk.

All of those above files (system.img.raw, backup.img.raw, and system.img.raw), when renamed as “bootloader/system.img”, are what the Jetson flashes. If you have passed the “-r” argument to flash.sh, then whatever is there now gets flashed. If you fail to pass “-r”, then the existing system.img (if any) is overwritten with one that is nearly the same as the sample rootfs within the “rootfs/” directory on the host. “system.img” is just a “sparse” version of the “raw” “system.img.raw”. Raw images are exact images, sparse images are sort of a way of compressing. Flash software allows either the sparse image to be used (it’s fast to flash) or a raw image (it’s slow to flash) to be used.

The raw image is the only one you can work with. A sparse image is only for flashing. No open source tools are able to handle the version of sparse image used.

If you wish to clone, then you should clone using the same L4T version as that on your Jetson. Technically you can clone with a newer version and it won’t hurt, but if you use the newer version to actually flash and restore, then it won’t work. So you might as well start with the correct version.

Can you tell us which L4T version is on the TX1 now? If not, does the directory on the host still exist from which you flashed? If so, then the “Linux_for_Tegra/rootfs/etc/nv_tegra_release” file’s first line tells the version.

#9

Thanks very much, I really appreciate. I had successfully recovered my etxlinux.conf file use the recovery model and edit the .img.raw file and flash the system back.
but sadly my end goal is to add my external usb ssd as the main home partition by editing the extlinux.conf file. I follow the tutorial https://www.youtube.com/watch?time_continue=172&v=LQqePvjnKws&t=488s here, and I failed several times. I have found the feed here https://devtalk.nvidia.com/default/topic/1026273/jetson-tx1/how-to-boot-tx1-from-usb-drive-from-r28-1-jetpack-3-1-/, it seems like many users have this problem. But I still cannot figure it out. The [U-Boot Customization] in https://developer.nvidia.com/embedded/dlc/l4t-documentation-28-1 is not very helpful and hard to follow indeed. up-to-now is there any way to set the external usb drive as the main home partition? My serial console has not arrived yet, but it won’t matter about the end goal (just some more time to flash maybe).
and refer to the “Linux_for_Tegra/rootfs/etc/nv_tegra_release”, the first line is

R28 (release), REVISION: 2.0, GCID: 10567845, BOARD: t210ref, EABI: aarch64, DATE: Fri Mar 2 04:58:16 UTC 2018

so I guess it is L4T 28 version
Thanks very much

#10

I wouldn’t advise experimenting until you get the serial console. You can test different setups without risk that way.

Something which you should know about boot in general, when going through USB, is that the bootloader itself has a USB driver (at this boot stage Linux does not exist). If the driver does not need to reload between bootloader stage and the Linux kernel taking over, then continuity of service is good and the scheme works. On the other hand, the driver in U-Boot is USB2. If you have set the USB hard drive as the source of a file system needed during boot (e.g., kernel modules), and if the USB driver reloads (e.g., to go to USB3 mode using a new driver), then continuity of service is broken and boot will fail at that point. So you need to make sure that if U-Boot is USB2 and if the hard drive is needed to load the boot environment, then you cannot use USB3 mode.

“lsusb -t” will show “480M” for USB2 nodes, and “5000M” for USB3 modes. Make sure the USB hard drive is “480M” when booting normally to eMMC prior to making it the boot devices.

Understand that one can have the kernel and extlinux.conf on eMMC and tell it to mount “/” from a USB hard drive without much of a problem…provided all requirements to boot are integrated into the kernel (or if the USB hard drive is fully accessible from U-Boot through Linux kernel without any moment of loss). If it turns out the kernel is told to use USB3 mode, and the drivers required are in “/lib/modules/$(uname -r)/” instead of being integrated, then you have a “catch 22” and boot breaks (the USB controller has to reset and load a new driver…from a disk it doesn’t have access to because it is a USB disk in the process of resetting).

None of this is hard to deal with if all you have to do is pick the original boot entry to recovery via serial console. Without that every single failure will probably require flashing the TX1.