After reflashing Unbuntu via USB I cannot use Unbuntu Unbuntu credentials

I got my Nvidia Tegra K1 several months ago. I changed the password for the user Unbuntu. I tried several times to reflash the OS. I see that it completes successfully but I assume that it is keeping the password I originally made. I have searched for 2 weeks nd cannot find how to grab the shadow file in recovery mode through the USB or erase the flash before overwriting it. I just need some direction because I wanted to make my Jetson Useful. Thanks Joel

Each flash completely erases everything that was on the eMMC. Passwords and shadow files are created via whatever is in the content of the sample rootfs (a few boot-related files are edited first by the flash process, password content is not one of the edits).

You will find cloning useful in your case. See:
http://elinux.org/Jetson/Cloning

Normally a flash creates an image to be used as the complete root file system on the Jetson. It is possible to specify to reuse a previously generated image ("-r" option). The raw format of the image, if reused (versus flash generated without reusing), never gets edited by the flash software in any way. The “raw” format image can be loopback mounted and you can access any file you wish, including passwd/shadow, ssh keys, configuration files, so on. Then flashing with that image results in your edits being instantly available. A cloned image works for reusing an image (thus it also makes a great backup and restore method).

I followed the guide and wasnt able to do all the commands but i was able to pull back a full image of the TK1 and it is called all.img. I tried to use the instructions to mount it so i can make changes. It will see the contents but it is locked. Is there a idots guide or tool to mount the image i pulled back? I am sure that if I could mount the files I could see what it is using for credentials. I am able to see the system image I pulled back looks like it was dated three months ago. THis was successful
sudo ./nvflash --rawdeviceread 0 3849216 all.img --bl ardbeg/fastboot.bin --go

This did not work. sudo mount -t ext4 -o loop system.img /mnt I see the error is cannot find any loopdevice.

Thanks

Each Jetson has multiple partitions on the eMMC (most are not normally visible). The “all” variant lumps every single partition into a single binary file, concatenating them. This image can be used for restore operations, but is not loopback mountable. You’ll need to clone the root partition (“APP” partition), then you’ll be able to loopback mount, explore, edit, so on. See:
http://elinux.org/Jetson/Cloning

FYI, when I re-use a flash image, including a clone root partition image, one of my motivations is setting up proper networking and ssh keys, so you are on the right track. However, beware that half of the ssh key setup is on the Jetson, but the other half is on your desktop host…the host remembers what keys it saw during the first successful confirmed login to the Jetson…after that the host itself will refuse to connect to a client with changed keys; in that case you will either need to re-install the original keys to the client, or erase the memorized keys from the host so that the host will ask again if the keys are valid.

If you have a serial console the ubuntu account is always logged in (this may be insufficient to change something important if the password is not ubuntu and you wish to change password protected items).

ok I followed the directions for the Clone last time and got a system file. I was unable to mount it so I tried the All file. I followed the directions successfully till i tried to mount the system img. I click on system.img and I get the error msg

Error mounting /dev/loop11 at /media/joel/513b6bcf-3528-4766-bfcd-cabc2b8ec06b: Command-line `mount -t “ext4” -o “uhelper=udisks2,nodev,nosuid” “/dev/loop11” “/media/joel/513b6bcf-3528-4766-bfcd-cabc2b8ec06b”’ exited with non-zero exit status 32: mount: block device /dev/loop11 is write-protected, mounting read-only
mount: wrong fs type, bad option, bad superblock on /dev/loop11,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail

thats says
joel@joel-Aspire:/mnt/etc$ dmesg | tail
[36495.128756] EXT4-fs (loop11): write access unavailable, cannot proceed
[36565.578382] EXT4-fs (loop11): INFO: recovery required on readonly filesystem
[36565.578396] EXT4-fs (loop11): write access unavailable, cannot proceed
[36573.045343] EXT4-fs (loop11): INFO: recovery required on readonly filesystem
[36573.045359] EXT4-fs (loop11): write access unavailable, cannot proceed
[36608.395396] EXT4-fs (loop11): mounted filesystem with ordered data mode. Opts: (null)
[36659.532230] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
[37317.127280] systemd-hostnamed[6320]: Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname!
[37343.670914] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
[37775.324968] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)

Make sure that you make all mount attempts as user root (using “sudo” satisfies this). I’m not sure about that large mount command, I’d just use this and let the system figure it out:

sudo mount -o loop /some/path/to/clone/system.img /mnt

…the system.img refers to the cloned root partition, which is a “raw” file system…this won’t work with a “sparse” image.

Do be sure that your system disk is not full, use “df -H /” to see your desktop’s root partition capacity. Mounting a loopback image will not change this, but creating the image can be an issue if not enough disk space is available.

I have been trying for a long time to understand this process. I was able to pull back the system image and I can issue the sudo mount -t ext4 -o loop system.img /mnt command and it puts it somewhere. I am not sure but I assume it is on my desktop computer. I am using Unbuntu 14.04. I assume that command puts it in the root directory under /mnt. I also can see the Nvidia TK1 as 15 gig attached via the mini dim usb cable. I just cannot copy the etc file so I can crack whatever password it has on it. All I really want to do is flash the whole system back to what it shipped with. Is there an easy way to do this? I assume the cd …/
sudo ./flash.sh -r -S 14580MiB jetson-tk1 mmcblk0p1
would do this but I am afraid it is going to copy the backup of my current files from the bootloader and put it right back on the TK1. This would still leave me with the unknown password right?

Hoping my reply gets through, been having issues with access.

The sudo ./flash.sh command without “-r” will restore to a new state, including ubuntu/ubuntu login. With both the “-r” and the cloned image in the correct place, it will put the cloned copy in instead. If you previously mounted this on /mnt, then edited something like /mnt/passwd and /mnt/shadow, umounted, and put this at the location required, then the “-r” will effectively edit the password.

From the Linux_for_Tegra_tk1 folder i issued the command from my pc in terminal
sudo ./flash.sh -r -S 14580MiB jetson-tk1 mmcblk0p1
It appears that it reflashed the TK1 but when I type passwd and use unbuntu for the current password it says Authentication token manipulation error.

sorry the command i sent was without the -r
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1

1766 CHUNK 15288238080(3732480 blks) ==> 2372330212(579177 blks)

done.
system.img built successfully.
copying dtbfile(/home/joel/Downloads/TK1/Linux_for_Tegra_tk1/kernel/dtb/tegra124-jetson_tk1-pm375-000-c00-00.dtb)… done.
copying cfgfile(/home/joel/Downloads/TK1/Linux_for_Tegra_tk1/bootloader/ardbeg/cfg/gnu_linux_fastboot_emmc_full.cfg) to flash.cfg… done.
creating gpt(ppt.img)…

*** GPT Parameters ***
Device Sector Size ------- 512
device size -------------- 15766388736
bootpart size ------------ 8388608
userpart size ------------ 15758000128
Erase Block Size --------- 2097152
FS Buffer size ----------- 4096
Partition Config file ---- flash.cfg
Visible partition flag — GP1
Primary GPT output ------- PPT->ppt.img
Secondary GPT output ----- GPT->gpt.img
Target device name ------- none

*** PARTITION LAYOUT(20 partitions) ***
[ BCT] BH 0 16383 8.0MiB
[ PPT] UH 0 4095 2.0MiB ppt.img
[ PT] UH 4096 8191 2.0MiB
[ EBT] UH 8192 16383 4.0MiB u-boot.bin
[ LNX] UH 16384 49151 16.0MiB
[ SOS] UH 49152 61439 6.0MiB
[ NVC] UH 61440 65535 2.0MiB
[ MPB] UH 65536 77823 6.0MiB
[ MBP] UH 77824 90111 6.0MiB
[ GP1] UH 90112 94207 2.0MiB
[ APP] UV 94208 29954047 14580.0MiB system.img
[ DTB] UV 29954048 29962239 4.0MiB tegra124-jetson_tk1-pm375-000-c00-00.dtb
[ EFI] UV 29962240 30093311 64.0MiB
[ USP] UV 30093312 30101503 4.0MiB
[ TP1] UV 30101504 30109695 4.0MiB
[ TP2] UV 30109696 30117887 4.0MiB
[ TP3] UV 30117888 30126079 4.0MiB
[ WB0] UV 30126080 30130175 2.0MiB
[ UDA] UV 30130176 30773247 314.0MiB
[ GPT] UH 30773248 30777343 2.0MiB gpt.img
copying flasher(/home/joel/Downloads/TK1/Linux_for_Tegra_tk1/bootloader/ardbeg/fastboot.bin)… done.
Existing flashapp(/home/joel/Downloads/TK1/Linux_for_Tegra_tk1/bootloader/nvflash) reused.
*** Flashing target device started. ***
./nvflash --bct PM375_Hynix_2GB_H5TC4G63AFR_RDA_924MHz.cfg --setbct --configfile flash.cfg --create --bl fastboot.bin --odmdata 0x6009C000 --go
Nvflash 4.13.0000 started
BR_CID: 0x34001001740de1001c0000000b058340
rcm version 0X400001
Skipping BoardID read at miniloader level
System Information:
chip name: unknown
chip id: 0x40 major: 1 minor: 1
chip sku: 0x0
chip uid: 0x00000001740de1001c0000000b058340
macrovision: disabled
hdcp: disabled
jtag: disabled
sbk burned: false
board id: 0
warranty fuse: 0
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0

RCM communication completed
BCT sent successfully
sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb

  • 59637/59637 bytes sent
    tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
    odm data: 0x6009c000
    downloading bootloader – load address: 0x83d88000 entry point: 0x83d88000
    sending file: fastboot.bin
  • 594363/594363 bytes sent
    fastboot.bin sent successfully
    waiting for bootloader to initialize
    bootloader downloaded successfully
    ML execution and Cpu Handover took 1 Secs
    Partition backup took 0 Secs
    setting device: 2 3
    deleting device partitions
    creating partition: BCT
    creating partition: PPT
    creating partition: PT
    creating partition: EBT
    creating partition: LNX
    creating partition: SOS
    creating partition: NVC
    creating partition: MPB
    creating partition: MBP
    creating partition: GP1
    creating partition: APP
    creating partition: DTB
    creating partition: EFI
    creating partition: USP
    creating partition: TP1
    creating partition: TP2
    creating partition: TP3
    creating partition: WB0
    creating partition: UDA
    creating partition: GPT
    sending file: ppt.img
    \ 2097152/2097152 bytes sent
    ppt.img sent successfully
    padded 12 bytes to bootloader
    sending file: u-boot.bin
  • 440016/440016 bytes sent
    u-boot.bin sent successfully
    sending file: system.img
    | 2372330212/2372330212 bytes sent
    system.img sent successfully
    sending file: tegra124-jetson_tk1-pm375-000-c00-00.dtb
  • 59637/59637 bytes sent
    tegra124-jetson_tk1-pm375-000-c00-00.dtb sent successfully
    sending file: gpt.img
    \ 2097152/2097152 bytes sent
    gpt.img sent successfully
    Create, format and download took 216 Secs
    Time taken for flashing 219 Secs
    *** The target ardbeg has been flashed successfully. ***
    Reset the board to boot from internal eMMC.

Did that work? The flash log looks correct.

no the error msg tells that when i use unbuntu as a password it is invalid. When I use it other places it says Authentication token manipulation error. I also noticed today that if i open a browser and go to youtube the sounds stops working after about a minute. Is it possible that the hardware is the problem?

It is very unlikely a hardware failure would do this without other symptoms…like total failure. This really seems like a software issue.

One possibility…not common…but something to eliminate…is that the sample rootfs must itself be not only unpacked sudo (or as root), but must be unpacked onto a native Linux file system…e.g., NTFS or VFAT would cause strange errors after the flash, but not during the flash. Looking at the loopback mounted system.img.raw could verify some things.

After you did the flash, it looks like you said your “bootloader/system.img.raw” file is still there. When you do the “sudo mount -o loop system.img.raw /mnt”, the content of “/mnt” is replaced by the file system exactly as it would appear on the Jetson. Look at file permissions of files in places owned by root, like “/usr/bin” (from your host, “sudo -s ; cd /mnt/usr/bin” to get to that), and especially look for permissions of the “sudo” binary itself (it’s in one of the bin or sbin directories, I’m not where I can verify exact location right now)…see if those files seem to generally match between loopback mount and the sample rootfs from which they were created onto the loopback device. Similar for files in “/mnt/dev” (which would be “/dev” on the Jetson).

ok I reloaded Unbuntu and downloaded drivers and started over. I did the os reinstall and I got the same result. I looked at the permissions for the /usr/bin" (from your host, “sudo -s ; cd /mnt/usr/bin” and it says that I am not the owner and I only have read permissions. It also says some files may not be accessible. i tried to reflash without the -r and it did not guess after mounting those files root has read access only.

In order to access root ownership files on the loopback clone image under “/mnt”, you need to be root. One way to do that for a lot of commands if you don’t want to prefix everything with “sudo …” is:

sudo -s
...do a bunch of things.
# Now go back to normal "ubuntu" non-root account...
exit

Any time you go to mount or umount a clone image, you need to be root or sudo. Every time you edit files in the loopback mounted image which were owned by root, e.g., passwd or shadow files, you need to be root. Any time you unpack or modify the sample rootfs prior to a flash (including apply_binaries.sh), you need to be root. Any time you need to create or manipulate a loopback device which doesn’t already exist, you need to be root…during flash if there is a spare loopback device it will just use that, not requiring root…but if there are not enough loopback files in “/dev”, another will be automatically created (“automatic” breaks if you are not root, it may not bother to tell you this)…needing root.

So after cd to /mnt/usr/bin, “ls -l ./sudo” should show:

-rwsr-xr-x 1 root root 138464 Aug 27  2015 sudo

You could restore pass and related files via copy (as root) of “rootfs/etc/<whichever_file>” to “/mnt/etc/”.

One thing to consider is that if your Jetson is accessible to a public network (e.g., without a router protecting it), then the default login will get hacked extremely fast…a case where flash would work but then mysteriously stop working.

There may be a rare case where a host mounting a file system might see some SElinux interference, but except in that case root should be able to edit anything in the loopback image if it was not mounted read-only.

i once again followed directions wiped and reloaded the Tk1 this time when i try and mount i get this error

sudo mount -t ext4 -o loop system.img /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Remember…each time you flash without “-r” option, within the bootloader subdirectory is a new system.img.raw, and from that a compressed/sparse system.img is created. Sparse images cannot be mounted, only raw images can be mounted. If your clone was at system.img or system.img.raw in the bootloader subdirectory and you ran a non-reuse-image flash, it was all overwritten.

What was the exact type size of the image you tried to mount? This can tell you whether it was compressed/sparse or not. If it is a few GB it is too small and is compressed. If it is roughly 15GB it might be correct…exact size can be used to figure if it is valid.

Just double checking the easy solution- Are you typing “unbuntu” or “ubuntu” as your password? You’ve consistently spelled it “unbuntu” and no one has mentioned that’s not correct.

Thank you Andy for Checking. I finally tried to put Fedora on there and when I put Ubuntu back I was able to change it. I will admit that I am bad a typing but i was doing copy and paste on the username and password. It is possible though that I might have done that in the past. Thanks for all the help.