Re: [Lxc-users] Ltsp on LXC: PXE-E32: TFTP open Timeout
Osvaldo Filho wrote: I get this error on thinclient boot: PXE-E32: TFTP open timeout Can you give the version and the configuration of lxc, the host configuration, the kernel version, and the circumstances of the problem ? Thanks -- Daniel -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Ltsp on LXC: PXE-E32: TFTP open Timeout
Osvaldo Filho wrote: Host Environment: Linux ltspserver01 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux lxc 0.6.5-1 Linux containers userspace tools === lxc.utsname = ltsp2 lxc.tty = 4 lxc.pts = 1024 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.rootfs = ./rootfs lxc.mount = ./fstab.lxc #lxc.cgroup.cpuset.cpus = 0 lxc.network.ipv4 = 192.168.6.2/24 lxc.network.hwaddr = 0a:22:3c:4d:55:ff #lxc.cgroup.devices.deny = a # Deny all access to devices lxc.cgroup.devices.allow = c 1:3 rwm # /dev/null lxc.cgroup.devices.allow = c 1:5 rwm # /dev/zero lxc.cgroup.devices.allow = c 5:1 rwm # /dev/console lxc.cgroup.devices.allow = c 5:0 rwm # /dev/tty lxc.cgroup.devices.allow = c 5:1 rwm # /dev/console lxc.cgroup.devices.allow = c 4:0 rwm # /dev/tty0 lxc.cgroup.devices.allow = c 4:1 rwm # /dev/tty1 lxc.cgroup.devices.allow = c 4:2 rwm # /dev/tty2 lxc.cgroup.devices.allow = c 4:3 rwm # /dev/tty3 lxc.cgroup.devices.allow = c 1:9 rwm # /dev/urandon lxc.cgroup.devices.allow = c 1:8 rwm # /dev/random lxc.cgroup.devices.allow = c 136:* rwm # /dev/pts/* lxc.cgroup.devices.allow = c 5:2 rwm # /dev/pts/ptmx lxc.cgroup.devices.allow = c 254:0 rwm # /dev/rtc0 === When thinclient boot, the error occur: I get this error on thinclient boot: PXE-E32: TFTP open timeout This accur when firewall block inetd, but i do not set firewall. Can you give the network configuration of the host too ? brctl show br0 and ifconfig Thanks -- Daniel -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Actually, I'm not sure you can fully solve this. If rootfs is a separate file system, this is only much ado about nothing. If rootfs isn't a separate filesystem, you can't automatically find a good place and also clean it up. Maybe a single /tmp/lxc directory may be used as the mount points are private to the container. So it would be acceptable to have a single directory for N containers, no ? Then why not /usr/lib/lxc/pivotdir or something like that? Such a directory could belong to the lxc package and not clutter up /tmp. As you pointed out, this directory would always be empty in the outer name space, so a single one would suffice. Thus there would be no need cleaning it up, either. Agree. Shall we consider $(prefix)/var/run/lxc ? Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot if /var/run is on tmpfs. This isn't variable data either, that's why I recommended /usr above. Now the question is: if rootfs is a separate file system (which includes bind mounts), is the superfluous rbind of the original root worth skipping, or should we just do it to avoid needing an extra code path? Good question. IMO, skipping the rbind is ok for this case but it may be interesting from a coding point of view to have a single place identified for the rootfs (especially for mounting an image). I will cook a patchset to fix the rootfs location and then we can look at removing the superfluous rbind. I'm testing your patchset now. So far it seems to work as advertised. -- Thanks, Feri. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
Re: [Lxc-users] Ltsp on LXC: PXE-E32: TFTP open Timeout
Osvaldo Filho wrote: Sorry: /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 10.0.3.10 netmask 255.255.255.0 gateway 10.0.3.1 dns-nameservers 10.0.3.1 192.168.1.1 auto br0 iface br0 inet static address 192.168.6.1 netmask 255.255.255.0 broadcast 192.168.6.255 network 192.168.6.0 #gateway 192.168.6.1 dns-nameservers 192.168.6.1 bridge_ports eth2 bridge_stp off Is there a forwarding between br0 and eth0 ? At the first glance the configuration looks ok. I don't know ltsp, so maybe I won't able to help too much. The first thing to do is to check the traffic between the container and br0 is ok. You can check that by using tcpdump -i br0 and watch for outgoing packets when the thinclient does tftp. Assuming there is a forwarding between br0 and eth0: If the packets are visible on br0, maybe the iptables are blocking something. check: * /proc/sys/net/ipv4/ip_forward is set to 1 and you have the right iptables rules to do the masquerading for br0. Another point is if tftp does broadcast, I am not sure the packets will be forwarded. 2010/5/12 Osvaldo Filho arquivos...@gmail.com: No problem and thank you very much! = br0 Link encap:Ethernet Endereço de HW 00:10:18:4f:8e:fc inet end.: 192.168.6.1 Bcast:192.168.6.255 Masc:255.255.255.0 endereço inet6: fe80::210:18ff:fe4f:8efc/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:17528009 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:10890138 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:6134616116 (6.1 GB) TX bytes:24160294112 (24.1 GB) eth2 Link encap:Ethernet Endereço de HW 00:10:18:4f:8e:fc endereço inet6: fe80::210:18ff:fe4f:8efc/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:17545797 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:25377694 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:1000 RX bytes:6554180607 (6.5 GB) TX bytes:25219335827 (25.2 GB) IRQ:38 Memória:d600-d6012800 virbr0Link encap:Ethernet Endereço de HW 0e:0c:3a:d3:3e:6e inet end.: 192.168.122.1 Bcast:192.168.122.255 Masc:255.255.255.0 endereço inet6: fe80::c0c:3aff:fed3:3e6e/64 Escopo:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1 pacotes RX:0 erros:0 descartados:0 excesso:0 quadro:0 Pacotes TX:1689 erros:0 descartados:0 excesso:0 portadora:0 colisões:0 txqueuelen:0 RX bytes:0 (0.0 B) TX bytes:330948 (330.9 KB) --- iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT udp -- anywhere anywhereudp dpt:domain ACCEPT tcp -- anywhere anywheretcp dpt:domain ACCEPT udp -- anywhere anywhereudp dpt:bootps ACCEPT tcp -- anywhere anywheretcp dpt:bootps Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere 192.168.122.0/24state RELATED,ESTABLISHED ACCEPT all -- 192.168.122.0/24 anywhere ACCEPT all -- anywhere anywhere REJECT all -- anywhere anywhere reject-with icmp-port-unreachable REJECT all -- anywhere anywhere reject-with icmp-port-unreachable Chain OUTPUT (policy ACCEPT) target prot opt source destination = The problem, perhaps, is with openbsd-inetd. 2010/5/12 Daniel Lezcano daniel.lezc...@free.fr: Osvaldo Filho wrote: bridge name bridge id STP enabled interfaces br0 8000.0010184f8efc no eth2 virbr0 8000. yes *and* ifconfig :) Thanks -- Daniel LXC container use br0 2010/5/12 Daniel Lezcano daniel.lezc...@free.fr: Osvaldo Filho wrote: Host Environment: Linux ltspserver01 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010 x86_64 GNU/Linux lxc 0.6.5-1 Linux containers userspace tools === lxc.utsname = ltsp2 lxc.tty = 4 lxc.pts = 1024 lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.mtu = 1500 lxc.rootfs = ./rootfs lxc.mount = ./fstab.lxc #lxc.cgroup.cpuset.cpus = 0 lxc.network.ipv4 = 192.168.6.2/24 lxc.network.hwaddr = 0a:22:3c:4d:55:ff #lxc.cgroup.devices.deny = a # Deny all access to devices lxc.cgroup.devices.allow = c 1:3 rwm # /dev/null lxc.cgroup.devices.allow = c 1:5 rwm # /dev/zero lxc.cgroup.devices.allow = c 5:1 rwm #
Re: [Lxc-users] lxc-start leaves temporary pivot dir behind
Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Daniel Lezcano daniel.lezc...@free.fr writes: Ferenc Wagner wrote: Actually, I'm not sure you can fully solve this. If rootfs is a separate file system, this is only much ado about nothing. If rootfs isn't a separate filesystem, you can't automatically find a good place and also clean it up. Maybe a single /tmp/lxc directory may be used as the mount points are private to the container. So it would be acceptable to have a single directory for N containers, no ? Then why not /usr/lib/lxc/pivotdir or something like that? Such a directory could belong to the lxc package and not clutter up /tmp. As you pointed out, this directory would always be empty in the outer name space, so a single one would suffice. Thus there would be no need cleaning it up, either. Agree. Shall we consider $(prefix)/var/run/lxc ? Hmm, /var/run/lxc is inconvenient, because it disappears on each reboot if /var/run is on tmpfs. This isn't variable data either, that's why I recommended /usr above. Good point. I will change that to /usr/$(libdir)/lxc and let the distro maintainer to choose a better place if he wants with the configure option. Now the question is: if rootfs is a separate file system (which includes bind mounts), is the superfluous rbind of the original root worth skipping, or should we just do it to avoid needing an extra code path? Good question. IMO, skipping the rbind is ok for this case but it may be interesting from a coding point of view to have a single place identified for the rootfs (especially for mounting an image). I will cook a patchset to fix the rootfs location and then we can look at removing the superfluous rbind. I'm testing your patchset now. So far it seems to work as advertised. Cool, thanks for testing. -- ___ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
