Installing pkg

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.
 

Attachments

  • pkg_ports_freebsd10_2014-01-21_141124.jpg
    pkg_ports_freebsd10_2014-01-21_141124.jpg
    87.8 KB · Views: 702
  • pkg_install2_freebsd10_2014-01-21_141204.jpg
    pkg_install2_freebsd10_2014-01-21_141204.jpg
    57.8 KB · Views: 704
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.
 
Thanks Beastie! Still getting the lzma corrupt error. May be a different version of tar util is needed. Any other thoughts?
 

Attachments

  • pkg_static_lzma_error_2014-01-21_222045.jpg
    pkg_static_lzma_error_2014-01-21_222045.jpg
    56.3 KB · Views: 653
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:
Code:
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:
Code:
[jimmy@jmobile:/tmp % sha256 pkg-1.2.5.txz 
SHA256 (pkg-1.2.5.txz) = 2631e52016c93cc4bed270c8e0c880db8f37d3a8fd2f076877d71b3b37e373d5
 
nanotek said:
Beastie said:
I believe they said it will never be included in the base installation.

What is the reason for this?

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.
 
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.
 

Attachments

  • pkg_x86_32_2014-01-22_031700.jpg
    pkg_x86_32_2014-01-22_031700.jpg
    31.8 KB · Views: 617
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:
Code:
xz -d pkg-1.2.5.txz
tar xvf pkg-1.2.5.tar -s ",/.*/,,g" "*/pkg-static"
 
Thanks! I did this earlier with no luck. Here is what I got.
 

Attachments

  • pkg_xz_2014-01-22_111216.jpg
    pkg_xz_2014-01-22_111216.jpg
    69.5 KB · Views: 571
How big is pkg.tar after decompressing it with xz?
Code:
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
 
No aliases. tar is symlink to bsdtar as below and its version 3.1.2
 

Attachments

  • tar_014-01-22_142916.jpg
    tar_014-01-22_142916.jpg
    38.5 KB · Views: 535
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?
 
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
Code:
set vfs.unmapped_buf_allowed=0
boot

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