Re: recovering data from a RAID1 array from a single disk on a different system
On 28 Jul 2011, at 21:13, Lee Whalen wrote:
I'm no expert, but I'll add my insights regardless ;)
1. Using CCD or one of the other utilities, I need to add this USB-caged
disk into a temporary RAID-1 array in a 'degraded' state so FreeBSD sees
As far as I know, CCD (concatenated disk) can not do mirroring, so your RAID-1
disk won't be created using CCD.
the disklabels as something other than type raid. This will allow me
to mount the preexisting partitions as normal, and copy the data off the
disk. If there's some way I can positively identify a given
partition/slice as having been created by either ccd/geom/vinum, that
would be awesome.
According to the man page, descriptions of the various fs_type's are in
/usr/include/sys/disklabel.h, and indeed:
...
#define FS_RAID 15 /* RAIDFrame drive */
...
static const char *fstypenames[] = {
...
raid,
...
};
So, apparently your disk contains a RAIDFrame drive. I never heard of that
before, but apparently it's something that's part of NetBSD:
http://www.netbsd.org/docs/guide/en/chap-rf.html
So my guess is that the NAS device contained NetBSD instead of FreeBSD.
Alban Hertroys
--
The scale of a problem often equals the size of an ego.
!DSPAM:909,4e32752b12094789815349!
___
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
Re: [head tinderbox] failure on amd64/amd64
Guys, what's with the Tinderbox failures every 18 minutes? Could it be a little less frequent please? My mailboxes are overflowing... On 2 Feb 2011, at 1:12, FreeBSD Tinderbox wrote: TB --- 2011-02-02 00:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-02 00:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-02-02 00:10:00 - cleaning the object tree TB --- 2011-02-02 00:10:00 - cvsupping the source tree TB --- 2011-02-02 00:10:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-02-02 00:10:13 - building world TB --- 2011-02-02 00:10:13 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-02 00:10:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-02 00:10:13 - TARGET=amd64 TB --- 2011-02-02 00:10:13 - TARGET_ARCH=amd64 TB --- 2011-02-02 00:10:13 - TZ=UTC TB --- 2011-02-02 00:10:13 - __MAKE_CONF=/dev/null TB --- 2011-02-02 00:10:13 - cd /src TB --- 2011-02-02 00:10:13 - /usr/bin/make -B buildworld World build started on Wed Feb 2 00:10:13 UTC 2011 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools [...] cc -O2 -pipe -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wno-unknown-pragmas -I/obj/src/tmp/legacy/usr/include -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common/list.c cc -O2 -pipe -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wno-unknown-pragmas -I/obj/src/tmp/legacy/usr/include -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common/memory.c cc -O2 -pipe -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -std=gnu89 -Wno-unknown-pragmas -I/obj/src/tmp/legacy/usr/include -c /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c In file included from /src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common/sys/ctf.h:34, from /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common/ctf_headers.h:68, from /src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/merge.c:119: /src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris/sys/types.h:38: error: conflicting types for 'clock_t' /usr/include/time.h:64: error: previous declaration of 'clock_t' was here *** Error code 1 Stop in /src/cddl/usr.bin/ctfconvert. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-02 00:12:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-02 00:12:41 - ERROR: failed to build world TB --- 2011-02-02 00:12:41 - 136.71 user 17.25 system 160.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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 Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4d48a23b11731425515335
GPT on amd64 and boot managers
Good day, Yesterday I finally changed my FreeBSD disk to use GPT instead of a traditional MBR, but I hadn't realised that the FreeBSD boot manager doesn't understand GPT partitions (my CURRENT is from early January, if that matters). I used to have that disk set up in the BIOS as the preferred boot disk and the boot manager on it allowed me to boot one of the other disks containing Windows 7 [1]. I googled around and noticed that other people with this problem were told to use Grub as a boot manager, but trying to install that from ports I found out that Grub is only for x86, while I run amd64. So in short, I can't use the FreeBSD boot manager as I have my disk partitioned with GPT, and I can't use Grub as it's not compatible with amd64, yet I do want a boot manager. How do I solve this? Currently I have to choose which OS to boot by changing the boot sequence of my disks in the BIOS - not very convenient. [1] I didn't put a boot manager on the Windows disk on purpose, as Microsoft overwrites it with every reinstall anyway. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4bfe323010414002918410! ___ 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
Re: GPT on amd64 and boot managers
On 27 May 2010, at 12:02, Michael Reifenberger wrote: On Thu, 27 May 2010, Alban Hertroys wrote: Good day, Yesterday I finally changed my FreeBSD disk to use GPT instead of a traditional MBR, but I hadn't realised that the FreeBSD boot manager doesn't understand GPT partitions (my CURRENT is from early January, if that matters). I used to have that disk set up in the BIOS as the preferred boot disk and the boot manager on it allowed me to boot one of the other disks containing Windows 7 [1]. FreeBSD boots just fine from GPT. See the examples section of gpart(8). You appear to have missed the point; I was talking about the boot manager - the thing that lets you choose which OS to boot, not the boot loader. I can boot FreeBSD just fine off GPT, but I have to select in the BIOS whether I want to boot FreeBSD or Windows (by means of changing the boot sequence). A working boot manager would be so much more convenient for that. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4bfe4fa210412299192489! ___ 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
Re: GPT on amd64 and boot managers
On 05/27/10 13:33, Andriy Gapon wrote: on 27/05/2010 13:55 Alban Hertroys said the following: I can boot FreeBSD just fine off GPT, but I have to select in the BIOS whether I want to boot FreeBSD or Windows (by means of changing the boot sequence). A working boot manager would be so much more convenient for that. Right. OTOH I have standard GPT installation (pmbr + gptzfsboot) and during boot I am presented with a choice which _hard disk_ to boot from. I didn't do anything special for that. Not exactly a boot manager, but OK for me. I'd be quite happy to have something like that, do you have any idea what's doing that for you? I suspect it is your BIOS, as I don't get that choice and AFAIK I also have a standard GPT installation - I literally followed the examples in man gpart up to the point where freebsd-ufs partitions are added. This is my partition layout: dalroi:bommel gpart show ada0 = 34 625142381 ada0 GPT (298G) 34128 1 freebsd-boot (64K) 1622097152 2 freebsd-ufs (1.0G) 2097314 16777216 3 freebsd-swap (8.0G) 188745301024000 4 freebsd-ufs (500M) 198985302097152 5 freebsd-ufs (1.0G) 21995682 41943040 6 freebsd-ufs (20G) 63938722 561203693 7 freebsd-ufs (268G) !DSPAM:930,4bffa1c910415538290380! ___ 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
hid_get_item: Number of items truncated to 255
Hello, I see this message a couple of times in my dmesg every time I boot and I'm wondering from which device these messages originate and whether they might be harmful in some way? They don't seem to cause any trouble, but it's probably better if they weren't there. Below are the relevant section of my dmesg and the output of usbconfig: ugen5.4: Logitech at usbus5 ums0: Logitech Trackball, class 0/0, rev 1.10/2.20, addr 4 on usbus5 ums0: 3 buttons and [XYZ] coordinates ID=0 Root mount waiting for: usbus5 Root mount waiting for: usbus5 ugen5.5: vendor 0x05ac at usbus5 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 uhid1: vendor 0x05ac product 0x9223, class 0/0, rev 1.10/1.14, addr 5 on usbus5 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 hid_get_item: Number of items truncated to 255 ugen5.6: Microsoft at usbus5 ukbd0: Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 6 on usbus5 kbd2 at ukbd0 uhid2: Microsoft Natural Ergonomic Keyboard 4000, class 0/0, rev 2.00/1.73, addr 6 on usbus5 ugen0.1: OHCI root HUB ATI at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: OHCI root HUB ATI at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: OHCI root HUB ATI at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: OHCI root HUB ATI at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: OHCI root HUB ATI at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: EHCI root HUB ATI at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: Saitek R220 Saitek at usbus1, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen5.2: product 0x6560 vendor 0x04b4 at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen5.3: product 0x9131 vendor 0x05ac at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen5.4: Trackball Logitech at usbus5, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen5.5: product 0x9223 vendor 0x05ac at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.6: Natural Ergonomic Keyboard 4000 Microsoft at usbus5, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON I found that vendor 0x05ac is Apple Computer Inc and therefore I suspect the device that's causing these errors could be the brightness control in my Apple Cinema display. The first of below devices is probably the USB-hub in the display and the second the brightness control, but it could be the other way around. ugen5.3: product 0x9131 vendor 0x05ac at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen5.5: product 0x9223 vendor 0x05ac at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON The other unrecognised device, in case someone wants to add it somewhere: ugen5.2: product 0x6560 vendor 0x04b4 at usbus5, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE This is a Belkin n52te game-controller (http://www.belkin.com/IWCatProductPage.process?Product_Id=390404) !DSPAM:930,4bffa90810411104319959! ___ 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
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 31 May 2010, at 11:56, Kostik Belousov wrote: My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. True enough, but that coin has two sides. Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang, but if you have multiple compilers at your disposal you can determine that you're probably looking at a compiler bug instead of a FreeBSD bug. Especially once there are users running the same code compiled with gcc and with clang it should be /easier/ to determine whether it's a compiler bug or not. Seeing a Y doesn't work for me compiled with clang vs. Y works for me compiled with gcc or vice versa would mean that the problem is likely in one of the compilers. Now you're probably correct in saying that the number of compiler bugs you are likely to encounter /now/ would be higher in clang than in gcc, but there also have been a number of cases where clang found bugs in code that gcc didn't find. Whether you find that useful is up to you, you are the developers after all. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4c04de8b10155455914109! ___ 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
Re: using cupsd instead of base lpr [was Re: [HEADS UP] Kernel modules don't work properly in FreeBSD 8.1-RC1 (solved)]
On 24 Jun 2010, at 9:23, Gary Jennejohn wrote: On Wed, 23 Jun 2010 18:15:09 -0700 Ted Faber fa...@isi.edu wrote: (/usr/local/bin/ preceeds /usr/bin in my path so I can use the lpr commands from cupsd, though it's evidently a bit of a dangerous idea.) [trimmed Cc] I use cupsd and have these settings to get around using the base system lp stuff: in /etc/src.conf - WITHOUT_LPR=yes and these symbolic links in /usr/bin lrwxr-xr-x 1 root wheel 17 Mar 18 2009 /usr/bin/lp - /usr/local/bin/lp lrwxr-xr-x 1 root wheel 24 Mar 18 2009 /usr/bin/lpoptions - /usr/local/bin/lpoptions lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpq - /usr/local/bin/lpq lrwxr-xr-x 1 root wheel 18 Mar 18 2009 /usr/bin/lpr - /usr/local/bin/lpr lrwxr-xr-x 1 root wheel 19 Mar 18 2009 /usr/bin/lprm - /usr/local/bin/lprm lrwxr-xr-x 1 root wheel 21 Mar 18 2009 /usr/bin/lpstat - /usr/local/bin/lpstat and /usr/bin is _before_ /usr/local/bin in my PATH. Wouldn't it be easier to alias those commands instead of physically replacing them? In my .tcshrc I have: alias lp/usr/local/bin/lp alias lpq /usr/local/bin/lpq alias lpr /usr/local/bin/lpr alias lprm /usr/local/bin/lprm I only have /usr/local/bin/lpoptions on my system (7-STABLE), so I guess that's exclusive to CUPS, hence no need for me to alias it. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:909,4c2317ad286211131610927! ___ 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
Is 802.11p supported?
Hello all, On behalf of a friend I have an inquiry whether FreeBSD supports the wireless 802.11p protocol? More specifically, is it supported on Atheros 5k cards? I realise 5k is a bit generic, I don't have any more details than that (yet) though. He is actually looking for a Linux driver, so I'm not sure knowing that there's a FreeBSD driver (if there is one) would help him at all, but it would be a good opportunity to make him sway to the light side ;) Regards, Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4c48301f286215329633792! ___ 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
Re: Official request: Please make GNU grep the default
On 15 Aug 2010, at 3:12, Doug Barton wrote: (And before anyone bothers to reply saying Use pkg_info -O for that I'll save you the trouble. My version is from 10-20% faster. Not sure why, don't really care.) :) Congrats for beating the performance of a(nother) utility in base, but - regardless of whether you'd use it in that case - doesn't that just indicate that pkg_info could use some performance improvements as well? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:930,4c67abaf967636193329187! ___ 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
Re: calcru: runtime went backwards
On 30 Oct 2010, at 21:19, David Rhodus wrote: I haven't seen much of this since 5.x days. Anyone else see calcru messages lately ? I had a bunch of those in my daily-mail this morning as well. I assumed it was due to the DST change last night: Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 11993 usec to 9596 usec for pid 34369 (local) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 13584 usec to 10869 usec for pid 34368 (smtpd) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 11459 usec to 9169 usec for pid 34367 (lmtp) Oct 31 00:12:58 solfertje kernel: calcru: runtime went backwards from 13430 usec to 10746 usec for pid 34366 (cleanup) That system isn't running HEAD btw, it runs FreeBSD 7.2-STABLE (upgrade planned). Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:930,4ccd4aa810263770721941! ___ 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
Re: [HEADSUP] pkg(8) is now the only package management tool
On 2 September 2014 11:08, Julian Elischer jul...@freebsd.org wrote: On 9/1/14, 8:03 PM, Andrew Berg wrote: On 2014.09.01 21:39, Julian Elischer wrote: sigh.. when are we as a project, all going to learn that reality in business is that you often need to install stuff that is old. Its not always your choice. The custommers require it.. You should try arguing with someone like Bank of Americas security and operations department some day about whether they want to suddenly upgrade 300 machines for no real reason (from their perspective). FreeBSD minor version upgrades are meant to be non-disruptive. However, I will admit that I have not performed any such upgrades in a critical environment, so if you think they are disruptive, please enlighten me with the details. Also, there are options out there for getting support for extended periods if you need it. Some companies are built around providing support for things that the original developers have long abandoned because some businesses need it. It's not how disruptive they are technically. it's how many months of shakedown testing you have to go through before they allow you to put new software on any production system. Just adding here, in commercial environments things don't change quickly or easily. Whether this applies to the current issue with pkg is not for me to say. For example, certain commercial upstream software vendors require to go through a certification process before they even consider supporting the new software you intend to use with theirs. Admittedly we haven't run into this issue in relation to FreeBSD, but we certainly have with Firefox. As an example, the last version of Firefox that Information Builders' WebFOCUS 7.7 supports is 3.6.7 (currently available versions are 31 or 32!) and for Internet Explorer that's 7 (currently at 11). If you run into any kind of problem, the standard answer is to use a browser that they support. Good luck with that! Firefox 3.6.7 was released on July 20, 2010; over 4 years ago. In such cases you're more or less required to keep an old system around that still has such old packages, if only to see if you can reproduce any issues you encounter (with modern versions of your software) on those old versions. With the deprecation of the old pkg_* tools you run into a conflict; You can either update packages that are _not_ under certification for such a vendor and get security updates and fixes using the new pkg, or you have to stick with the certified software and _not_ get any security updates or fixes. It gets more interesting if you have to deal with manufacturing processes (something we're looking to use FreeBSD for to replace our current OpenVMS systems before they go out of support), as often automatons write data to external databases and such software resides in PLC's. Manufacturing equipment tends to age and the kind of external databases they support is limited to what was available when they were new and the capabilities of the PLC involved. I can totally understand that at some point it starts to get impossible to maintain two separate packaging systems and I understand that you think 2 years is enough time to shake things out, but software vendors aren't that quick. For many, 2 years is a short time. Just saying... -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ 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
KLD zfs.ko: depends on kernel - not available or version mismatch
This seems to have gotten lost in the moderate queue, but after a week I am no closer to a solution, so here’s a resend: I’ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko. I updated to the latest current using svn up in /usr/src, then: make clean make buildworld kernel -j12 shutdown -r now boot to single user mode kldload zfs Which results in dmesg messages: KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type I can load the zfs kernel module from kernel.old just fine: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) This happens with any kernel module I’ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW). I’ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail. I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help. Do I need to go back further to get into a usable state or is there something else I should be doing? Regards, Alban Hertroys -- There is always an exception to always. ___ 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: KLD zfs.ko: depends on kernel - not available or version mismatch
> On 8 Dec 2020, at 16:40, John Kennedy wrote: > > On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote: >> This seems to have gotten lost in the moderate queue, but after a week I am >> no closer to a solution, so here???s a resend: >> >> I???ve been trying to get a fresh world running (for the eventual purpose of >> running amdgpu against my recent graphics adapter), but I run into trouble >> with core loadable kernel modules, such as zfs.ko from the subject. It also >> happens with other modules that I tried randomly, for example, >> geom_mirror.ko. >> >> I updated to the latest current using svn up in /usr/src, then: >> make clean >> make buildworld kernel -j12 >> shutdown -r now >> >> boot to single user mode >> >> kldload zfs > > I'm not sure you've provided enough information for a one-shot armchair > diagnosis, but some things seem factually wrong. For example, my normal > rebuild procedure is: > > cd /usr/src && make buildworld && make buildkernel > make installkernel > shutdown -r now > > cd /usr/src && mergemaster -pi > make installworld > mergemaster -Fi > make -DBATCH_DELETE_OLD_FILES delete-old Aha! So that’s how to prevent having to press ‘y’ for every deprecated file! > shutdown -r now > > cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs > > (I'm on a desktop system here. You haven't described your setup.) This is also a desktop system. > You didn't say that you've installed the new kernel, which at least starts > you down the road towards a driver/kernel mismatch. You presumably have a > non-ZFS boot+root. I’m fairly sure I did, actually. Last time I checked, "make buildworld buildkernel" was equivalent to "make buildworld && make buildkernel", while "make kernel” is a shorthand for “make buildkernel && make installkernel” So, unless I’m mistaken, “make buildworld kernel” should be equivalent to your first two lines. Nevertheless, I retried without these assumptions, the result was the same. I forgot to “make delete-old” though, I rarely remember to do that… > Did you mess around with the ZFS from ports (ZoL -> ZoF) > at some point so you're not using the kernel's ZFS drivers? What ZFS > entries do you have in /etc/loader.conf, /etc/rc.conf, and some of the > varients that may get dragged in? (see rc.conf(5) for possibilities) Nope, stock modules here. > At the bottom of your email, you say / is UFS and /usr is ZFS, but I guess we > have the extra fun of wondering what is under /usr on your /? If you have a > pre-ZFS /usr that is populated by something now presumably very old (because > all the new, current stuff went onto ZFS /usr, now unavailable). There is no populated directory /usr on the UFS file-system. This install was created on a fresh NVME disk based on an existing install on a spinning platter. The install happened with /usr mounted at the ZFS file-system. I had to copy over several files from /etc and /usr/local/etc and re-installed the most important packages. This was admittedly a bit messy, it is possible that I forgot to copy something over. (Originally my intention was to dd the contents of the spinning disk over, but apparently that disk has a few wonky sectors, dd failed after a few device timeouts) I did sort-of manage to fix things, but recent kernels keep causing the same issue: I noticed that uname -a said I was at revision 366335, while I had the source tree up-to-date. For a test, I reverted back to that revision and went through: make buildworld make buildkernel Which broke on /usr/local/sys/drm-current-kmod, which I turned out to have installed through pkg. There have been changes to the linux_kpi shortly after above revision - probably what broke compatibility between HEAD and r366335. After removing that pkg, the kernel built and installed, world installed fine too and I have a working system again, with kernel and world in sync. So I tried again to move to HEAD: cd /usr/src svn up make buildworld -j12 make buildkernel -j12 make installkernel shutdown -r now mount -u / zpool import -Nf system (my /usr FS) KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type >> Which results in dmesg messages: >> >> KLD zfs.ko: depends on kernel - not available or version mismatch >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type >> KLD zfs.ko: depends on kernel - not available or version mismatch >> linker_load_file: /boot/kernel/zfs.ko - u
Re: KLD zfs.ko: depends on kernel - not available or version mismatch
> On 9 Dec 2020, at 3:48, John Kennedy wrote: > >> I had to copy over several files from /etc and /usr/local/etc and >> re-installed the most important packages. This was admittedly a bit messy, >> it is possible that I forgot to copy something over. >> (Originally my intention was to dd the contents of the spinning disk over, >> but apparently that disk has a few wonky sectors, dd failed after a few >> device timeouts) > > ... so, no guarantee that things are totally sane. > > The "sane" we're looking for is how you can presumably be booting a kernel > located at /boot/kernel/kernel and not have it match the kernel modules > found under /boot/kernel. (...) > What I have built in my source tree is the kernel/zfs module I'd expect: > > # md5 -r /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel > /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko > /boot/kernel/kernel /boot/kernel/zfs.ko | sort > 941ab52d075e444da6eea7fb56213e10 /boot/kernel/kernel > 941ab52d075e444da6eea7fb56213e10 > /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel > 97d4e0c8ffed1f75e924bf8768a95ff1 /boot/kernel/zfs.ko > 97d4e0c8ffed1f75e924bf8768a95ff1 > /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko > > What are you seeing after your installkernel equivalent? It turns out that I was being fooled by the BIOS. Even though I selected the device that this kernel and modules were on as the device to boot from, the actual kernel was still coming from the old spinning disk! It would probably have taken me significantly longer to figure that out without your hints, as I was trying to solve the wrong problem. So thanks a lot for that. Having things to verify was a tremendous help. I used the opportunity to switch to EFI booting, which took me the better part of the evening, but that's working now and booting the correct kernel. It’s even booting into a 1280x720 resolution with the help of the drm-devel-kmod. The next challenge is getting Xorg to run on this Navi-10 GPU; so far I get stuck with "[KMS] drm report modesetting isn't supported”. > Your hashes won't match mine due to non-reproducible build. > > I'd make sure you don't have anything in /boot/modules or otherwise load any > extra modules until sanity is restored (just to reduce random variables). Ah yes, I wasn’t aware of /boot/modules. Last time I used CURRENT, modules were still in the kernel directory. Hence, that was also where I pointed kldload to to test my modules, which explains part of the confusion (and there’s no modules.old…). Alban Hertroys -- There is always an exception to always. ___ 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"
KLD zfs.ko: depends on kernel - not available or version mismatch
I’ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko. I updated to the latest current using svn up in /usr/src, then: make clean make buildworld kernel -j12 shutdown -r now boot to single user mode kldload zfs Which results in dmesg messages: KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type KLD zfs.ko: depends on kernel - not available or version mismatch linker_load_file: /boot/kernel/zfs.ko - unsupported file type I can load the zfs kernel module from kernel.old just fine: ZFS filesystem version: 5 ZFS storage pool version: features support (5000) This happens with any kernel module I’ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW). I’ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail. I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help. Do I need to go back further to get into a usable state or is there something else I should be doing? Regards, Alban Hertroys -- There is always an exception to always. ___ 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: [HEADSUP] making /bin/sh the default shell for root
> On 22 Sep 2021, at 10:36, Baptiste Daroussin wrote: > > Hello, > > TL;DR: this is not a proposal to deorbit csh from base!!! (…) > Recently our sh(1) has receive update to make it more user friendly in > interactive mode: > * command completion (thanks pstef@) > * improvement in the emacs mode, to make it behave by default like other > shells > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > * support for history as described by POSIX. > > This makes it a usable shell by default, which is why I would like to propose > to > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) My one concern is this: what is the impact of these usability improvements to sh on its usage in scripts? I can imagine that there is merit to having a separate shell that is optimised for scriptability and script performance and having a different shell for user interaction. It seems to me the former was a primary purpose of sh? How much “weight” did it gain in becoming more user friendly and how will that impact script performance? I’ve been using FreeBSD with some frequency since 2.2.5 or so, so I am used enough to getting csh as root shell to not be able to see the problem that this change is trying to solve. Call me biased. My purpose is just to throw in a different point of view here, I’m not a big sh script user myself (I think I wrote less than a dozen over the years), this is not something for me to judge. Alban Hertroys -- There is always an exception to always.
