The last post about the Lin­ux­u­la­tor where I explained the Lin­ux­u­la­tor from an user point of view got some good amount of atten­tion. Trig­gered by a recent expla­na­tion of the Lin­ux­u­la­tor errno stuff to a fel­low FreeBSD devel­oper I decided so see if more devel­op­ers are inter­ested in some more info too…

The syscall vector

In sys/linux/linux_sysvec.c is all the basic setup to han­dle Linux “sys­tem stuff” in FreeBSD. The “sys­tem stuff” is about trans­lat­ing FreeBSD errnos to Linux errnos, about trans­lat­ing FreeBSD sig­nals to Linux sig­nales, about han­dling Linux traps, and about set­ting up the FreeBSD sys­tem vec­tor (the ker­nel struc­ture which con­tains all the data to iden­tify when a Linux pro­gram is called and to be able to lookup the right ker­nel func­tions for e.g. syscalls and ioctls).

There is not only one syscall vec­tor, there is one for a.out (struct sysentvec linux_sysvec) and one for ELF (struct sysentvec elf_linux_sysvec) bina­ries (at least on i386, for other archi­tec­tures it may not make sense to have the a.out stuff, as they maybe never seen any a.out Linux binary).

The ELF AUX args

When an ELF image is exe­cuted, the Lin­ux­u­la­tor adds some run­time infor­ma­tion (like page­size, uid, guid, …) so that the user­land can query this infor­ma­tion which is not sta­tic at build-time eas­ily. This is han­dled in the elf_linux_fixup func­tion(). If you see some error mes­sages about miss­ing ELF notes from e.g. glibc, this is the place to add this infor­ma­tion to. It would not be bad from time to time to have a look what Linux is pro­vid­ing and miss­ing pieces there. FreeBSD does not has an auto­mated way of doing this, and I am not aware of some­one who reg­u­larly checks this. There is a lit­tle bit more info about ELF notes avail­able in a mes­sage to one of the FreeBSD mail­ing lists, it also has an exam­ple how to read out this data.

Traps

Linux and FreeBSD do not share the same point of view how a trap shall be han­dled (SIGBUS or SIGSEGV), the cor­re­spond­ing deci­sion mak­ing is han­dled in translate_traps() and a trans­la­tion table is avail­able as _bsd_to_linux_trapcode.

Sig­nals

The val­ues for the sig­nal names are not the same in FreeBSD and Linux. The trans­la­tion tables are called linux_to_bsd_signal and bsd_to_linux_signal. The trans­la­tion is a fea­ture of the syscall vec­tor (= automatic).

Errnos

The val­ues for the errno names are not the same in FreeBSD and Linux. The trans­la­tion table is called bsd_to_linux_errno. Return­ing an errno in one of the Linux syscalls will trig­ger an auto­matic trans­la­tion from the FreeBSD errno value to the Linux errno value. This means that FreeBSD errnos have to be returned (e.g. FreeBSD ENOSYS=78) and the Linux pro­gram will receive the Linux value (e.g. Linux ENOSYS=38, and as the Linux ker­nel returns neg­a­tive errnos, the linux pro­gram will get –38).

If you see some­where an “-ESOMETHING” in the Lin­ux­u­la­tor code, this is either a bug, or some clever/tricky/dangerous use of the sign-bit to encode some info (e.g. in the futex code there is a func­tion which returns –ENOSYS, but the sign-bit is used as an error indi­ca­tor and the call­ing code is respon­si­ble to trans­late neg­a­tive errnos into pos­i­tive ones).

Syscalls

The Linux syscalls are defined sim­i­lar to the FreeBSD ones. There is a map­ping table (sys/linux/syscalls.master) between syscall num­bers and the cor­re­spond­ing func­tions. This table is used to gen­er­ate code (“make sysent” in sys//linux/) which does what is necessary.

There are some HOW­TOs out there in the net which describe some auto­matic net­work based install via PXE-booting a machine from a server which has a spe­cific FreeBSD release in the PXE-booting area and a non-interactive con­fig for sysin­stall to install this FreeBSD ver­sion on the machine which PXE-boots this.

The setup of this is com­pletely man­ual and only allows to net­boot one FreeBSD ver­sion. The server-side setup for the clients is also com­pletely man­ual (and only allows to install one client at a time, it seems). This is not very user-friendly, and far away from the power of Jumpstart/JET for Solaris where you cre­ate a tem­plate (maybe from another tem­plate with auto­matic value (IP, name, MAC) replace­ment) and can spec­ify dif­fer­ent OS releases for dif­fer­ent clients and then just run a com­mand to gen­er­ate a good con­fig for this.

I thought a lit­tle bit how it could be done and decided to write down all the stuff (so far 160 lines, 830 words) to not for­get some details. All in all I think this could be done (at least a sen­si­ble sub­set) in a week or two (full­time) if you have the hard­ware, moti­va­tion, and time. As always, the prob­lems are within the details, so I may be off with my esti­ma­tion a lit­tle bit (also depends upon the knowledge-level (shell, tftp, dhcpd, install–soft­ware) of the per­son doing this).

Unfor­tu­nately I do not know if I have the hard­ware at home to do some­thing like this. I have some unused hard­disks which could be used in a machine which is used tem­po­rary as a test-install-client (nor­mally I use this machines as my Desk­top… if I do not use my lit­tle Net­book instead, as I do not do much at home cur­rently), but I’ve never checked if this machine is PXE-booting-capable (VIA KT133 chipset with a 3Com 3c905C–TX Fast Ether­link XL). I also do not have the time to do this (with the cur­rent rate of free time I would expect to need about a year), except maybe some­one would call my boss and nego­ti­ate something.

I can not remem­ber any request to have some­thing like this on the freebsd-current, freebsd-arch or freebsd-hackers list since I read them (and that is since about at least 3.0-RELEASE). Is this because nearly nobody is inter­ested in some­thing like this, or are the cur­rent pos­si­bil­i­ties enough for your needs? Do you work at a place where this would be wel­come (= directly used when it would be done)? If you use a sim­ple solu­tion to make a net-install, what is your expe­ri­ence with this (pros/cons)?

I updated some work­sta­tions of the client to Solaris 10 update 9. Upon installing my xorg.conf (dual-screen setup) I had to notice that it does not work any­more. The prob­lem is, that the NVidia dri­ver does not con­tain sup­port for the graphic card we use.

Nor­mally this is not a big deal, this can hap­pen… but in this case this is about SUN Ultra 20 work­sta­tions with SUN pro­vided NVidia Quat­tro FX (NV37GL) cards. Ok, they are not the most recent ones, they where bought 4 – 5 years ago, but still, they just work as needed here and the cur­rent Solaris release has no out-of-the-box sup­port for them. I would expect this to work already in a fresh install (yes, I was not able to get the nv dri­ver to work with two screens on this graphic card, it seems the nv dri­ver has not sup­port for this).

Solu­tion for me: down­load the old dri­ver from NVidia and inte­grate it into Jump­start (but still, some hours are lost because of first try­ing to get a work­ing dual-screen setup with the nv dri­ver before tak­ing an old NVidia dri­ver and using it like before in xorg.conf).

Another glitch a co-worker dis­cov­ered is that StarOf­fice is not included any­more. That is again some­thing which will cause some loss of time. I will have to have a look how to han­dle it. Prob­a­bly it is best to install it on the server and mount it via NFS on the work­sta­tions. I will see soon if this is can be done (instal­la­tion of OO into a spe­cific place which can be shared) or not.

I was build­ing Berke­leyDB (4.7, yes I know, there are more recent ver­sions avail­able) on a Solaris machine. First try was to unpack, cd into the direc­tory, run con­fig­ure. It failed, there is no con­fig­ure script. Bah.

Sec­ond try: search­ing for docs… found some… in HTML (the README refers to it and tells noth­ing else). This is a remote machine, I do not want to use a HTML browser remotely (I may not even have one installed there…). Bah.

Ok, dist/configure exists, no spe­cial options needed for my case, it seems.

There is even a Solaris spe­cific HTML file, but from a quick glance at it with ‘less’, it looks like a FAQ.

Usabil­ity from a com­mand line: zero.
Pos­si­bil­ity to com­pile from a GUI (unix): I doubt it.

What is wrong with plain text files? If I down­load the source and want to com­pile it (and for Solaris this is the nor­mal way of work­ing), why the hell do I need some GUI instead of get­ting a plain text file with the required descrip­tion (which is not graph­i­cally enhanced in the HTML ver­sion either)? You can even gen­er­ate a plain text ver­sion of the docs auto­mat­i­cally dur­ing the src-packaging process.

Hey Ora­cle, there is room for improve­ment here!

After mov­ing our sec­ondary man­age­ment site (our team is split up into 2 dif­fer­ent loca­tions) to a new build­ing, we decided to clean-up some things. One of those things involves mov­ing the LDAP to a dif­fer­ent machine (more or less a new server for the new site, it is inde­pen­dent regard­ing LDAP/homes/… from the pri­mary site). While I am at it, I take the oppor­tu­nity to move from DSEE5 to DSEE7 (my pre­vi­ous post about the DSEE6 migra­tion was at the pri­mary site). This time I took the pack­age dis­tri­b­u­tion instead of the zip dis­tri­b­u­tion (the main rea­son is that I can get patch-listings with an auto­matic tool, and the sec­ondary man­age­ment site has no disaster-recovery require­ments for the appli­ca­tions… we just will setup a new sec­ondary site some­where else if necessary).

Here my expe­ri­ences with the instal­la­tion instruc­tions of DSEE7.

• The install instruc­tions refer to the web inter­face for the DSEE7 man­age­ment, but I have not seen some­thing which tells you first have to setup an appli­ca­tion server (this was bet­ter in the DSEE6 instructions).
• When using the Glass­fish appli­ca­tion server which comes with Solaris 10 for the web inter­face, you will get an excep­tion after deploy­ing the dscc7.war, as it is using an out­dated JVM. After some fight­ing and Googling, I found that I have to change the AS_JAVA value in /usr/appserver/config/asenv.conf to a more recent JVM as it is point­ing to the very out­dated j2se 1.4.x. I pointed it to /usr/java (which is a sym­link to the most recent ver­sion installed as a pack­age). Instead of the orig­i­nal excep­tion I got another one now (after a redi­rec­tion in the web-browser), some­thing that it can not find the AntMain class (Glass­fish uses ANT from /usr/sfw, this is the one which comes with Solaris 10 update 9). I tried with Java 5 instead of Java 6, but I get the same error. In the net there are some dis­cus­sions about such errors (it is even a FAQ at the ANT site), but this Glassfish/DSEE7 thing is a black box for me, so what am I sup­posed to do here (I do not want to put the sys­tem into an unof­fi­cial state by installing my own ANT for Glassfish/DSEE7)?
  It was not men­tioned in the Appen­dix of the DSEE7 install instruc­tions which explains how to install the .war in Glass­fish that you have to change to a more recent JVM, and I still fight with the AntMain prob­lem (hey Ora­cle, there is room for improve­ment in the prod­uct com­pat­i­bil­ity test­ing and doc­u­men­ta­tion ver­i­fi­ca­tion process).

I will update this post­ing when I make some advance­ments. For now I let the web inter­face in the bad state as it is and con­cen­trate on fin­ish­ing the LDAP move to the new sys­tem (installing an DSEE on a backup sys­tem, con­fig­ur­ing repli­ca­tion, switch­ing the clients to them). The web inter­face is inde­pen­dent enough to han­dle it later (hints wel­come, that is the main pur­pose why I write this pos­ing in the mid­dle of the work).