SliTaz Forum

mqudsi

Member

Registered: 2012-03-29

Posts: 12

Out-of-the-Box Regressions on VMware w/ SliTaz 4

Hello,

Like many other developers considering various linux distros, the first stop is to run them in a virtual machine and poke them with a stick.

SliTaz 3 worked like a dream, and we're highly considering it as the base for our live CD. However, we ran into many issues with the build system (way too old versions of basically any/all build-related tools that make it impossible to compile C++0x code), and then we heard that one of the biggest improvements in SliTaz is the improved build system and decided to take a look.

I know that ST4 isn't ready yet and I apologize if these issues have already been raised, but I just wanted to bring to attention the regressions in the user experience out-of-the-box.

With SliTaz 3, VMware could boot to a minimal working state without any difficulties. X would start, networking was working. With cooking, I've had a very difficult time starting X (and I see the Xtiny Xvesa option has been removed), with constant errors about MTTR, even after doing hardware detection. With RC3, I was able to start x, but it was somewhat broken (the window manager didn't load properly). I found the slitaz-rolling and that fixed my X problems - congratulations. I hope this becomes the default configuration, as it's really a failure for any distro to fail to load to a desktop environment in 2012 - this has been a solved problem since the early 2000's (right around the time time everyone switched to Xorg).

I haven't done any real testing yet, not with the VMware hardware compatibility nor with the gcc toolkit, but for now the first thing that I noticed was broken in the default boot is the network access. If it's possible to please include the vmware networking drivers out-of-the-box, that would be very much appreciated by myself and any other developers considering ST.

Thank you.

mqudsi

Member

Registered: 2012-03-29

Posts: 12

Re: Out-of-the-Box Regressions on VMware w/ SliTaz 4

Actually, this is interesting. Since SliTaz is unusable without either an internet connection or VMware tools, and VMware tools isn't possible without some not pre-installed packages, I tried to debug the network situation.

It turns out that the virtual network adapter is recognized by ST just fine - but that DHCP was failing to get an address. What's interesting is that when I switched the configuration of the VM from directly bridging the virtual adapter to the physical network and instead configured it to use a private NAT, everything worked fine.

It turns out that ST 4 rolling was unable to negotiate a DHCP connection with my router (it's a Linux-based router running tomato which is a ddWRT fork), but was able to get a DHCP address from VMware just fine in the latter configuration. The odd thing is that ST v3 can negotiate a DHCP lease from the tomato router just fine in the exact same configuration.

I'm nowhere near proficient enough in networking to make sense of a wireshark dump, but I suppose I can provide that for anyone willing to look into this? Or anyone have any ideas about changes between v3 and v4 that would cause the networking stack to be unable to negotiate a DHCP connection? The output of the networking script is unhelpful, as it just shows multiple attempts then a fallback to 192.168.0.xxx (which is interesting instead of defaulting to the 169.xxxx autoconf address).