Aw: recent change to vim defaults?
Julian Elischer wrote: > I noticed that suddenly vim is grabbing mouse movements, which makes > life really hard. > > Was there a specific revision that brought in this change, and can it > be removed? Of course this behavior can be disabled as suggested by others--or you give it a try. IMHO using the mouse in vim has many advantages. To temporarily disable the mouse you can press the SHIFT key. As long as SHIFT is pressed vim ignores the mouse. So you may use copy/paste with left and middle mouse buttons as before or you now use the mouse to position the cursor or select text--very useful IMHO (I actually have "set mouse=a" in .vimrc... ;) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WLAN hardware not recognized
Adrian Chadd wrote: > Right, you need to create the interface: > > ifconfig wlan0 create wlandev iwn0 > > then run wpa_spuplicant > > (or do it all in /etc/rc.conf .. :) That seems to work. There seems to be something configured wrong for wpa_supplicant but WLAN does react. Thank you for all your WLAN work! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WLAN hardware not recognized
Conrad Meyer wrote: > "[1] iwn0: mem 0xf7b0-0xf7b01fff > irq 18 at device 0.0 on pci3" is fine; "module iwn already present!" > is fine. > > What makes you say it isn't recognized or doesn't work? ifconfig iwn0 says "interface iwn0 does not exist". Also starting wpa_supplicant doesn't work (I use a wpa setup that did work on my previous laptop on FreeBSD 10). At install time I only "configured" ethernet, iwn0 I skipped since I intented to configure that later. But that may not be relevant. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: WLAN hardware not recognized
Adrian Chadd wrote: > sysctl net.wlan.devices > > iwn0 no longer shows up in ifconfig -a . > > > -a Ok, "sysctl -a|grep iwn" gives quite some output. Actually I tried to start wpa_supplicant, but WLAN didn't react. Then--just for testing--I wrote "ifconfig iwn0 up", where ifconfig reported that iwn0 is unknown. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WLAN hardware not recognized
Conrad Meyer wrote: > kldload iwn6000fw, iwn6000g2afw, iwn6000g2bfw. This or edit loader.conf doesn't help, all these things had already been in the kernel. dmesg stays the same. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WLAN hardware not recognized
Larry Rosenman wrote: > Did you load the iwn firmware? How do I do this? I put "if_iwn_load="YES"" into /boot/loader.conf, now I get "module iwn already present!" in dmesg... ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: WLAN hardware not recognized
Joe Nosay wrote: > Is the card removable? If so, have you tried plugging in one that would > have the driver already included with the base - so to speak - system? Have > you tried the card in another computer/laptop? It is an integrated card. Theoretical it is removeable, but this is by design intented only for repairing reasons. I have never tried another card in this laptop. --Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
WLAN hardware not recognized
Hello, the WLAN hardware of my Dell E6540 (intel 633ANHMW) is not recognized (or at least does not work). The only message found in dmesg is: [1] iwn0: mem 0xf7b0-0xf7b01fff irq 18 at device 0.0 on pci3 Full dmesg is: Copyright (c) 2013-2016 The HardenedBSD Project. [1] Copyright (c) 1992-2016 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 11.0-CURRENT-HBSD #18 7affcca(HEAD): Fri Feb 19 03:41:41 EST 2016 [1] jenk...@nyi-01.build.hardenedbsd.org:/usr/obj/jenkins/workspace/HardenedBSD-CURRENT-i915kms-amd64/sys/HARDENEDBSD amd64 [1] FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225 [1] WARNING: WITNESS option enabled, expect reduced performance. [1] VT(vga): resolution 640x480 [1] HBSD: initialize and check HardenedBSD features (version 41). [1] [HBSD LOG] logging to system: enabled [1] [HBSD LOG] logging to user: disabled [1] [HBSD ASLR] status: opt-out [1] [HBSD ASLR] mmap: 30 bit [1] [HBSD ASLR] exec base: 30 bit [1] [HBSD ASLR] stack: 42 bit [1] [HBSD ASLR] vdso: 28 bit [1] [HBSD ASLR] map32bit: 18 bit [1] [HBSD ASLR] disallow MAP_32BIT mode mmap: opt-out [1] [HBSD PAGEEXEC] status: opt-out [1] [HBSD MPROTECT] status: opt-out [1] [HBSD HARDENING] procfs hardening: enabled [1] [HBSD HARDENING] randomize pids: enabled [1] [HBSD HARDENING] unset insecure init variables: enabled [1] [HBSD SEGVGUARD] status: opt-in [1] [HBSD SEGVGUARD] expiry: 120 sec [1] [HBSD SEGVGUARD] suspension: 600 sec [1] [HBSD SEGVGUARD] maxcrahes: 5 [1] CPU: Intel(R) Core(TM) i5-4300M CPU @ 2.60GHz (2594.05-MHz K8-class CPU) [1] Origin="GenuineIntel" Id=0x306c3 Family=0x6 Model=0x3c Stepping=3 [1] Features=0xbfebfbff [1] Features2=0x7ffafbff [1] AMD Features=0x2c100800 [1] AMD Features2=0x21 [1] Structured Extended Features=0x27ab [1] XSAVE Features=0x1 [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory = 8589934592 (8192 MB) [1] avail memory = 8158760960 (7780 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads [1] cpu0 (BSP): APIC ID: 0 [1] cpu1 (AP): APIC ID: 1 [1] cpu2 (AP): APIC ID: 2 [1] cpu3 (AP): APIC ID: 3 [1] random: unblocking device. [1] ioapic0 irqs 0-23 on motherboard [1] random: entropy device external interface [1] kbd1 at kbdmux0 [1] netmap: loaded module [1] module_register_init: MOD_LOAD (vesa, 0x80eea620, 0) error 19 [1] random: registering fast source Intel Secure Key RNG [1] random: fast provider: "Intel Secure Key RNG" [1] vtvga0: on motherboard [1] cryptosoft0: on motherboard [1] aesni0: on motherboard [1] acpi0: on motherboard [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] cpu1: on acpi0 [1] cpu2: on acpi0 [1] cpu3: on acpi0 [1] hpet0: iomem 0xfed0-0xfed003ff on acpi0 [1] Timecounter "HPET" frequency 14318180 Hz quality 950 [1] Event timer "HPET" frequency 14318180 Hz quality 550 [1] Event timer "HPET1" frequency 14318180 Hz quality 440 [1] Event timer "HPET2" frequency 14318180 Hz quality 440 [1] Event timer "HPET3" frequency 14318180 Hz quality 440 [1] Event timer "HPET4" frequency 14318180 Hz quality 440 [1] atrtc0: port 0x70-0x77 irq 8 on acpi0 [1] atrtc0: Warning: Couldn't map I/O. [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0 [1] acpi_ec0: port 0x930,0x934 on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: irq 16 at device 1.0 on pci0 [1] pci1: on pcib1 [1] vgapci0: port 0xe000-0xe0ff mem 0xe000-0xefff,0xf7c0-0xf7c3 irq 16 at device 0.0 on pci1 [1] vgapci1: port 0xf000-0xf03f mem 0xf580-0xf5bf,0xd000-0xdfff irq 16 at device 2.0 on pci0 [1] agp0: on vgapci1 [1] agp0: aperture size is 256M, detected 32764k stolen memory [1] vgapci1: Boot video device [1] hdac0: mem 0xf7d24000-0xf7d27fff irq 16 at device 3.0 on pci0 [1] pci0: at device 22.0 (no driver attached) [1] uart2: port 0xf0e0-0xf0e7 mem 0xf7d2e000-0xf7d2efff irq 19 at device 22.3 on pci0 [1] em0: port 0xf080-0xf09f mem 0xf7d0-0xf7d1,0xf7d2d000-0xf7d2dfff irq 20 at device 25.0 on pci0 [1] em0: Using an MSI interrupt [1] em0: Ethernet address: f0:1f:af:4e:d5:85 [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 [1] ehci0: mem 0xf7d2c000-0xf7d2c3ff irq 16 at device 26.0 on pci0 [1] usbus0: EHCI version 1.0 [1] usbus0 on ehci0 [1] hdac1: mem 0xf7d2-0xf7d23fff irq 22 at device 27.0 on pci0
Aw: Re: Haswell graphics (i915) still not in CURRENT
Shawn Webb wrote: > We at HardenedBSD have an experimental branch that is kept up-to-date > with FreeBSD HEAD along with Jean-Sebastien's excellent work (and > HardenedBSD's awesomeness on top of that). > > The code is here: > > https://github.com/HardenedBSD/hardenedBSD-playground/tree/hardened/experime > ntal/master-i915 > > Latest builds are here: > > http://jenkins.hardenedbsd.org/builds/HardenedBSD-CURRENT-i915kms-amd64-LATE > ST/ISO-IMAGES/ Thank you for that suggestion, this works well! --Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Haswell graphics (i915) still not in CURRENT
Hello, Haswell graphics (i915) still seems not to be in CURRENT. There is a suggested test procedure on https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20Linux%203.8 but currently I'm to busy with other projects to test this. At the moment CURRENT can't be used on laptops with i915 graphics, so it may not harm to integrate a buggy i915 support in CURRENT. The advantage would be that more users would test the driver and could give response. This may speed up the debugging/testing of this driver. --Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No X on Dell E6540
Warren Block wrote: > The vesa driver can be run on most systems where the newer graphics are > not directly supported. See the last example here: > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html#x-c > onfig-video-cards-file My experience from qemu is that vesa doesn't support resolution 1920x1080. In this case I couldn't use it. I'll test it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: make .SUFFIXES bug?
Thomas Dickey wrote: > On Tue, Dec 15, 2015 at 04:01:41PM +0100, Carsten Kunze wrote: > > current groff doesn't build on FreeBSD. I had noticed the same issue some > > months ago on NetBSD and cross checked on FreeBSD and it had worked on > > FreeBSD. There must have somethig changed since then. How to reproduce: > > > > When there is a file "test.1.man" and a makefile: > > > > .SUFFIXES: > > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf > > .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp > According to POSIX > > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html > > .SUFFIXES > Prerequisites of .SUFFIXES shall be appended to the list of known > suffixes > and are used in conjunction with the inference rules (see Inference > Rules). > If .SUFFIXES does not have any prerequisites, the list of known > suffixes > shall be cleared. > > and goes on to list the expected suffixes: > > .SUFFIXES: .o .c .y .l .a .sh .f .c? .y? .l? .sh? .f? Why is this relevant? The first "empty" .SUFFIXES line in the example above clears all default (or previously set) suffixes and the second one sets the project relevant suffixes. So I can assume that for the following suffix rules *these* specified suffixes are used. > > .man: > > @echo Making $@ from $< > > rm -f $@ > > @LC_ALL=C \ > > sed -e "s|foo|bar|g" \ > > $< >$@ > > > > "make test.1" results in "make: don't know how to make test.1. Stop". > > > > When ".man" is put to the start of the list it works. It also works when > > the first .SUFFIXES line is removed. > > > > The answer from NetBSD is that this is very likely a bug in make. May > > this > > also be the case for FreeBSD? > That's ironic, considering that a while back they were adamant that if > the suffix wasn't in the list cited in POSIX, then it was a bug in the > makefile. I agree, but ".man" is in the list. > Your example does not list a suffix for ".1". It would be harmless to > update groff's makefile to provide that, and a corresponding suffix-rule. Please don't consider .1 as a suffix here. The task is to make "test.1", it could also be named test_1 or whatever. So according to the known suffixes make looks for a file "test.1" until it finds "test.1.man". So the ".man:" rule generates a from a .man, in this case test.1 from test.1.man. So I do not really see a bug in the makefile. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: keymap set after file system decryption
Trond Endrestøl wrote: > I guess we who live outside the US should take into account that PCs > are initialised by firmware to the US keyboard layout and the 437 code > page, courtesy of IBM, 1981. In 1981 I had accepted this. Now it's simply a bug and I wonder it has not been fixed in 22 years. I'll file a bug report. > I'm not sure if the creators of (U)EFI has considered other keyboard > layouts and/or code pages at boot time. I don't care for the BIOS here, the OS has to take care of it. It may be ok that at the boot prompt only US keymap is set. But when the rc scripts are running the keymap must be set correctly (as one of the first actions). > A bad workaround is to copy the suitable keymap from /usr/share... to > /etc, along with /usr/sbin/kbdcontrol, and add a suitable line to one > or either of /etc/rc.d/geli{,2}, e.g.: > > /etc/kbdcontrol -l /etc/german.iso.kbd > > kbdcontrol is linked only to libc: > > $ ldd `which kbdcontrol` > /usr/sbin/kbdcontrol: > libc.so.7 => /lib/libc.so.7 (0x800827000) In my case it's simpler since I have /usr in /, but as you descripted kbdcontrol must be in /sbin and the maps in /etc in the future. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
keymap set after file system decryption
Hello, according to the boot messages the keymap is set after decryption of file systems. I consider this as a bug. The geli decryption script asks for the passphrase which can't of course be input if the kaymap is not set. Handbook §17.12 does not mention the keymap setup. What can I do to make this work? (Of course I can call e.g. kbdmap in /etc/rc.d/geli, but this is kind of tinkering.) Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Do keymaps need to be in /usr/...?
Hello, disk decryption works for me when I put kbdcontrol -l /usr/share/syscons/keymaps/german.iso.kbd into /etc/rc.d/geli. But do the keymaps need to be in a file system which may be mounted delayed? If there is an error at boot time and something needs to be input to the console the keyboard can be considered as unusable until the correct keymap has been set. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: make .SUFFIXES bug?
Hello Simon, > > .SUFFIXES: > > .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf > .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp > > What is the value of EXEEXT at this point? You are right, the example is not as small as it could be for reproducing the issue. These lines are just extracted from groff's makefile. The issue does still occur if .test$(EXEEXT) is removed. Regards, Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Keyboard language not set before decrypting devices?
Hello, I have encrypted /home and want to decrypt it at boot time with 'geli_devices="da2"' in /etc/rc.conf but the passphrase is not accepted. Is it possible that the keymap is set *after* the decrypting of filesystems? Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make .SUFFIXES bug?
Hello, current groff doesn't build on FreeBSD. I had noticed the same issue some months ago on NetBSD and cross checked on FreeBSD and it had worked on FreeBSD. There must have somethig changed since then. How to reproduce: When there is a file "test.1.man" and a makefile: .SUFFIXES: .SUFFIXES: .roff .in .ps .mom .pdf .me .ms .ps .html .txt .texi .dvi .pdf .xhtml .man .c .cpp .log .o .obj .sed .sin .test .test$(EXEEXT) .trs .ypp .man: @echo Making $@ from $< rm -f $@ @LC_ALL=C \ sed -e "s|foo|bar|g" \ $< >$@ "make test.1" results in "make: don't know how to make test.1. Stop". When ".man" is put to the start of the list it works. It also works when the first .SUFFIXES line is removed. The answer from NetBSD is that this is very likely a bug in make. May this also be the case for FreeBSD? Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: No X on Dell E6540
Hello Michael, > It looks like that is a machine with Haswell integrated graphics. > Haswell graphics has not yet landed in CURRENT but there is a > development branch availible for testing. > > https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20L > inux%203.8 there is also an additional AMD graphics card in this laptop (AMD Radeon HD 8790M). Is this supported by CURRENT? Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: No X on Dell E6540
Hello David, > I had a similar issue with my Dell M4800 until I entered BIOS > configuration (vi F12 key at boot), selected "Video," then disabled > "Switchable Graphics." this option is unfortunately not available in "Video" (only display brightness can be set there in my BIOS). Regards, Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
No X on Dell E6540
Hello, X does not start. For the error message I get (Number of created screens does not match number of detected devices) there are many posts on https://forums.freebsd.org but this URL seems to not work currently. Xorg log is (for dmesg see below): [ 369.089] X.Org X Server 1.17.4 Release Date: 2015-10-28 [ 369.089] X Protocol Version 11, Revision 0 [ 369.089] Build Operating System: FreeBSD 11.0-CURRENT amd64 [ 369.089] Current Operating System: FreeBSD pcdd146.dmosdesign.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r291495: Mon Nov 30 23:14:34 UTC 2015 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 [ 369.090] Build Date: 12 December 2015 01:25:52PM [ 369.090] [ 369.090] Current version of pixman: 0.32.8 [ 369.090]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 369.090] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 369.091] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Dec 14 17:02:05 2015 [ 369.091] (II) Loader magic: 0x80a070 [ 369.091] (II) Module ABI versions: [ 369.091]X.Org ANSI C Emulation: 0.4 [ 369.091]X.Org Video Driver: 19.0 [ 369.091]X.Org XInput driver : 21.0 [ 369.091]X.Org Server Extension : 9.0 [ 369.091] (!!) More than one possible primary device found [ 369.091] (--) PCI: (0:0:2:0) 8086:0416:1028:05be rev 6, Mem @ 0xf580/4194304, 0xd000/268435456, I/O @ 0xf000/64, BIOS @ 0x/65536 [ 369.091] (--) PCI: (0:1:0:0) 1002:6606:1028:05be rev 0, Mem @ 0xe000/268435456, 0xf7c0/262144, I/O @ 0xe000/256, BIOS @ 0x/65536 [ 369.092] List of video drivers: [ 369.092]nv [ 369.092]mach64 [ 369.092]intel [ 369.092]ati [ 369.092]radeon [ 369.092]openchrome [ 369.092]r128 [ 369.092]vesa [ 369.092]modesetting [ 369.092] (II) LoadModule: "nv" [ 369.093] (II) Loading /usr/local/lib/xorg/modules/drivers/nv_drv.so [ 369.093] (II) Module nv: vendor="X.Org Foundation" [ 369.093]compiled for 1.17.4, module version = 2.1.20 [ 369.093]Module class: X.Org Video Driver [ 369.093]ABI class: X.Org Video Driver, version 19.0 [ 369.093] (II) LoadModule: "mach64" [ 369.094] (II) Loading /usr/local/lib/xorg/modules/drivers/mach64_drv.so [ 369.094] (II) Module mach64: vendor="X.Org Foundation" [ 369.094]compiled for 1.17.4, module version = 6.9.5 [ 369.094]Module class: X.Org Video Driver [ 369.094]ABI class: X.Org Video Driver, version 19.0 [ 369.094] (II) LoadModule: "intel" [ 369.094] (II) Loading /usr/local/lib/xorg/modules/drivers/intel_drv.so [ 369.095] (II) Module intel: vendor="X.Org Foundation" [ 369.095]compiled for 1.17.4, module version = 2.21.15 [ 369.095]Module class: X.Org Video Driver [ 369.095]ABI class: X.Org Video Driver, version 19.0 [ 369.095] (II) LoadModule: "ati" [ 369.096] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so [ 369.096] (II) Module ati: vendor="X.Org Foundation" [ 369.096]compiled for 1.17.4, module version = 7.5.0 [ 369.096]Module class: X.Org Video Driver [ 369.096]ABI class: X.Org Video Driver, version 19.0 [ 369.096] (II) LoadModule: "radeon" [ 369.096] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so [ 369.097] (II) Module radeon: vendor="X.Org Foundation" [ 369.097]compiled for 1.17.4, module version = 7.5.0 [ 369.097]Module class: X.Org Video Driver [ 369.097]ABI class: X.Org Video Driver, version 19.0 [ 369.097] (II) LoadModule: "openchrome" [ 369.097] (II) Loading /usr/local/lib/xorg/modules/drivers/openchrome_drv.so [ 369.097] (II) Module openchrome: vendor="http://openchrome.org/"; [ 369.098]compiled for 1.17.4, module version = 0.3.3 [ 369.098]Module class: X.Org Video Driver [ 369.098]ABI class: X.Org Video Driver, version 19.0 [ 369.098] (II) LoadModule: "r128" [ 369.098] (II) Loading /usr/local/lib/xorg/modules/drivers/r128_drv.so [ 369.098] (II) Module r128: vendor="X.Org Foundation" [ 369.098]compiled for 1.17.4, module version = 6.10.0 [ 369.098]Module class: X.Org Video Driver [ 369.098]ABI class: X.Org Video Driver, version 19.0 [ 369.098] (II) LoadModule: "vesa" [ 369.099] (II) Loading /usr/local/lib/xorg/modules/drivers/vesa_drv.so [ 369.099] (II) Module vesa: vendor="X.Org Foundation" [ 369.099]compiled for 1.17.4, module version = 2.3.4 [ 369.099]Module class: X.Org Video Driver [ 369.099]ABI class: X.Org Video Driver, version 19.0 [ 369.099] (II) LoadModule: "modesetting" [ 369.099] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so [ 369.099] (II) Module modesetting: vendor="X.Org Foundation" [ 369.099]compiled for 1.1
[Solved] Partitioning on a MBR table disk fails
Hi Rick, thank you for your help! Using gpart in the shell did work well :) Regards, Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)
Rick Macklem wrote: > I don`t use it, but gpart is the preferred FreeBSD command. You might try > that instead. Does it work with MBR or only GPT? Anyway, I'll try it. > Well, although installing is always a bit scary, if you don`t touch the > other > slices, I`d delete and create the freebsd one. It gets to a certain point > when > doing the `Manual MBR` before it asks you if you want to save it on disk. At least creating by the (curses) GUI installer is not possible. It does create somewhere instead of asking me and it doesn't even tell me where it has created it. And there are numeric bugs in the tool. The numbers it displayed changed without reason and became even negative ... So the MBR I don't touch with FreeBSD anymore ... A simple task for the installer developer: Please let me use an existing empty slice. This is no rocket sience. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: Partitioning on a MBR table disk fails (and destroys my data...)
Rick Macklem wrote: > Did you use "Manual" when it gets to the partitioning screen? > When I've done this, after selecting "Manual MBR" (or whatever it's called, > one or two below "Auto"), it should show you the slices > (what FreeBSD calls the 4 MBR partitions): > - Then I select the "freebsd" (move around until it is highlighted one) > and create partitions within it with "Create" at the bottom of the > screen. > (I always have "fun" with the interface, but repeated attempts with >and the arrow keys eventually get me to the right place on the screen;-) I think I did select "auto" which brings me into the "manual" screen after few steps. It does show the slices and does even show NTFS and Linux partitions inside the extended partition (I have 3 primary MBR partitions, first is freebsd, then two NTFS, then an extendet with further NTFS and Linux). The first 10MB of the first slice (freebsd) had been cleared with "dd if=/dev/zero of=...". When I put the cursor line on this slice and select "create" it doesn't allow me to create the freebsd-ufs for "/". > Good luck with it, rick > ps: If it doesn't show the slices,I'm guessing the MBR doesn't make sense > to > FreeBSD's fdisk. You can go to "" instead of "" and > then > try typing "fdisk". I did try the shell and typed "fdisk" and "disklabel" but this did not work as known from other BSDs. The actually issue is that I can't create something in the found freebsd slice. In the past I did simply remove this slice and added a new one (since the free space on the disk had exactly been what I wanted to use). But now the seemingly free space is not actually completely free so I'd like to not delete the slice. The installer should support using this slice. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Partitioning on a MBR table disk fails (and destroys my data...)
Hello, how is it possible to install FreeBSD in an existing empty MBR partition with type "freebsd"? The installer does not allow this (for unknown reason), it returns the error "no space left". What steps would be necessary to add two freebsd-ufs and one freebsd-swap into the existing freebsd partition? In no case I want to delete this partition since I do *not* want FreeBSD to edit the MBR (to not have data loss again). There is unfortunately not much information in the handbook "2.6.5. Shell Mode Partitioning" (anyway I'd prefer to use the curses UI partition editor). Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Partitioning on a MBR table disk fails (and destroys my data...)
Hello, I had not been succesful in partitioning and MBR disk for FreeBSD. I have only one free primary partition where I had installed NetBSD and OpenBSD alternatively since many years. The free space on the disk is divided into three parts: one for NetBSD, one for OpenBSD and one left for FreeBSD. When I did change from one BSD to the other I edited the MBR (start sector, end sector and type a6/a9). Before now installing FreeBSD for the first time (did use qemu in the past) I adjusted the sectorss to the FreeBSD range and changed to type a5, then erased the first sectors of that partition. While NetBSD and OpenBSD autoselect their a9/a6 partitions, FreeBSD sees it's partition but doesn't allow to add BSD partitions for e.g. / or swap (no space left...). So I deleted the prepared partition and added a new one. The size the tool told me was too large (sum of free space on the disk) but after it was added a different size had been shown--that which I had reserved for FreeBSD (so there is a bug in the install tool). After installation I saw that it had overwritten the over BSDs data. 1) Why does FreeBSD not simply use the free partitoin that I had prepared for it? It had detected that it is erased, why just doesn't it allow to add / and swap? 2) Why doesn't FreeBSD doesn't show where (on which sector) it adds a new partition? This and the loss of my data is really disappointing. At the moment installing FreeBSD is impossible at my disk while the over BSDs did work out of the box. Carsten ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Aw: Re: [RFC] Replace gnu groff in base by heirloom doctools
Steffen Nurpmeso wrote: > It seems you haven't checked at all. > It seems to me that e.g. mdoc(7) of n-t-r seems to require quite > a bit of work in order to be at all usable. This is not completely true. It is usable, I did check it with all about 7000 manpages in the base of OpenBSD. But it does indeed also require further work. Please note that FreeBSD uses mandoc(1) for formatting manpages. Groff in the base (or a replacement) is only a fallback. > The macros i use for myself don't work with n-t-r, too: once > i truly looked (a few months ago) i found that i would have to > rewrite all traps and other positioning in order to get that > right. Please make a bug report ;) > Despite that you seem to do what you want to do anyway, n-t-r is > possibly a usable troff, if you go its way and deal with it you > may be able to gain a bit nicer output _faster_ and without > converting your beloved special fonts first, but in no way is > n-t-r a _replacement_ for groff. The groff version in the base is quite old and is there to have a *roff toolchain in the base and as a fallback solution for mandoc(1). If one does serious typesetting (and wants to use groff) it is recommended to use the up-to-date version from ports. Carsten ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"