So after a powercut, the xavier is stuck in a boot loop. Is this a common issue? Due to the nature of my application, there could often be power cuts. Is there any way to prevent the xavier from this boot loop and how to get out of it?
Thanks
Hi,
Have you seen any error in the boot log? Sudden powercut is not good, but we have the experience of powercut after booting to Ubuntu desktop, and then the system still can be powered and booted up successfully.
The rootfs is itself ext4, which is journaled, but journal replay can result in missing files. You really need the serial console boot log to know what is going on.
Hello DaneLLL and linuxdev,
I’ve tried a “dmesg --follow” and the following is a output of the boot up, since it is a boot loop I’ve cut it off when the device rebooted.
[ 3932.107184] usb 2-3: new SuperSpeed USB device number 17 using xhci_hcd
[ 3932.128003] usb 2-3: New USB device found, idVendor=0955, idProduct=7020
[ 3932.128008] usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3932.128011] usb 2-3: Product: Linux for Tegra
[ 3932.128014] usb 2-3: Manufacturer: NVIDIA
[ 3932.128017] usb 2-3: SerialNumber: 0423218011697
[ 3932.130211] rndis_host 2-3:1.0 usb0: register ‘rndis_host’ at usb-0000:00:14.0-3, RNDIS device, 72:54:86:79:71:34
[ 3932.131348] cdc_acm 2-3:1.2: ttyACM0: USB ACM device
[ 3932.132870] usb-storage 2-3:1.4: USB Mass Storage device detected
[ 3932.133251] scsi host6: usb-storage 2-3:1.4
[ 3932.135289] cdc_ether 2-3:1.5 usb1: register ‘cdc_ether’ at usb-0000:00:14.0-3, CDC Ethernet Device, 7e:bd:7a:d0:6f:22
[ 3932.163609] rndis_host 2-3:1.0 enp0s20f0u3: renamed from usb0
[ 3932.211694] cdc_ether 2-3:1.5 enp0s20f0u3i5: renamed from usb1
[ 3932.228259] IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u3: link is not ready
[ 3932.250562] IPv6: ADDRCONF(NETDEV_UP): enp0s20f0u3i5: link is not ready
[ 3933.160166] scsi 6:0:0:0: Direct-Access Linux File-Stor Gadget 0409 PQ: 0 ANSI: 2
[ 3933.160904] sd 6:0:0:0: Attached scsi generic sg1 type 0
[ 3933.160983] sd 6:0:0:0: Power-on or device reset occurred
[ 3933.161348] sd 6:0:0:0: [sdb] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
[ 3933.161484] sd 6:0:0:0: [sdb] Write Protect is on
[ 3933.161488] sd 6:0:0:0: [sdb] Mode Sense: 0f 00 80 00
[ 3933.161613] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
[ 3933.166343] sdb:
[ 3933.167416] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[ 3948.263202] cdc_acm 2-3:1.2: failed to set dtr/rts
[ 3950.334943] usb 2-3: USB disconnect, device number 17
I also tried using minicom, and all I could get was this before the device rebooted. Any ideas? The name of the Xavier is empress.
Welcome to minicom 2.7.1
OPTIONS: I18n
Compiled on Aug 13 2017, 15:25:34.
Port /dev/ttyACM0, 10:45:30
Press CTRL-A Z for help on special keys
Ubuntu 18.04.3 Lempress
empress login: ATPassword:
Ubuntu 18.04.3 LTS empress ttyGS0
empress login: ATPassword:
Additionally, in the boot message displayed on a monitor, it says “failed to start load kernel modules” and “failed to start nvidia bluetooth/wifi init script”.
Try gtkterm (“sudo apt-get install gtkterm”) instead of minicom (minicom can end up sending text you did not intend since it was a modem program and not just a serial console…I trust gtkterm more and it is simpler to use, plus the option to log to file is easy to use). On your host side, if the serial cable shows as “/dev/ttyUSB0”, then:
# If you are a member of group "dialout":
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
# Or use root:
<b>sudo</b> gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyUSB0
Have you modified the kernel? The failure to start load kernel modules could be from an incorrect CONFIG_LOCALVERSION. If you can get far enough in boot, what do you see from “uname -r”?
If the kernel is not modified, then it may simply be the cut power has damaged the file system too much for the journal to recover.
In addition to what linuxdev already pointed out about modules I’ve seen what could look like a boot loop if the root filesystem is full. Sometimes a misbehaving program will flood syslog with messages and rapidly fill the filesystem.
If you are able to login via the serial console run df -h to check filesystem use. If the root is full and the log files are at fault then sudo rm /var/log/syslog* will recover your system for you at the expense of losing log data. Generally, in these cases, the log data is useless anyhow.