# Installing pkg



## tej (Jan 21, 2014)

It does not look like the base system (10.0 on 20-Jan-2014) did not come with pkg.
Tried to install it via ports - no luck as it fails.
When pkg is entered, the system tried to fetch pkg but the install failed.
How can any package or pkg for that matter be installed.

VM Used: Virtual Box (4.3.6)
Arch: i386

Attached are screen shots of the errors.

Any help would be greatly appreciated.


----------



## Beastie (Jan 21, 2014)

I believe they said it will never be included in the base installation.

You can try this method to install it offline manually. Make sure you use the right URL for the package.


----------



## tej (Jan 22, 2014)

Thanks Beastie! Still getting the lzma corrupt error. May be a different version of tar util is needed. Any other thoughts?


----------



## ljboiler (Jan 22, 2014)

I get a different file size and date for pkg-1.2.5.txz downloaded from http://pkg1.nyi.freebsd.org/freebsd:10:x86:64/latest/All/pkg-1.2.5.txz:

```
jimmy@jmobile:/tmp % ls -l pkg-1.2.5.txz 
-rw-r--r--  1 jimmy  wheel  2072856 Jan 15 10:37 pkg-1.2.5.txz
```
From http://pkg1.nyi.freebsd.org/freebsd:10:x86:32/latest/All/pkg-1.2.5.txz, I see the 2057700 file size.
No problems extracting either with `tar`

Here's the sha256 hash I get for the i386 version:

```
[jimmy@jmobile:/tmp % sha256 pkg-1.2.5.txz 
SHA256 (pkg-1.2.5.txz) = 2631e52016c93cc4bed270c8e0c880db8f37d3a8fd2f076877d71b3b37e373d5
```


----------



## nanotek (Jan 22, 2014)

Beastie said:
			
		

> I believe they said it will never be included in the base installation.



What is the reason for this?


----------



## kpa (Jan 22, 2014)

nanotek said:
			
		

> Beastie said:
> 
> 
> 
> ...



Once something is in the base system it's a major burden to maintain because of shared libraries compatibility concerns. It's better to keep pkg out of base so that it can be updated at will without having to think if the changes break the shared library compatibility in the base system.


----------



## nanotek (Jan 22, 2014)

That sounds reasonable. Thanks, @kpa.


----------



## tej (Jan 22, 2014)

ljboiler, the file you listed was for 64-bit arch. hence the size difference. Also, there is no issue with the file as the secure hash digest you presented matches with that of the 32-bit pkg file I have.


----------



## ljboiler (Jan 22, 2014)

This is interesting...   I have no problem when using the `tar` command on either one(64 bit or 32-bit).
Have you tried uncompressing the file and extracting the contents of the archive in 2 steps:

```
xz -d pkg-1.2.5.txz
tar xvf pkg-1.2.5.tar -s ",/.*/,,g" "*/pkg-static"
```


----------



## tej (Jan 22, 2014)

Thanks! I did this earlier with no luck. Here is what I got.


----------



## ljboiler (Jan 22, 2014)

How big is pkg.tar after decompressing it with `xz`?

```
jimmy@jmobile:/tmp % ls -l pkg*
-rw-r--r--  1 jimmy  wheel  7412224 Jan 15 09:08 pkg-1.2.5.tar
-rw-r--r--  1 jimmy  wheel  2057700 Jan 15 09:08 pkg-1.2.5.txz
```


----------



## tej (Jan 22, 2014)

The size matches.


----------



## ljboiler (Jan 22, 2014)

There wouldn't be an alias defined for `tar`, would there?  What does this show?
	
	



```
alias
```


----------



## tej (Jan 22, 2014)

No aliases. tar is symlink to bsdtar as below and its version 3.1.2


----------



## Beastie (Jan 22, 2014)

Now that I notice you are trying the _i386_ version under _Virtual Box_... maybe your problem is related to the first issue mentioned in the errata.
Does the proposed solution work for you?


----------



## tej (Jan 23, 2014)

Excellent find. Thanks Beastie!! Disabling the unmapped IO worked! Also, noticed that during startup, there were less error messages, dhclient started, etc.
Resolved!! Thanks again.

Resolution: Go to loader prompt on boot

```
set vfs.unmapped_buf_allowed=0
boot
```

For persistent changes, add vfs.unmapped_buf_allowed=0 to /boot/loader.conf.


----------

