# Compat8x and COMPAT_FREEBSD8



## SirDice (Jan 11, 2012)

So, I just updated my sources (*RELENG_9*), build world, started building my kernel...

Kernel config doesn't recognize *COMPAT_FREEBSD8*.

misc/compat8x mentions it. PR for it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=163630&cat=

It was closed because the option should have been added but still isn't?

It should also have been added to *GENERIC* but isn't.

Assuming the ABI did change and keeping up with previous versions what happened to *COMPAT_FREEBSD8*?


----------



## vand777 (Jan 11, 2012)

Will share my upgrading experience...

I was upgrading from sources few days ago. I didn't have this option in my kernel config file (because it was missing in GENERIC). 

After I installed kernel/world and rebooted servers, all services started without any problems. I installed misc/compat8x and rebooted servers. All started without any problems again. Then I rebuilt all the ports (with no rush) and deinstalled misc/compat8x.

Didn't have any problems during the update at all.


----------



## vand777 (Jan 11, 2012)

There is one important thing to take into account. It may effect a lot of users unless they read /usr/src/UPDATING:


```
20110424:
        The GENERIC kernels for all architectures now default to the new
        CAM-based ATA stack. It means that all legacy ATA drivers were
        removed and replaced by respective CAM drivers. If you are using
        ATA device names in /etc/fstab or other places, make sure to update
        them respectively (adX -> adaY, acdX -> cdY, afdX -> daY, astX -> saY,
        where 'Y's are the sequential numbers starting from zero for each type
        in order of detection, unless configured otherwise with tunables,
        see cam(4)). There will be symbolic links created in /dev/ to map
        old adX devices to the respective adaY. They should provide basic
        compatibility for file systems mounting in most cases, but they do
        not support old user-level APIs and do not have respective providers
        in GEOM. Consider using updated management tools with new device names.

        It is possible to load devices ahci, ata, siis and mvs as modules,
        but option ATA_CAM should remain in kernel configuration to make ata
        module work as CAM driver supporting legacy ATA controllers. Device ata
        still can be used in modular fashion (atacore + ...). Modules atadisk
        and atapi* are not used and won't affect operation in ATA_CAM mode.
        Note that to use CAM-based ATA kernel should include CAM devices
        scbus, pass, da (or explicitly ada), cd and optionally others. All of
        them are parts of the cam module.

        ataraid(4) functionality is now supported by the RAID GEOM class.
        To use it you can load geom_raid kernel module and use graid(8) tool
        for management. Instead of /dev/arX device names, use /dev/raid/rX.

        No kernel config options or code have been removed, so if a problem
        arises, please report it and optionally revert to the old ATA stack.
        In order to do it you can remove from the kernel config:
            options        ATA_CAM
            device         ahci
            device         mvs
            device         siis
        , and instead add back:
            device         atadisk         # ATA disk drives
            device         ataraid         # ATA RAID drives
            device         atapicd         # ATAPI CDROM drives
            device         atapifd         # ATAPI floppy drives
            device         atapist         # ATAPI tape drives
```


----------



## gkontos (Jan 12, 2012)

@SirDice ,

I am under the impression that the ABI has not been changed. I recall that it was discussed in the current mailing list and that there would be a BUMP version  sometime during BETAS.
Anyway, when I brought my first server to 9.0-BETA1 from 8.2-STABLE, all services were running fine. I decided to rebuild all of my ports because it was a good opportunity to upgrade Perl & Python.
Other than that,  I never read anything regarding the ABI change and COMPAT_FREEBSD8 never appeared in GENERIC

Regards,


----------



## SirDice (Jan 12, 2012)

gkontos said:
			
		

> Other than that,  I never read anything regarding the ABI change and COMPAT_FREEBSD8 never appeared in GENERIC


Every major version had changes. I find it rather odd this one doesn't. It's also odd because *COMPAT_FREEBSD8* is mentioned in the PR.



> This option will be added to kernel before 9.0-RELEASE. I already asked
> about it to developers when i created the port.


----------



## SirDice (Jan 12, 2012)

Ok, I took the plunge. Build a kernel without *COMPAT_FREEBSD8*, didn't even install misc/compat8x. Everything appears to be working. Odd, not what I expected after a major version update.

sysutils/smartmontools does complain about not being able to find any disks. But I'll deal with that later, after I've rebuilt all the ports on this machine.


----------



## gkontos (Jan 12, 2012)

I can't hide the fact that I am the same confused as you are. So, I asked on stable & current mailing lists:

http://lists.freebsd.org/pipermail/freebsd-stable/2012-January/065385.html

Let's see if I get any responses. In the mean time have fun recompiling all the ports :beergrin


----------



## SirDice (Jan 13, 2012)

Thanks, lets see what comes up 

I did find out you really need misc/compat8x, mainly because of the bump on the libraries.


----------



## gkontos (Jan 13, 2012)

SirDice said:
			
		

> Thanks, lets see what comes up
> 
> I did find out you really need misc/compat8x, mainly because of the bump on the libraries.



So, did you manually modify KERNEL to include COMPAT_FREEBSD8?


----------



## SirDice (Jan 13, 2012)

gkontos said:
			
		

> So, did you manually modify KERNEL to include COMPAT_FREEBSD8?



Yes, I normally run a custom kernel. So after a csup(1) to RELENG_9 I added it to my kernel config, expecting to need it, and tried to build the kernel. This failed as that option doesn't exist. Building the kernel without it went flawless.


----------



## gkontos (Jan 13, 2012)

I got a reply that makes some sense:



> Did he do make delete-old-libs, if you leave them, then no recompile is needed, and the ports still have there old libs laying around.!
> If you do the make delete-old-libs command, your ports do not work anymore



Still no clear answer regarding COMPAT_FREEBSD8


----------



## SirDice (Jan 13, 2012)

I only did a `# make delete-old`

It worked at first but after a while it started complaining about missing libraries. I then installed compat8x. Only did a delete-old-libs afterwards. It appeared it didn't delete anything at that point.

So, quick recap.


 installkernel, installworld, mergemaster(8), delete-old, reboot
 everything appeared to be working
 after a few hours the problems started, various ports started complaining about missing libraries
 installed compat8x, reboot
 everything worked again
 delete-old-libs, which appeared not to remove anything.

It's been running fine since. Almost done rebuilding all my ports for 9-STABLE.


----------



## gkontos (Jan 13, 2012)

Finally, wrapping up things, there is no direct relation between COMPAT_FREEBSD8 and misc/compat8x.

Therefore, when upgrading to FreeBSD 9.0-RELEASE or STABLE, all ports should be rebuild again. In the meantime using misc/compat8x will make sure that all your software is running as it should.


----------



## SirDice (Jan 13, 2012)

Yep, looks that way. And contrary to previous major version upgrades (and compat8x's pkg-message) COMPAT_FREEBSD8 isn't needed.


----------



## vand777 (Jan 13, 2012)

SirDice said:
			
		

> And contrary to previous major version upgrades (and compat8x's pkg-message) COMPAT_FREEBSD8 isn't needed.



Let's hope so. Could we get the official answer from FreeBSD team?


----------



## phoenix (Jan 13, 2012)

Read through the thread on the freebsd-stable mailing list.


----------

