Re: Mounting USB drive
netve...@gmail.com (Ron Georgia) writes: >When trying to mount I get the following: >sudo mount /dev/sd0a /mnt/sans/ >mount_ffs: /dev/sd0a on /mnt/sans: incorrect super block >sudo mount -t msdos /dev/sd0a /mnt/sans/ >mount_msdos: /dev/sd0a on /mnt/sans: Invalid argument That probably says that there is no formatted filesystem, neither FFS (very likely) nor FAT (that would be common) on partition 'a'. >4 partitions: >#sizeoffset fstype [fsize bsize cpg/sgs] > a: 3072 0 4.2BSD 0 0 0 # (Cyl. 0 - 14999) > d: 3072 0 unused 0 0# (Cyl. 0 - 14999) >Partition table: >0: Primary DOS with 32 bit FAT - LBA (sysid 12) >start 2048, size 30922752 (15099 MB, Cyls 0-1924/249/53), Active >1: >2: >3: That doesn't agree. While a FAT partition at block 2048 on a 16GB drive isn't that common, it's probably correct. A synthesized disklabel would match the MBR, so that one has probably been written to the USB drive. Can you try to erase the label with 'disklabel -D sd0' ? -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Attaching gdb session to a service launched from rc.d
I'm still experiencing problems with attaching a process to a service from rc.d: What happens often is I am seeing three threads in my process, however thread #1 and #2 are identical (and should be 2, perhaps ?) I was doubting my own code, but I check a local variable and it shows at the same address, I will restart to see what this does. Thank you! Germain -- Germain Le Chapelain Lanvaux Computer Games Limited
Re: gcc issues when compiling ArcticFox browser
Hi, Leonardo Taccari wrote: I think that's unrelated. USE_PKGSRC_GCC_RUNTIME is used as a kludge to depends on corresponding gcc-libs package (USE_GCC_RUNTIME should be used). I am still stuck with this and looked at it a bit further. The error is: 76:42.39 In file included from /usr/pkg/gcc6/include/c++/math.h:36:0, 76:42.39 from /home/multix/code/Arctic-Fox/intl/icu/source/common/putil.cpp:63: 76:42.39 /usr/pkg/gcc6/include/c++/cmath:1101:11: error: '::double_t' has not been declared 76:42.39 using ::double_t; 76:42.39 ^~~~ and the code in putil.cpp around that line is: // Must be before any other #includes. #include "uposixdefs.h" /* include ICU headers */ #include "unicode/utypes.h" #include "unicode/putil.h" #include "unicode/ustring.h" #include "putilimp.h" #include "uassert.h" #include "umutex.h" #include "cmemory.h" #include "cstring.h" #include "locmap.h" #include "ucln_cmn.h" #include "charstr.h" /* Include standard headers. */ #include #include #include #include There is no code, just include and the compiler barfs at math.h - so it looks to me that somehow GCC's 6.5 headers are inconsistent and I think this is a pkg issue, but can't really prove that. This is an older version of ICU, so nto even real FF code. If gcc 5.5 could compile it and gcc 7 too, I am even more convinced that it is a system vs. pkg compiler issue. WHy, I don't know. Are any tricks needed when using the pkg compiler? I just used: export CC="/usr/pkg/gcc6/bin/gcc" export CXX="/usr/pkg/gcc6/bin/g++" no other tricks or settings. Riccardo Riccardo
Re: current transaction too big to flush
kab...@lich.phys.spbu.ru (Dima Veselov) writes: >Maybe I need to create PR, but here might be a >person already met the situation of kernel panic >on big file operation. When I try to delete several >files (from 1 to 8 Gb at once) from net/transmission >interface I get kernel panic like this: >panic: wapbl_flush: current transaction too big to flush Yes, that's a known problem. You might increase the journal size to allow for larger transactions with the tunefs command. But there is still a limit that you could hit. >I also have question about dumping: kernel can't >do dump on panic: >dumping to dev 168,2 (offset=4278362, size=515454): >dump device bad >Why it is bad if it work as a swap normally? "device bad" means an ENXIO error from the device driver. There could be several reasons for that, but I'd guess that the partition isn't typed as "swap" or "raid". The swap code ignores the type, but the dump code does not. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Mounting USB drive
I know this may seem old by now, but I cannot mount a USB stick. I find how to mount a CD, DVD and even a floppy, but mounting a USB seems to allude me. Even if someone can point me to a wiki or other resource, I would appreciate it. When I plug in the USB drive I get this in dmesg: [ 436511.473549] umass1: Generic (0x90c) Nexcopy Device (0x1000), rev 3.00/11.00, addr 12 [ 436511.473549] umass1: using SCSI over Bulk-Only [ 436511.483564] scsibus1 at umass1: 2 targets, 1 lun per target [ 436511.623791] sd0 at scsibus1 target 0 lun 0: disk removable [ 436511.633806] sd0: fabricating a geometry [ 436511.633806] sd0: 15000 MB, 15000 cyl, 64 head, 32 sec, 512 bytes/sect x 3072 sectors [ 436511.633806] sd0: fabricating a geometry [ 436511.633806] sd0: mbr partition exceeds disk size [ 436512.635426] sd0: mbr partition exceeds disk size [ 436512.645441] sd0: mbr partition exceeds disk size When trying to mount I get the following: sudo mount /dev/sd0a /mnt/sans/ mount_ffs: /dev/sd0a on /mnt/sans: incorrect super block sudo mount -t msdos /dev/sd0a /mnt/sans/ mount_msdos: /dev/sd0a on /mnt/sans: Invalid argument disklabel: # /dev/sd0: type: SCSI disk: Mass Storage label: default label flags: removable bytes/sector: 512 sectors/track: 32 tracks/cylinder: 64 sectors/cylinder: 2048 cylinders: 15000 total sectors: 3072 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # microseconds track-to-track seek: 0 # microseconds drivedata: 0 4 partitions: #sizeoffset fstype [fsize bsize cpg/sgs] a: 3072 0 4.2BSD 0 0 0 # (Cyl. 0 - 14999) d: 3072 0 unused 0 0# (Cyl. 0 - 14999) disklabel: boot block size 0 disklabel: super block size 0 ~> fdisk /dev/sd0 fdisk: Cannot determine the number of heads Disk: /dev/sd0 NetBSD disklabel disk geometry: cylinders: 15000, heads: 64, sectors/track: 32 (2048 sectors/cylinder) total sectors: 3072, bytes/sector: 512 BIOS disk geometry: cylinders: 1023, heads: 255, sectors/track: 63 (16065 sectors/cylinder) total sectors: 3072 Partitions aligned to 2048 sector boundaries, offset 2048 Partition table: 0: Primary DOS with 32 bit FAT - LBA (sysid 12) start 2048, size 30922752 (15099 MB, Cyls 0-1924/249/53), Active 1: 2: 3: First active partition: 0 Drive serial number: 0 (0x) Ron Georgia “90% of my problems are due to ignorance, the other 10% is because I just don’t know any better.”
current transaction too big to flush
Hello, Maybe I need to create PR, but here might be a person already met the situation of kernel panic on big file operation. When I try to delete several files (from 1 to 8 Gb at once) from net/transmission interface I get kernel panic like this: panic: wapbl_flush: current transaction too big to flush cpu0: Begin traceback... vpanic() at netbsd:vpanic+0x15d snprintf() at netbsd:snprintf wapbl_stop() at netbsd:wapbl_stop wapbl_begin() at netbsd:wapbl_begin+0x5b ufs_inactive() at netbsd:ufs_inactive+0x13a VOP_INACTIVE() at netbsd:VOP_INACTIVE+0x4c vrelel() at netbsd:vrelel+0x168 ufs_remove() at netbsd:ufs_remove+0xab VOP_REMOVE() at netbsd:VOP_REMOVE+0x50 do_sys_unlinkat.isra.5() at netbsd:do_sys_unlinkat.isra.5+0x1eb syscall() at netbsd:syscall+0x1ec --- syscall (number 10) --- 7887406fb53a: cpu0: End traceback... I also have question about dumping: kernel can't do dump on panic: dumping to dev 168,2 (offset=4278362, size=515454): dump device bad Why it is bad if it work as a swap normally? [root@ssd ~]$ swapctl -l Device 512-blocks UsedAvail Capacity Priority /dev/dk2 84019950 8401995 0%0 [root@ssd ~]$ ls -la /dev/dk2 brw-r- 1 root operator 168, 2 Apr 19 2018 /dev/dk2
Unable to boot 8.1 on i386
Hi! I have a Thinkpad R51 which is running 8.0 quite fine (except well known problems). To test these Problems, I also did occasionally boot 8.99 I did download NetBSD 8.1 to upgrade, but it fails to boot! I see the typical kernel loading numbers and spinner, then almost the first message is printed out about a file missing and then the computer reboots. I tried netbsd-INSTALL.gz and then also did burn boot.iso and have the same effect. Is the image busted? It doesn't look like a computer specific issue... Riccardo Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 8.0 (GENERIC) #0: Tue Jul 17 14:59:51 UTC 2018 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/i386/compile/GENERIC total memory = 2038 MB avail memory = 1985 MB rnd: seeded with 128 bits timecounter: Timecounters tick every 10.000 msec Kernelized RAIDframe activated running cgd selftest aes-xts-256 aes-xts-512 done timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 IBM 288732G (ThinkPad R51) mainbus0 (root) ACPI: RSDP 0x000F6DA0 24 (v02 IBM ) ACPI: XSDT 0x7F6EB16B 4C (v01 IBM TP-1V 1290 LTP ) ACPI: FACP 0x7F6EB200 F4 (v03 IBM TP-1V 1290 IBM 0001) ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20170303/tbfadt-642) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has valid Address but zero Length: 0x102C/0x0 (20170303/tbfadt-693) ACPI: DSDT 0x7F6EB3E7 00BA37 (v01 IBM TP-1V 1290 MSFT 010E) ACPI: FACS 0x7F6F8000 40 ACPI: FACS 0x7F6F8000 40 ACPI: SSDT 0x7F6EB3B4 33 (v01 IBM TP-1V 1290 MSFT 010E) ACPI: ECDT 0x7F6F6E1E 52 (v01 IBM TP-1V 1290 IBM 0001) ACPI: TCPA 0x7F6F6E70 32 (v01 IBM TP-1V 1290 PTL 0001) ACPI: BOOT 0x7F6F6FD8 28 (v01 IBM TP-1V 1290 LTP 0001) ACPI: 2 ACPI AML tables successfully acquired and loaded cpu0 at mainbus0 cpu0: Intel(R) Pentium(R) M processor 1500MHz, id 0x695 cpu0: package 0, core 0, smt 0 acpi0 at mainbus0: Intel ACPICA 20170303 acpi0: X/RSDT: OemId , AslId < LTP,> acpiecdt0 at acpi0: ACPI Embedded Controller via ECDT LNKA: ACPI: Found matching pin for 0.2.INTA at func 0: 11 LNKA: ACPI: Found matching pin for 0.29.INTA at func 0: 11 LNKD: ACPI: Found matching pin for 0.29.INTB at func 1: 11 LNKC: ACPI: Found matching pin for 0.29.INTC at func 2: 11 LNKH: ACPI: Found matching pin for 0.29.INTD at func 7: 11 LNKC: ACPI: Found matching pin for 0.31.INTA at func 1: 255 LNKB: ACPI: Found matching pin for 0.31.INTB at func 3: 11 LNKA: ACPI: Found matching pin for 2.0.INTA at func 0: 11 LNKF: ACPI: Found matching pin for 2.2.INTA at func 0: 11 LNKE: ACPI: Found matching pin for 2.8.INTA at func 0: 11 acpi0: SCI interrupting at int 9 timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 acpiec0 at acpi0 (EC, PNP0C09-0): using acpiecdt0 MEM (PNP0C01) at acpi0 not configured acpilid0 at acpi0 (LID, PNP0C0D): ACPI Lid Switch acpibut0 at acpi0 (SLPB, PNP0C0E): ACPI Sleep Button SIO (PNP0C02) at acpi0 not configured attimer1 at acpi0 (TIMR, PNP0100): io 0x40-0x43 irq 0 pcppi1 at acpi0 (SPKR, PNP0800): io 0x61 midi0 at pcppi1: PC speaker sysbeep0 at pcppi1 FPU (PNP0C04) at acpi0 not configured pckbc1 at acpi0 (KBD, PNP0303) (kbd port): io 0x60,0x64 irq 1 pckbc2 at acpi0 (MOU, IBM0057) (aux port): irq 12 LPT (PNP0400) at acpi0 not configured acpibat0 at acpi0 (BAT0, PNP0C0A-0): ACPI Battery acpibat0: SANYO LION rechargeable battery acpibat0: granularity: low->warn 0.001 Wh, warn->full 0.001 Wh acpiacad0 at acpi0 (AC, ACPI0003-0): ACPI AC Adapter thinkpad0 at acpi0 (HKEY, IBM0068) acpivga0 at acpi0 (VID): ACPI Display Adapter acpiout0 at acpivga0 (LCD0, 0x0400): ACPI Display Output Device acpiout1 at acpivga0 (CRT0, 0x0100): ACPI Display Output Device acpiout2 at acpivga0 (TV0, 0x0200): ACPI Display Output Device acpivga0: connected output devices: acpivga0: 0x0400 (acpiout0): Unknown Output Device, head 0 acpivga0: 0x0100 (acpiout1): Ext. Monitor, head 0 acpivga0: 0x0200 (acpiout2): TV, head 0 acpitz0 at acpi0 (THM0) acpitz0: levels: critical 94.0 C, passive 86.5 C, passive cooling apm0 at acpi0: Power Management spec V1.2 attimer1: attached to pcppi1 pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 5.9 pms0: Passthrough, Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev
Re: Typo in vitut.txt
On Mon, Jun 17, 2019 at 05:44:28PM +0200, ignat...@cs.uni-bonn.de wrote: > On Mon, Jun 17, 2019 at 03:26:43PM -, Valery Ushakov wrote: > > adr wrote: > > > > > /usr/share/doc/usd/vi/vitut.txt lines 943-984/2970 ... > > [...] > > > "...you shoud use a _named_ buffer." > > > > Applied. Thank you. > > Ahem. From finger memory: this isn't true for our version of nvi, > or is it? *checking* I think not. Maybe we should add a footnote? >From the vi/ex reference, /usr/share/doc/reference/ref1/vi/vi.txt: Historically, the contents of the unnamed buffer were discarded by many different commands, even ones that didn't store text into it. Nex/nvi never discards the contents of the unnamed buffer until new text replaces them. -is
Re: Typo in vitut.txt
On Mon, Jun 17, 2019 at 03:26:43PM -, Valery Ushakov wrote: > adr wrote: > > > /usr/share/doc/usd/vi/vitut.txt lines 943-984/2970 ... > [...] > > "...you shoud use a _named_ buffer." > > Applied. Thank you. Ahem. From finger memory: this isn't true for our version of nvi, or is it? *checking* I think not. Maybe we should add a footnote? -is
Re: Typo in vitut.txt
adr wrote: > /usr/share/doc/usd/vi/vitut.txt lines 943-984/2970 ... [...] > "...you shoud use a _named_ buffer." Applied. Thank you. -uwe
Typo in vitut.txt
/usr/share/doc/usd/vi/vitut.txt lines 943-984/2970 ... [...] An ordinary delete command saves the text in the unnamed buffer, so that an ordinary put can move it elsewhere. However, the unnamed buffer is lost when you change files, so to move text from one file to another you should use an unnamed buffer. [...] "...you shoud use a _named_ buffer." Please if you are not interested in this type of feedback, let me know. adr.
