Though this doesn't mean that usb0 would have to be considered as an error by itself, it leads me to speculate:
If you'd had plugged your Chromecast to the PWR port at least once, I suspect that Raspbian may not have detected the USB device correctly, and you are somehow stuck with that partial or incorrect detection.
Ahh I see, this could be correct. When I first set up my raspberry pi, I believe I did in fact have the Chromecast initially plugged into the PWR port. Should I try doing a completely fresh install from the beginning?
To try to encourage device detection, did you try to start your Zero when powered by a dedicated PSU via the normal PWR port before plugging your Chromecast Ethernet PSU into USBwithout any external/additional power attached?
This is a route I can test out but I do not have a dedicated PSU with me right now, I will have to purchase one. I thought everything would just work smoothly so I only bought the minimum necessary where this adapter would act as both a PSU and Ethernet adapter.
Your lsusb output would imply you don't have any USB device attached. Is your Chromecast plugged into your Zero at the moment?
Yes, the Chromecast Ethernet Adapter is plugged into the USB port as can be seen in these pictures:
This is what /etc/dhcpcd.conf shows, I think everything is left at default and unchanged.
pi@raspberrypi:~ $ sudo nano /etc/dhcpcd.conf
GNU nano 3.2 /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
I wouldn't normally recommend the following, but if you'd happen to own a phone charge cable that would fit the RPi's port, you could try to power your Zero via another computer's USB port.
Providing your RPi's power in that way is not advisable in general.
Peaking at about 400mA on startup and drawing well below 200mA during normal operation, the RPi Zero is the only model forgiving in that regard. You shouldn't connect anything that draws additional power to the GPIO pins, though (if yours is a Zero WH).
This could also be true if you intend to power your Zero via the Chromecast later on. The current model ist listed with 1.5A, but older versions sported some ~800mA, and that is even lower than the 900mA a USB2 port is specified at.
I run some Zeros on a 1A PSU, so if I had to choose, I'd opt for the beefier model.
I used a different command to access /etc/dhcpcd than I did in the initial post, not sure if that is the reason for the different file.
This is the result from "sudo grep -v '#|^$' /etc/dhcpcd.conf"
pi@raspberrypi:~ $ sudo grep -v '#|^$' /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface eth0
static ip_address=192.168.1.86/24
static routers=192.168.1.254
static domain_name_servers=192.168.1.254
And this is the result from "sudo nano /etc/dhcpcd.conf"
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
option interface_mtu
# Most distributions have NTP support.
#option ntp_servers
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private
# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1
# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
interface eth0
static ip_address=192.168.1.86/24
static routers=192.168.1.254
static domain_name_servers=192.168.1.254
(I didn't realize there was an additional page to scroll down and copy in this one, I've added it here)
Have you modified /etc/network/interfaces for usb0 ?
I'm not sure, is there a way to check?
Thank you to everyone so far who has been so kind and patient assisting me by the way, I really appreciate it and this community that you've built here.
Okay, I think the best course of troubleshooting would probably be to start over again from the beginning and take things step by step. Is there anything I need to undo here before I reformat the sd card (ex. change the static ip address?).
Also, where would be the points during the setup process where I can check to make sure I've connected to eth0, would the first point of knowing be during the setup when you choose (Expecting to see usb0, eth0, and wlan0)?
Just make sure you pick a different IP address for each network interface, e.g. .2 for wlan0 and .3 for the one associated with your Chromecast, be that usb0 or eth0.
Also, if you configure static IP addresses on device (e.g. via /etc/dhcpcd.conf), pick IP addresses outside of your DHCP pool's range.
You may also want to reverify your router's DNS settings, probably reverting them to defaults if you did already use Pi-hole over your RPi's wifi interface.
When flash the SD card fresh (without Pi-hole), messages in the kernel ring buffer should confirm loading that g_ether driver successfully resulting in a usb0 (or eth0) interface being added:
dmesg -T | less -p g_ether
lsmod
ip link show
If you have a carrier, you can proceed with assigning a static IP address to that interface plus reboot:
If that results in having an IP assigned to the usb0/eth0 interface:
ip -br -4 address show
You can proceed with the Pi-hole installation.
But I dont believe installing Raspbian/PiOS fresh will solve your NO-CARRIER issue.
EDIT: Ow one more thing, with the current setup, could you post output for below pls after a fresh reboot ?
dmesg -T | grep -A5 -B5 'usb0\|g_ether'
EDIT2: Allot of info on below blog (most based on Jessie release though!):
I believe it might have something to do with the USB port being either in OTG host mode or device mode.
In host mode, you probably see the other Chromecast end as usb0.
In device mode it probably switches to eth0 reflecting the Pi-hole end and what seems to be requered for your case.
