Disabling NVIDIA boot up messages

Sounds like you’ve been dropped to a single-user minimal shell, main filesystems not mounted. See if you can revert the change thet led to this using the minimal shell you’re in or reflash to a sane state.

I guess you removed the root=mmcblk0p1 in kernel cmdline accidentally. Please check if this is showing up in kernel message during boot up.

Thanks @WayneWWW for reply.

I am not receiving the message regarding root=mmcblk0p1 and I have not edited anything with root command.
With the bash prompt I can only browse through following file tree –
bin dev etc init lib mnt proc root sbin sys tmp use var

Is there any file that I can go into and make changes?

Are you able to see anything via this command:
cat /proc/cmdline

If so, then this would tell you about the “root=/dev/mmcblk0p1” argument to the kernel. You might even be able to see device tree in “/proc/device-tree/”.

Hi @linuxdev

after running the cat /proc/cmdline, I got
console=tty0, quiet

This is the same configuration that I used in extlinux.conf file
How can I delete the console=tty0 inorder to get everything back to work in normal way

I opened the device tree from command cd /proc/device-tree/, it shows the files (please see the attached image)proc command|666x500

This is far too small for a valid command line. Here is a typical example of how long that line should be on a TX2 (this is all a single line even though the forum might line wrap):
root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

Somewhere the “console=tty0,quiet” replaced the entire command line, rather than appending to it. Also, if there is a space between “tty0,” and “quiet”, then this is an error. Individual arguments to different drivers are separated via a space as a delimiter. When multiple arguments are given to an individual driver, then a comma separates those arguments (without spaces). This means the “console=tty,” is in error, and still needs an argument after the comma, without using spaces. Going directly from a comma to a space should never occur.

If you examine a command line in the older extlinux.conf when this was not seeded with the device tree “chosen->bootargs” entry, there would be one very long line to do so, without any newline/linefeed. Example from my earlier example, had it been purely through extlinux.conf:

APPEND root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

Notice in that example the key word “APPEND”. The extra content was intended to go on the end, and not replace previous content. So for example, if my “chosen->bootargs” entry in device tree were this:

root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

…then my “APPEND”, to add “quiet”, would simply be:
APPEND quiet
…which would have resulted in “cat /proc/cmdline” showing (differing only by a space and the word “quiet” at the end):

root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x2772e0000 gpt usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 bl_prof_dataptr=0x10000@0x275840000 sdhci_tegra.en_boot_part_access=1 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 quiet

…note the space and the word “quiet” appended to the end of the content that was in the device tree.

Basically, your kernel, even if perfectly valid, has no chance to boot because it has a very messed up command line. To be clear, some content should exist based on the device tree’s “chosen->bootargs” node. Content from the extlinux.conf’s “APPEND” key/value pair would append to the end of this. Arguments from “APPEND” would all be on a single line, and a space is used between individual driver command lines. Commas are used for multiple arguments within a single driver, and no comma should ever have a space directly after it.

Perhaps the device tree “chosen->bootargs” never loaded. Perhaps confusion with the comma followed by a space broke something. Perhaps an incorrect signature caused the device tree “chosen->bootargs” to be rejected. Perhaps a modified kernel did not have the right configuration to load “chosen->bootargs”. I do not know, but it will be mandatory to fix this before you continue.

Thanks @linuxdev for the detailed explanation.

While I was expermenting to disable boot up messages I deleted cbootargs after APPEND and made it like APEEND console=tty0, quiet(may be there is also a space between those arguments as you mentioned). That’s why I don’t see the large command output.

Is there any way that I can change this line or I have to reinstall ubuntu on tx2?

The “${…}” syntax containing the “cbootargs” is a macro to expand the content to inherit from earlier stages. This would cause failure to boot. You would instead want to add a space and then your extra content. A more typical line would be this (note I added “quiet”, but the rest is from an R32.1 TX2):

APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 quiet

The “console=” needs a longer explanation. In most cases, if an argument shows up twice or more, then only the last version of the argument is used. Consoles are somewhat of a special case since there can be more than one console, e.g., directly at the monitor, and on serial port. The normal location of this when earlier boot stages are passing this along prior to Linux loading (and this is what CBoot is, an earlier boot stage) is the device tree “chosen->bootargs”. I don’t know how to explicitly name “console=tty0” to override it since so far as I know this only names a console, and does not allow something like “console=0” to disable. I think you’re going to have to adjust this in the device tree (at least for “console=tty0”) to remove this argument.

Note that you could still have the “quiet” in the extlinux.conf’s “APPEND” key/value pair. There could be some advantage to leaving it in extlinux.conf since only a file edit would be required to see that content again if you want. The “console=ttyS0,115200n8” should be left alone since this is purely serial console you want this (there will be no output to a regular terminal from this, only the serial console would see this). However, you could add “quiet” (with a space separating it) in the device tree “chosen->bootargs” node if you wish.

Note: There is reason to inherit from cbootargs, this was not done arbitrarily. This is a case of earlier boot stages needing the content, but being unable to read an ext4 filesystem.

I deleted cbootargs after APPEND and made it like APEEND console=tty0

That it why causing such problem. Some cbootargs are added to your cmdline during flash.

p2771-0000.conf.common:
CMDLINE_ADD=“console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0”;

Thank you @linuxdev for pointing me into the right direction.

I saw the chosen directory in device tree and ‘bootargs’ when I used ls command for ‘chosen’ directory. I am not sure how can I open and edit ‘bootargs’ to add the APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 quiet from bash prompt.

I am very new to the kernel boot system and tx2. Thankyou for helping me and providing all the details.

Thanks @WayneWWW

Where can I find this file p2771-0000.conf.common?

Linux_for_Tegra/p2771-0000.conf.common

I could not find this under device tree directory. Where should I look for its root folder?

The “.conf” files are part of the L4T flash software and do not go into the rootfs. Changes to this may change device tree or other boot options depending on the arguments passed to the flash software. It is possible that changing this conf file will indirectly cause a change in the generated image.

Thank you @linuxdev for your help.

I am not able to find the files or directories. So I am planning to reflash tx2 with ubuntu. I will let you know if I got success in having my tx2 running back to normal.

If you have actually flashed once with a particular JetPack/SDK Manager release, then the content of the “Linux_for_Tegra/” directory and “Linux_for_Tegra/rootfs/” would have been filled in. Presumably, this would also include creation of “Linux_for_Tegra/p2771-0000.conf.common” without any special steps on your part (other than using JetPack/SDKM to trigger install…you can manually create this content as well with the driver package and sample rootfs…SDKM is just a front end to do this).

In cases where JetPack/SDKM fails to create content it is often due to the network being unable to retrieve the file manifest. The manifest provides a number of web URLs to pull various content from, and if one of those addresses fails, then so does the creation of that content within the “Linux_for_Tegra/” subdirectory.

Thanks @linuxdev

While I was working to flash the TX2, wires on the board got some short circuits causing the hardware to fail. Now I am using new board that is already flashed. I still will be doing the disabling of the boot up messages later this week. I will let you know in case I will need help.

Thanks again for helping me so much.

Hi @linuxdev

Now I am working to disable the boot up messages again.
I tried adding loglevel=3 after APPEND=${cbootargs} but nothing happened.

Can you suggest any other way to do this?

Thanks