On Sat, Oct 25, 2014 at 06:04:16PM -0400, Steve Petrie, P.Eng. via smartos-discuss wrote:
> Here is a summary of the steps used on an EH VM Debian Linux server, to strip > the "intel_nhm*" drivers from a standard-issue "smartos-latest.iso" CD image, > and repackage the revised SmartOS distro, back into a > "smartos-latest.no_nhm.iso" bootable on an EH VM: Thanks for the detailed writeup. Should others find themselves here, your procedure certainly seems fine. There is however a simpler way to get started, provided you can access the GRUB menu or alter the contents of the USB key to alter the default menu. Simply add "disable-XXX", where XXX is the name of a driver you wish to prevent from loading, to the kernel's command line. This should prevent the problem until someone figures out why a CPU driver is loading on a CPU that doesn't match (it's also possible that this is a bug in the hypervisor that EH uses, in that it may be reporting itself as a particular CPU even if that's not the actual CPU type or if the virtual CPU presented to the guest lacks functions that the CPU it identifies itself as always has). One can also modify /etc/system, either in the image itself or via bootfs modules, to prevent loading a particular driver. If you do choose to rebuild the boot archive, you should also regenerate the contents of boot_archive.hash. This file contains a single newline-terminated line holding the SHA-1 sum of boot_archive. > b.. (2) produce a SmartOS build, elapsed time statistic on an EH VM, to > offer for comparison with illumos build times on various underlying > platforms, published on web page > http://wiki.illumos.org/display/illumos/Build+Times Note that building SmartOS does a lot more than just build illumos, so you'll need to work a bit harder to come up with something comparable. > problem: enabling SSH access to SmartOS running on the EH VM > > Presently, I am using VNC access to work with the SmartOS console on the EH > VM, as the PuTTY SSH client times out when trying to connect to SmartOS on > the EH VM. The PuTTY SSH client works fine,with other EH VMs running Linux. > > SmartOS setup using the "smartos-latest.no_nhm.iso", was done with the EH VM > configured to emulate a RealTek 8139 NIC. > > The SSH service shows as being "online", according to SmartOS console svcs > command output. > > A ping from the SmartOS console, shows as "Alive", the static IP address > 107.6.4.77 assigned to the same EH VM. > > But pings from another EH VM running Linux, and from a remote Windows XP > desktop, both timeout. You'll need to fix this before you can get SSH working. This appears to be a problem with the (virtual) network device and/or perhaps an interoperability issue between the virtual device and our rtls driver. If EH supports an Intel Gigabit Ethernet device instead of Realtek ("e1000"), that may be a better option. > SmartOS also boots when the EH VM is configured to emulate an Intel e1000 > NIC, instead of a RealTek 8139 NIC, but I haven't produced any SmartOS > diagnostics under this configuration. Does it work in this configuration? I would expect e1000g or perhaps igb to attach in this case. Unless the networking problem is caused by something like an MTU mismatch, I don't believe there is any command you can use to find the problem other than perhaps mdb(1). You might start by seeing whether snoop(1) shows receipt of any packets -- that would put you on the path of rx vs. tx in rtls (or the relevant Intel driver). ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
