Re: problems with installworld
On 18/08/2018 14:15, Polytropon wrote: Try to follow the instructions on top of /usr/src/Makefile (comment header). Before you perform "make installworld", make sure you have rebooted the system into single-user mode (with the new kernel). Also see "man 7 build" for details. yep, that fixed it, sorry for the noise ;) -- J. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mSATA strangeness (was Re: gpart strangeness)
OK, Some more odd things going on. If I write to a file from dd some random junk, not all of the file is saved when I do an unmount. This seems to be specific either to the ata controller of the APU or to the msata disk as I tested on a regular server with plain old disks and no issue Eric, any chance you can try this on your APU as well ? 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 0# hd /mnt/junk2 > /tmp/hd-junk2 0# ls -l /mnt/junk2 -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# umount /mnt 0# mount /dev/ada0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb 0# ls -l /mnt/junk2 -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount 0# ls -l /tmp/hd-junk2* -rw--- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 -rw--- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount 0# If I do the same test on a USB stick it works as expected 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# umount /mnt 0# mount /dev/da0p1 /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 0# Same with an SD card. All is OK 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 4+0 records in 4+0 records out 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# umount /mnt 0# mount /dev/mmcsd0s2a /mnt 0# md5 /mnt/junk2 MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 0# Looking at hd before and after, its missing the end of the file --- hd-junk22018-08-22 11:54:09.891572000 -0400 +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 @@ -24574,106500 +24574,6 @@ 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 |.q..x.r...;.1...| 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb |.9r..9...u...VC.| 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f |@.T...>..i.o| -0006 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 |..h.=..C| -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 |.[N..7..['.T| -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 |.l.}JJ..| -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 |.<...ONb^'.q| -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 |."..d#sg| -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 |.x...p.."...;u..| -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 |S9...9_.. ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) protocol ATA/ATAPI-10 SATA 3.x device model SATA SSD firmware revision S9FM02.0 serial number 81B5074C1B6500076878 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 31277232 sectors LBA48 supported 31277232 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM non-rotating Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags NCQ Queue Management no NCQ Streaming no Receive & Send FPDMA Queuedno SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management no no media status notification no no power-up in Standbyno no write-read-verify no no unload yes yes general purpose loggingyes yes free-fall no no Data Set Management (DSM/TRIM) yes DSM - max 512byte blocks yes 8 DSM - deterministic read no Host Protected Area (HPA) yes no 31277232/31277232 HPA - Security no 0# On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. >> >> There is an easy way to verify this just with naked eye: >> >> yes | dd bs=128k of=/dev/ada0 >> hd /dev/ada
Re: bad hash in repo
> seeing a lot of these > > Looking up update.FreeBSD.org mirrors... 2 mirrors found. > Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > Fetching 2 patches.. done. > Applying patches... done. > Fetching 2 files... > 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has > incorrect hash. these continue; like for a week. for multiple servers, all on the global internet no filters other than samba etc. randy ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: bad hash in repo
On 8/22/18 9:19 AM, Randy Bush wrote: seeing a lot of these Looking up update.FreeBSD.org mirrors... 2 mirrors found. Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. Fetching 2 patches.. done. Applying patches... done. Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorrect hash. these continue; like for a week. for multiple servers, all on the global internet no filters other than samba etc. have you forced pulling down metadata from the pkg servers? i have gotten into this state in the past and a "pkg update -f" would get me out of that scenario. -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: gpart strangeness (solved)
On 8/21/2018 2:30 PM, Mike Tancsa wrote: > On 8/21/2018 9:51 AM, Eugene Grosbein wrote: >> >> It seems like faulty media to me: it silently returns bad data. OK, it was a config issue on my part! Some legacy config from the long ago days of Soekris 5501s, had hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf Commenting those out fixed the issue! Sorry for the noise everyone! ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mSATA strangeness (was Re: gpart strangeness)
Never mind, I found the issue hw.ata.ata_dma=0 hw.ata.atapi_dma=0 in /boot/loader.conf, hanging around from the days of wood burning power supplies was causing this strange behaviour! Sorry for the noise folks! ---Mike On 8/22/2018 12:17 PM, Mike Tancsa wrote: > OK, > Some more odd things going on. If I write to a file from dd some random > junk, not all of the file is saved when I do an unmount. This seems to > be specific either to the ata controller of the APU or to the msata disk > as I tested on a regular server with plain old disks and no issue > > Eric, any chance you can try this on your APU as well ? > > > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.101394 secs (20683253 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = acca1d8997c3b9d906b40d99cba734b6 > 0# hd /mnt/junk2 > /tmp/hd-junk2 > 0# ls -l /mnt/junk2 > -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# umount /mnt > 0# mount /dev/ada0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 2ef0cadf32db4e07a8edf4fc66f8a4eb > 0# ls -l /mnt/junk2 > -rw--- 1 root wheel - 2097152 Aug 22 11:53 /mnt/junk2 > 0# hd /mnt/junk2 > /tmp/hd-junk2-post-mount > 0# ls -l /tmp/hd-junk2* > -rw--- 1 root wheel - 10354697 Aug 22 11:54 /tmp/hd-junk2 > -rw--- 1 root wheel - 1941594 Aug 22 11:54 /tmp/hd-junk2-post-mount > 0# > > If I do the same test on a USB stick it works as expected > > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.102256 secs (20508777 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# umount /mnt > 0# mount /dev/da0p1 /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 51190332cdd4ef898bdc9c2520a9f749 > 0# > Same with an SD card. All is OK > > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# dd if=/dev/urandom of=/mnt/junk2 bs=512k count=4 > 4+0 records in > 4+0 records out > 2097152 bytes transferred in 0.107400 secs (19526588 bytes/sec) > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# umount /mnt > 0# mount /dev/mmcsd0s2a /mnt > 0# md5 /mnt/junk2 > MD5 (/mnt/junk2) = 0811af4e57ab5a3bc224e5b8f8b3bc29 > 0# > > Looking at hd before and after, its missing the end of the file > > --- hd-junk22018-08-22 11:54:09.891572000 -0400 > +++ hd-junk2-post-mount 2018-08-22 11:54:41.996983000 -0400 > @@ -24574,106500 +24574,6 @@ > 0005ffd0 8b 71 87 b8 78 03 72 ca 0e 06 3b d4 31 fd 18 f8 > |.q..x.r...;.1...| > 0005ffe0 de 39 72 fb c8 39 fd 1f 93 75 10 de 05 56 43 fb > |.9r..9...u...VC.| > 0005fff0 40 ce 54 e2 a4 17 3e 1e ec 01 b7 fd 1b 69 b7 6f > |@.T...>..i.o| > -0006 91 f3 02 ea 95 f4 12 1c bf 00 68 1b 3d 8c 01 43 > |..h.=..C| > -00060010 f6 5b 4e ec 7f 37 19 15 5b c4 e6 fb 88 27 1c 54 > |.[N..7..['.T| > -00060020 15 6c 02 7d fb 00 06 c1 4a 4a bf ce 9a 1b fe d4 > |.l.}JJ..| > -00060030 1c 3c b5 05 b6 4f 4e 62 b5 03 e3 e7 5e 27 d6 71 > |.<...ONb^'.q| > -00060040 ea 22 00 99 9d 13 e8 a9 64 0e fd 13 cc 23 73 67 > |."..d#sg| > -00060050 8e 78 0a ad ae 70 ab e4 22 b4 b7 b9 3b 75 9f 85 > |.x...p.."...;u..| > -00060060 53 39 0c af 15 39 5f 04 ac 3c 65 e9 ea 29 1d b7 > |S9...9_.. -00060070 ea f0 2f 19 3c 6d 1c 21 f1 58 4a 4b a8 26 8e f6 > |../. -00060080 05 99 8a 9d 54 75 e4 77 78 78 6c 75 21 31 d4 0c > |Tu.wxxlu!1..| > -00060090 52 88 c6 65 c0 09 04 ce 7f 5f 29 0c 46 9a 68 13 > |R..e._).F.h.| > -000600a0 73 30 97 78 d7 b7 d2 ba 8f 73 27 58 3d eb 0c d6 > |s0.x.s'X=...| > > > 1# camcontrol identify ada0 > pass0: ACS-3 ATA SATA 3.x device > pass0: 600.000MB/s transfers (SATA 3.x, PIO4, PIO 8192bytes) > > protocol ATA/ATAPI-10 SATA 3.x > device model SATA SSD > firmware revision S9FM02.0 > serial number 81B5074C1B6500076878 > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 31277232 sectors > LBA48 supported 31277232 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > Zoned-Device Commands no > > Feature Support Enabled Value Vendor > read ahead yes yes > write cacheyes yes > flush cacheyes yes > overlapno > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > NCQ Queue Management no > NCQ Streaming no > Receive & Send FPDMA Queuedno > SMART yes yes > microcode download yes yes > security yes no > power management
Re: bad hash in repo
>>> seeing a lot of these >>> >>> Looking up update.FreeBSD.org mirrors... 2 mirrors found. >>> Fetching metadata signature for 11.1-RELEASE from update4.freebsd.org... >>> done. >>> Fetching metadata index... done. >>> Inspecting system... done. >>> Preparing to download files... done. >>> Fetching 2 patches.. done. >>> Applying patches... done. >>> Fetching 2 files... >>> 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has >>> incorrect hash. >> these continue; like for a week. for multiple servers, all on the >> global internet no filters other than samba etc. > > have you forced pulling down metadata from the pkg servers? i have > gotten into this state in the past and a "pkg update -f" would get me > out of that scenario. # pkg update -f Updating FreeBSD repository catalogue... Fetching meta.txz: 100%944 B 0.9kB/s00:01 Fetching packagesite.txz: 100%6 MiB 2.2MB/s00:03 Processing entries: 100% FreeBSD repository update completed. 32029 packages processed. All repositories are up to date. # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 2 mirrors found. Fetching metadata signature for 11.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. Fetching 2 patches.. done. Applying patches... done. Fetching 2 files... 104969ef03336523729ea1df2547267441a13cb040c778e971b74103e88dbc77 has incorrect hash. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
