Jump to content

Tom3

Members
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tom3

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 1 GE does not use half duplex (for a long time). The original spec did permit half-duplex with a hub. Hubs have not been produced in many years. Since the advent of switches, 1G-Base-T (Cat 5 twisted pair) interfaces use full duplex. I'm going to guess that most or perhaps even all available interfaces do not support half-duplex 1GE. -- Tom
  2. On the main screen. Under Boot Device, click Flash. Next screen click 'Flash Backup' It will ask where on the client you want to put the backup. -- Tom
  3. Tried it today and the md5 hash problem is resolved. Everything appears to be working correctly. Thanks for repairing this ! -- Tom
  4. It may depend on how you are doing the deletion. For example the Ubuntu GUI File manager will by default put each file in the 'Trash' directory so they can be recovered later. This slows down massive file deletions terribly. There is a shift-delete on Ubuntu GUI that just deletes the files without this extra step, and it runs much faster. If you are deleting files using the command line from the terminal, then by default it doesn't use the trash directory. -- Tom
  5. Thanks! It's back upon re-installing Community Applications, and "Fix Common Problems" is now updatable as well. -- Tom
  6. So finally got the container to use eth1. What made this take so long is that the Docker tab in UNRAID showed the container as mapping to eth0 even when bridged to eth1. It is actually bridged to both eth0 and eth1. Here's my notes (for my own future sanity) -------------------------------------------------------------------- There are multiple uses of the word bridge in docker networking. 1. It's a Linux networking object. This can be seen with root@Tower:~# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default modem.domain 0.0.0.0 UG 216 0 0 br0 10.0.0.0 10.2.114.49 255.0.0.0 UG 227 0 0 br1 10.2.114.48 0.0.0.0 255.255.255.248 U 227 0 0 br1 172.16.0.0 10.2.114.49 255.240.0.0 UG 227 0 0 br1 192.168.0.0 0.0.0.0 255.255.255.0 U 216 0 0 br0 192.168.16.0 0.0.0.0 255.255.240.0 U 0 0 0 docker0 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Which shows that the networking bridge br1 is handling the 10.0.0.0/8 network to the gateway 10.2.114.49. root@Tower:~# brctl show bridge name bridge id STP enabled interfaces br0 8000.ac1f6b6c1fc4 no eth0 br1 8000.ac1f6b6c1fc5 no eth1 docker0 8000.02421a0073f7 no virbr0 8000.525400dab422 yes virbr0-nic Shows that br1 is using eth1 as it's interface. 2. There is a separate bridge object in Docker that is a virtual Ethernet switch with ports in the private 192.168.16.0/20 space (for the first virtual bridge). Each subsequent bridge gets the next assignment block of internal addresses. 3. A new Docker bridge object needs to be created that uses the Linux br1 This is not to be confused with the UNRAID preconfigured docker br1 bridge of type macvlan. root@Tower:~# docker network create -o "com.docker.network.bridge.name=br1" my-net This creates a new docker bridge named my-net of type bridge (the type you get when no type is specified with switch -d ...) that uses the br1 Linux bridge as the external interface. Then select the Docker tab, select the Docker Image you want, left-click and select edit. Choose Custom : my-net for the virtual bridge from the Docker drop-down list. The UNRAID window showing the container mapping doesn't show this, it shows the host default interface mapping. Both interfaces work in this specific container. -- Tom
  7. I opened up apps this morning, it it advised that there was an update, so I clicked update. That caused the APPS menu to disappear. Rebooting did not bring back the APPS menu. Anyone know how to get it back? -- Tom
  8. Thank you again for your patience! I created my-bridge of type -d bridge with the --subnet= 10.2.114.48/29 docker network inspect my-bridge looks good When selecting Custom : my-bridge in the GUI for the docker container, the displayed mappings are: App to Host 10.2.114.54:port bridge to 192.168.0.250:port So it's setting the docker app bridge internal IP address to 10.2.114.54 and routing that out to eth0. If I force the -p 10.2.114.54:port:port as an additional parameter, the docker container run crashes. I was able to get the Web GUI to work on eth1 by changing the webgui parameter in the edit panel from: http://[IP]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1 to: http://[IP:10.2.114.54]:[PORT:6080]/vnc.html?resize=remote&host=[IP]&port=[PORT:6080]&autoconnect=1 Now the container responds with a GUI on both eth0 and eth1. Progress, sort of. -- Tom
  9. Thanks. Absolutely no luck. The eth1 interface is working as I can login in to the management interface on 10.2.114.54. However when I set Custom : br1 as the network for the Docker container, it assigns 10.2.114.50 as the IP address (within the pool of 5 available). Thus I think it is using MACVLANS. I can successfully ping 10.2.114.50 and 10.2.114.54 but cannot reach the Docker container on it's defined ports. When setting the container to use Bridge, it uses 192.168.0.250 (shared with the management GUI) is pingable at that address and responds to the appropriate ports. The port mapping, etc. is the same between using 'Bridge' and 'Custom : br1' then only thing changed is the specific network. Can one add a custom bridge that is of type bridge and not of type macvlan? Does that even make sense? I cannot find 'add' anywhere. -- Tom
  10. So I've found the following file: /boot/config/network.cfg. It appears to be the one that sets up Custom : br0 and Custom : br1 # Generated settings: IFNAME[0]="br0" DHCP_KEEPRESOLV="no" DHCP6_KEEPRESOLV="no" BRNAME[0]="br0" BRNICS[0]="eth0" BRSTP[0]="no" BRFD[0]="0" PROTOCOL[0]="ipv4" USE_DHCP[0]="yes" USE_DHCP6[0]="yes" IFNAME[1]="br1" BRNAME[1]="br1" BRSTP[1]="no" BRFD[1]="0" BRNICS[1]="eth1" PROTOCOL[1]="ipv4" USE_DHCP[1]="yes" SYSNICS="2" One can see how to edit that to add another, however I don't see what parameter tells the new Custom bridge whether to use macvlan or bridge. Some posts refer to the network setting page for configuring the bridges / macvlans, but I don't see any options to add a new bridge, nor to set the parameters. eth1 (the interface eth1 I'm trying to get one specific Docker container to use) is defined in ipconfig -a and it has all the correct parameters for the interface (correct ip address, netmask, up, etc. Is there some definition of the parameters in this file to see how to configure the new bridge into bridge mode? -- Tom
  11. Same request. This has been a long rabbit trail today. I have attempted to create a new bridge that is on eth1 (10. . . address): 1. Stop Docker & VM service with GUI 2. Create a new bridge 2A. $ ip link add new_bridge_name type bridge 2B. $ ip addr add 10.2.114.49/29 dev new_bridge_name 2C. $ ip link set new_bridge_name up and that creates the appropriate entry as a bridge with the correct external ip address and bridge name, etc. 3. Edit /boot/config/docker.cfg, appending: DOCKER_OPTS="-b=new_bridge_name" 4. Start docker & VM service with GUI. The only file I could find to edit is /boot/config/docker.cfg - not sure this is the right place... or that DOCKER_OPTS is the right directive. But this just makes br1 disappear and the new_bridge_name does not appear, so can't be selected. Commenting out the #DOCKER_OPTS line and restarting Docker & VM gets br1 back. I am not using br1 because it is of type macvlan. Any advice here? -- Tom, N5EG
  12. Uncovered a little more... Ubuntu 18 can't be shutdown or rebooted from within Ubuntu VM. Instead it has to be shutdown and restarted from the Unraid Dashboard-->Apps panel using Stop and Start. That fixes up the messiness with editing the boot order. The boot order generated by the Ubuntu template appears correct without changes. -- Tom
  13. Thank you for pointing me in the right direction ! I edited the XML and reversed the boot order number. It initially had ...vdi = 1 and CDROM = 2, so flipped it the other way around. That did not solve the problem. I was able to fix it by force stopping the VM after the installation is completed (when it's asking to be rebooted), then editing the XML back to the original order before booting for the second time. The inital stop of the VM fails with an error about being unable to unmount the CDROM, which is why I have to force the stop after it hangs. -- Tom
  14. Noob to Unraid. I am trying to install an ubuntu 18.04 VM. The install goes fine until the time I have to reboot the VM the first time. Normally one has to eject the ISO (which Ubuntu thinks in on a CDROM). In VirtualBox, there is a button to eject the virtual CDROM containing the creation ISO file. I cannot seem to find the way to eject the equivalent in Unraid. After rebooting the first time Ubuntu fails with Unable to eject CDROM error in the onscreen startup text. I'm sure this is an easy one.... -- Tom