pkg_add - error while reading header / read short file / gzheader truncated
Hello Misc, I am configuring a couple of laptops for my kids, i had installed 70 with i3 and gcompris in them, its been a while since the last update so i decided to make a fresh install. So I installed 74 in both of them, used the autoinstall so the process was straightforward as always, rebooted, hw_update, syspatch, everything as expected. The problem comes when trying to install a package, i am trying just to of them: feh and gcompris, in both laptops, and i get the following errors, they are several since i do a few tries and then the problem goes and comes at different packages pkg_add: Ustar [package name, it is different every try, meaning lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: Read short file My configuration are: 1 laptop, re0, trying pkg_add feh 1 laptop, iwn0, trying pkg_add gcompris both with the same results, maybe i should try in another LAN, but could it be a problem with the CDN server ? Thank you for your time, -- Manuel Solis >> Hello, I'm new to openBSD about 3 days old. and I ran into the same issue as you. I would pkg_add something and I kept getting the header message. someone on IRC helped me Simple. change the cdn to another mirror look at https://www.openbsd.org/faq/faq15.html#Mirror Basically You find a mirror probably ftp like I did go to vim or nano /etc/installurl delete the cdn add another mirror and re-run the pkg_add you might need to pkg_delete the partial and then re-run. pkg_add After all that you might need pkg_add -u to see if the new mirror fixes all the other partials Hope this helps ~ Joe B
Re: pkg_add - error while reading header / read short file / gzheader truncated
On 2023-12-07, Joe B wrote: > Hello Misc, > > I am configuring a couple of laptops for my kids, i had installed 70 with > i3 and gcompris in them, its been a while since the last update so i > decided to make a fresh install. > > So I installed 74 in both of them, used the autoinstall so the process was > straightforward as always, rebooted, hw_update, syspatch, everything as > expected. > > The problem comes when trying to install a package, i am trying just to of > them: feh and gcompris, in both laptops, and i get the following errors, > they are several since i do a few tries and then the problem goes and comes > at different packages > > pkg_add: Ustar [package name, it is different every try, meaning > lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header > https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz: > Read short file > > My configuration are: > 1 laptop, re0, trying pkg_add feh > 1 laptop, iwn0, trying pkg_add gcompris > > both with the same results, maybe i should try in another LAN, but could it > be a problem with the CDN server ? pkg_add/ftp aren't good at retrying when network connections fail. I'd think it's more likely a problem with your network connection than the cdn server, but you could try one of the other mirrors listed in www.openbsd.org/ftp.html (either set in /etc/installurl or set in the PKG_PATH environment variable; you can just use the hostname in the latter) > Thank you for your time, > > -- Manuel Solis > >>> > > Hello, > > I'm new to openBSD about 3 days old. and I ran into the same issue as > you. I would > > pkg_add something and I kept getting the header message. someone on > IRC helped me > > Simple. change the cdn to another mirror > > look at https://www.openbsd.org/faq/faq15.html#Mirror > > Basically You find a mirror probably ftp like I did go to vim or nano > /etc/installurl > > delete the cdn add another mirror and re-run the pkg_add you might > need to pkg_delete > > the partial and then re-run. pkg_add After all that you might need > pkg_add -u to see if the new mirror > > fixes all the other partials > > > Hope this helps > > > ~ Joe B > -- Please keep replies on the mailing list.
Re: Getting stuck on trying a fresh install to 7.4
On 2023-12-06, Daniel Ouellet wrote: >>> Any suggestion woudl be greattly appreciated. >> >> Old boot loaders cannot boot 7.4 kernels. >> Upgrade your 6.7 system to 7.3 first (the usual advice to avoid >> skipping releases during upgrades applies). Then upgrade to 7.4. Specifically the interface used for communicating system console information between the boot loader and the kernel was changed. There was backwards compat but sadly it was removed after one single release. I think this brings the total number of people I know who have been affected by this up to 6 now. > I didn't care what's on it now. All fresh install will do. > I have 22 to do. :( You can copy a new bootloader to the old machines and run installboot. -- Please keep replies on the mailing list.
Re: pkg_add - error while reading header / read short file / gzheader truncated
On Thu, Dec 07, 2023 at 12:35:01PM -, Stuart Henderson wrote: > pkg_add/ftp aren't good at retrying when network connections fail. > I'd think it's more likely a problem with your network connection > than the cdn server, but you could try one of the other mirrors > listed in www.openbsd.org/ftp.html (either set in /etc/installurl > or set in the PKG_PATH environment variable; you can just use the > hostname in the latter) Read the previous email carefully, paying attention to the bizarre quoting style... The person you replied to was actually answering the original question :-).
Weird network performance with iwn(4)
Hi all! Recently my trusty T410 died (had iwn(4) in it) and had to switch to an E450 - but this has iwm(4). Never had any issues with iwn(4) and iwm(4) seems to operate perfectly fine in some scenarios, e.g. speedtest.net indicates 100/100Mbit down/up speed. But downloading a base74.tgz set takes little more than 30 minutes - in firefox and in console with ftp(1). I know mirrors don't have the same bandwidth and connection to me, etc., but regardless, this is too slow even after factoring that in - plus it's the same with every mirror, even my own (not "local" local, but within the country). While looking at `systat ifstat 1` it starts out at 2 Bytes/s, then sometimes it goes up to a couple of 100KBytes, varies between 300-400-500KBytes/sec, then for a second it says 1MByte/s, then drops back to around 300-500KB/s, and this goes on. Meanwhile the same thing on a different machine/OS is 10+MByte/s. Generally speaking, browsing in firefox seems/feels slow - e.g. YouTube takes 10-20 seconds to load completely. I've installed the latest available firmware: iwm-firmware-20230330 Also thought about the disk being the bottleneck, but seems fair enough; it's an older SATA SSD: $ dd if=/dev/zero of=testfile bs=4096 31031+0 records in 31031+0 records out 127102976 bytes transferred in 1.084 secs (117233296 bytes/sec) $ ifconfig iwm0 iwm0: flags=a48843 mtu 1500 lladdr 60:57:xx:xx:xx:xx index 2 priority 4 llprio 3 groups: wlan egress media: IEEE802.11 autoselect (VHT-MCS5 mode 11ac) status: active ieee80211: join apname chan 44 bssid aa:bb:cc:dd:ee:ff 65% wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp inet 192.168.x.x netmask 0x broadcast 192.168.255.255 Is this something with .11ac not supported well enough, or this specific hardware? Any thoughts, suggestions are welcome :) Thanks, Daniel dmesg: OpenBSD 7.4-current (GENERIC.MP) #1471: Thu Nov 30 07:57:45 MST 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17078009856 (16286MB) avail mem = 16540798976 (15774MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x9cdfd000 (62 entries) bios0: vendor LENOVO version "J5ET64WW (1.35 )" date 10/31/2019 bios0: LENOVO 20DC008DHV efi0 at bios0: UEFI 2.3.1 efi0: Lenovo rev 0x1350 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP ASF! HPET ECDT APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI POAT BATB FPDT UEFI acpi0: wakeup devices LID_(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz, 1596.32 MHz, 06-45-01, patch 0026 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz, 1596.32 MHz, 06-45-01, patch 0026 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 3MB 64b/line 12-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i3-4005U CPU @ 1.70GHz, 1596.34 MHz, 06-45-01, patch 0026 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,
Re: Getting stuck on trying a fresh install to 7.4
On 12/7/23 7:37 AM, Stuart Henderson wrote: On 2023-12-06, Daniel Ouellet wrote: Any suggestion woudl be greattly appreciated. Old boot loaders cannot boot 7.4 kernels. Upgrade your 6.7 system to 7.3 first (the usual advice to avoid skipping releases during upgrades applies). Then upgrade to 7.4. Specifically the interface used for communicating system console information between the boot loader and the kernel was changed. There was backwards compat but sadly it was removed after one single release. I think this brings the total number of people I know who have been affected by this up to 6 now. I didn't care what's on it now. All fresh install will do. I have 22 to do. :( You can copy a new bootloader to the old machines and run installboot. Hi Stuart, Just to be clear and to help others here. You are talking about these two files only right? /usr/mdec/boot /usr/sbin/installboot or should this one below be included too? I don't think it's needed, but just want to be sure and make the info complete. /usr/mdec/biosboot
Re: Weird network performance with iwn(4)
On Thu, Dec 07, 2023 at 03:39:33PM +, Lévai, Dániel wrote: > Hi all! > > Recently my trusty T410 died (had iwn(4) in it) and had to switch to an E450 > - but this has iwm(4). > Never had any issues with iwn(4) and iwm(4) seems to operate perfectly fine > in some scenarios, e.g. speedtest.net indicates 100/100Mbit down/up speed. > But downloading a base74.tgz set takes little more than 30 minutes - in > firefox and in console with ftp(1). So you are getting 100/100 Mbit on iwm(4) in a speed test, and only downloading base74.tgz is slow? The speed test being successful would imply that the wifi layer is working just fine. If so then something else must be messing with your base74.tgz download attempts. What happens when you download base74.tgz over ethernet? Or with iwm(4) via a different AP? Or with iwm(4) via a different ISP?
Re: Weird network performance with iwn(4)
On Thu, Dec 07, 2023 at 03:39:33PM +, Lévai, Dániel wrote: > Hi all! > > Recently my trusty T410 died (had iwn(4) in it) and had to switch to an E450 > - but \ > this has iwm(4). Never had any issues with iwn(4) and iwm(4) seems to operate > \ > perfectly fine in some scenarios, e.g. speedtest.net indicates 100/100Mbit > down/up \ > speed. > But downloading a base74.tgz set takes little more than 30 minutes - in > firefox and \ > in console with ftp(1). Just a lucky guess, no offense please, are you using ftp2.eu.openbsd.org ?
Re: pkg_add - error while reading header / read short file / gzheader truncated
I see the same with multiple installs - Started with 7.4. No modification to default installurl. It is amazing - For 5 years, I never considered that pkg_add(1) could fail (and it didn't)! Updating my install scripts to try until the last package add, with -l option, is confirmed. A little concerned that a package could be partially installed / marked manual and not work (I think this has happened and I restarted from scratch). On Thu, 2023-12-07 at 00:07 -0800, Joe B wrote: > Hello Misc, > > I am configuring a couple of laptops for my kids, i had installed 70 > with > i3 and gcompris in them, its been a while since the last update so i > decided to make a fresh install. > > So I installed 74 in both of them, used the autoinstall so the > process was > straightforward as always, rebooted, hw_update, syspatch, everything > as > expected. > > The problem comes when trying to install a package, i am trying just > to of > them: feh and gcompris, in both laptops, and i get the following > errors, > they are several since i do a few tries and then the problem goes and > comes > at different packages > > pkg_add: Ustar [package name, it is different every try, meaning > lcms2-2.15.tgz, gstreamer, libass-] [?]: Error while reading header > https://cdn.openbsd.org/pub/OpenBSD/7.4/packages/amd64/lame-3.100p1.tgz > : > Read short file > > My configuration are: > 1 laptop, re0, trying pkg_add feh > 1 laptop, iwn0, trying pkg_add gcompris > > both with the same results, maybe i should try in another LAN, but > could it > be a problem with the CDN server ? > > Thank you for your time, > > -- Manuel Solis > > > > > > Hello, > > I'm new to openBSD about 3 days old. and I ran into the same issue as > you. I would > > pkg_add something and I kept getting the header message. someone on > IRC helped me > > Simple. change the cdn to another mirror > > look at https://www.openbsd.org/faq/faq15.html#Mirror > > Basically You find a mirror probably ftp like I did go to vim or nano > /etc/installurl > > delete the cdn add another mirror and re-run the pkg_add you might > need to pkg_delete > > the partial and then re-run. pkg_add After all that you might need > pkg_add -u to see if the new mirror > > fixes all the other partials > > > Hope this helps > > > ~ Joe B
Raspberry Pi Installation media gives blank screen on boot
Hello, I am in the process of turning a Void Linux Raspberry Pi 3 B server to one that runs OpenBSD 7.4. However, when attempting to begin the installation process, after the install media boots, the screen goes blank, nothing else happens afterwards, the keyboard lights still strangely react to caps lock and such. The HDMI monitor doesnt outright lose signal, the screen just remains black. I did the following steps. 1. Download miniroot74.img and install74.img from openbsd.org arm64 2. Write miniroot74.img to an SD card using dd doas dd if=miniroot74.img of=/dev/sdb 3. Write install74.img to a USB using dd doas dd if=install74.img of=/dev/sdb 4. Put in the SD card and USB 5. Start the Raspberry Pi Hardware involved: Raspberry Pi 3 B A USB Keyboard An HDMI monitor An ethernet cord A 32 GB sd card A 32 GB USB flashdrive Any help would be much appreciated. -- ~VK vilyaem.us.to
Re: NFS Server performance
On Tue, Dec 05, 2023 at 02:06:44PM +, Steven Surdock wrote: Using an OBSD 7.4 VM on VMware as an NFS server on HOST02. It is primarily used to store VMWare VM backups from HOST01, so VMWare is the NFS client. I'm seeing transfers of about 1.2 MB/s. Sounds about right. On a single (magnetic) disk, assume 200 ops/sec maximum, or about 5 kbyte per write op. Remember that NFS is synchronous. It is based on RPC, remote procedure calls. The call has to return a result to the client before the next call can happen. So your client (ESXi) is stuck at the synchronous write rate of your disk, which is governed by seek time and rotation rate. To confirm, run systat and note the "sec" measurement for your disk. It will likely be in the 0.5 to 1.0 range. This means your disk is 50% to 100% busy. And the speed is about 1MB/s. For improvement, use "-o noatime" on your exported partition mount. This reduces inode update IO. Or, try "-o async" if you want to live dangerously. Or, you could even try ext2 instead of ffs.rumour has it that ext2 is faster. I don't know, never having tried it. Or use an SSD for your export partition. Or, crank up a copy of Linux and run NFS v4 server. That will definitely be faster than any NFS v3 server. V4 streams writes, to be very simplistic about it. (I think you already confirmed it's NFS v3 with TCP, not NFS v2. You should turn UDP off for reliability reasons, not performance.) J
Re: NFS Server performance
> -Original Message- > From: j...@bitminer.ca > Sent: Thursday, December 7, 2023 7:55 PM > > On Tue, Dec 05, 2023 at 02:06:44PM +, Steven Surdock wrote: > > > > Using an OBSD 7.4 VM on VMware as an NFS server on HOST02. It is > > primarily used to store VMWare VM backups from HOST01, so VMWare is > > the NFS client. I'm seeing transfers of about 1.2 MB/s. > > Sounds about right. On a single (magnetic) disk, assume 200 ops/sec > maximum, or about 5 kbyte per write op. > > Remember that NFS is synchronous. It is based on RPC, remote procedure > calls. The call has to return a result to the client before the next call > can happen. So your client (ESXi) is stuck at the synchronous write rate > of your disk, which is governed by seek time and rotation rate. > > To confirm, run systat and note the "sec" measurement for your disk. > It will likely be in the 0.5 to 1.0 range. This means your disk is 50% to > 100% busy. And the speed is about 1MB/s. > > For improvement, use "-o noatime" on your exported partition mount. This > reduces inode update IO. > > Or, try "-o async" if you want to live dangerously. > > Or, you could even try ext2 instead of ffs.rumour has it that > ext2 is faster. I don't know, never having tried it. > > Or use an SSD for your export partition. > > Or, crank up a copy of Linux and run NFS v4 server. That will definitely > be faster than any NFS v3 server. V4 streams writes, to be very > simplistic about it. > > (I think you already confirmed it's NFS v3 with TCP, not NFS v2. > You should turn UDP off for reliability reasons, not performance.) So I thought that disk I/O might be an issue as well, but SCP rips at 800+ Mbps (95+ MBps). I did end up trying async and noatime on the filesystem. 'async' offered the best improvement with about 75 Mbps (or 9.3 MBps). Still not what I was hoping for, or even close to SCP. I did confirm NFS V3 (via tcpdump), plus esxi only supports V3 and V4. I also experimented with netbsd-iscsi-target-20111006p6, but I could not get esxi to connect reliably. You are correct on the disk performance during the NFS write: Disks sd0 sd1 seeks xfers 992 speed 110K 5915K sec 0.0 1.0 For the sake of completeness, here is the disk performance for the scp: Disks sd0 sd1 seeks xfers11 1559 speed 131K 97M sec 0.0 1.0 This is with /home mounted with 'ffs rw,nodev,nosuid 1 2' Thanks!
Re: NFS Server performance
On Tue, Dec 5, 2023 at 9:25 AM Zé Loff wrote: > > On Tue, Dec 05, 2023 at 02:06:44PM +, Steven Surdock wrote: > > Using an OBSD 7.4 VM on VMware as an NFS server on HOST02. It is > primarily used to store VMWare VM backups from HOST01, so VMWare is the NFS > client. I'm seeing transfers of about 1.2 MB/s. > > > > SCP from HOST01 to OBSD VM (same filesystem) copies at 110 MB/s. > > Iperf3 from a VM on HOST01 to OBSD on HOST02 gives me 900+ mbps. > > OBSD is a stock install running -stable. > > NFS is using v3 (according to VMWare) and using TCP > > During the NFS transfer the RECV-Q on the OBSD interface runs either > 64000+ or 0. > > I tried both em and vmx interface types. > > > > /etc/rc.conf.local: > > mountd_flags="" # for normal use: "" > > nfsd_flags="-tun 4" # Crank the 4 for a busy NFS fileserver > > ntpd_flags="" # enabled during install > > portmap_flags=""# for normal use: "" > > > > Any clues on where to look to (greatly) improve NFS performance would be > appreciated. > > Increasing write size, read size and the read-ahead count on the client > has helped me. > > E.g., on the client's fstab: > > 10.17.18.10:/shared/stuff /nfs/stuff nfs > rw,nodev,nosuid,intr,tcp,bg,noatime,-a=4,-r=32768,-w=32768 0 0 > > With this i got around 2.5x improvement (9-10MBps to 25-30MBps) > Cheers > Zé > > > > > -Steve S. > > > > -- > > >
unsubscribe
unsubscribe misc@openbsd.org
