There is nothing that prevents one from making a 32-bit build technically. All it takes is to recompile the platform-dependent packages and rebuild the image.
The demand for it is very low and shrinking though, now that affordable 64-bit boxes are common. The question therefore is whether we can make 32-bit builds easy enough to create a low maintenance build setup.
So far live-build couldn’t make images for architectures other than the on its running on. If someone finds a way to do that, it may tip the balance. Else we’d need to maintain a 32-bit host just to make those images.
I would have thought that compiling for 586 should be easier than for ARM, as you don’t need a separate toolchain and 586 code runs on amd64 but I guess it is still work and more complex when there is a lot of different modules / dependencies.
You do need a separate toolchain for 32-bit x86 code. Building ARM binaries on an ARM host is just as easy as building amd64 binaries on amd64. Building i586 binaries on an amd64 host is just a little easier than building them on an ARM host, it still needs a separate toolchain and libraries, even though testing those binaries is much easier because you can run them. You could simplify it by running builds in a containers in the i586/amd64 case, but the procedures still need to be developed.
You also need a separate build host for images because live-build’s architecture option appears to have no effect, at least when you specify i586 for live-build running on an amd64 host.
We don’t get many requests for i586, and none of the maintainers or active contributors use it (likewise, no one offered to pay for it), so other issues naturally get higher priorities. None of us is categorically opposed to i586 images though, so if someone helps make it happen, it may happen.
I think it might be time for me to give up trying to create a build for 586, after spending far too much of my time on it over the past 7 days.
Building all the dependencies (some not even listed in the project) took a very long time after resolving multiple problems
I eventually got to the point where I had an ISO: vyos-1.2.0-rolling+201901242343-i386.iso, however when I booted it, I was unable to login to it. Upon inspection of the chroot, it looks like no vies:vyos user was created. With no user with any password, I was unable to login.
During the boot sequence a service failed to start because libyang was missing.
These leads me to question if I was even building from the correct branch/version of vyos-build.
I really wanted to get VyOS up and running but I sadly I think I have spent too much time on it and it is time went back to using raw Debian Linux + ansible.
A lot of my initial problems were because I was building from master and not current (or crux) - most of the issues you covered above were resolved by switching to the current branch.
I am not sure if I have a complete build or not now, but the problem I have is with there being no vyos user on the live build. Do you know which script/component is supposed to create that user and set the password to ‘vyos’?
wireguard and accel-ppp needs the kernel sources. Wireguard could run purely in userspace, but it sucks performance of the cpu. We usually have that in the RERADME.md (GitHub - vyos/vyos-accel-ppp: accel-ppp debianized for the use with vyos, GitHub - vyos-legacy/vyos-wireguard). I surely have to make mine more structured and readable like the one from wireguard :), but it’s all compiling. I never have tested it against a x86 only, but did a cross-compile for armhf with no issues. For your user, I think it’s less a question of the ‘process’, at the end of the boot sequence you have a vyos-router and config, if anything exits 1, you would see that as error.
What you can do if you can boot is, booting in single user and init=/bin/bash, that way you are root on the system (there are ways to prevent that switch which might be activated in later releases) and can investigate. Wiorst case start vyos-config and trigger the user creation manually, or set everything debug and reboot etc.
Just a few ideas.
Hope that helps.
I resolved the problem with libyang thanks to this commit by c-po:
I put the resulting Debian package into the packages directory and it successfully included it in the build (previous attempts to install the libyang package in live-build failed for various annoying/unknown reasons)
Following @hagbard’s advice I managed to login to the VyOS Live CD by:
Pressing tab in the isolinux boot screen to edit the Linux kernel parameters
Appending single to the end of the parameters
When the boot paused I used passwd to set a root password and then pressed control-d to continue the boot
I could then login as root. However show configuration showed that there was no configuration loaded at all - hence no vyos user.
So it looks like /opt/vyatta/etc/config.boot.default isn’t being copied into the running configuration, not can I find the code that is supposed to do this.
There is no /config/config.boot at all - this a problem at first boot. It looks like it is a problem with loading the template files, rather than a problem with the configuration - although I don’t really understand what/how VyOS loads those files.
What shows sudo dpkg -l vyatta-wirelessmodem?
Should show something like: ii vyatta-wirelessmodem 0.1.24+vyos2+current1.
I highly doubt that a package is being replaced, the only replacements I know of are in vyos-replace, but I could be wrong and there are other mechanisms in place too.
So, I suppose the segfault comes from reading the non existent ‘config.boot’, it it repeatable? Like when you reboot, it shows the same error every time? You can restart the services and trace them to see where it hangs before the segfault. From here you should be able to see what happens before the segfault.
I’m going to test amd64 too for the absence of config.boot and see what happens.
on the rolling from yesterday:
ii vyatta-cfg-system 0.20.44+vyos2+current19
ii vyatta-cfg-firewall 0.14.0+vyos2+current2
ii vyatta-openvpn 0.2.60+vyos3+current2
ii vyatta-wirelessmodem 0.1.24+vyos2+current1
The opens a whole bunch of questions :D. Usually they shouldn’t exist on the rolling images as well. I tested the removal of the config.boot file, no issues it’s recreated by a script. I haven’t check which one yet.