Re: A tool for remapping bad sectors in CURRENT?
Eugeny N Dzhurinsky wrote: Hello, all! Recently I've started to see the following logs in messages: Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable (pending) sectors Mar 8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline uncorrectable sectors smartctl did really show that something is wrong with my HDD, but still no remaps - just read errors. SMART Self-test log structure revision number 1 Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offlineCompleted: read failure 60% 1198 222342559 # 2 Extended offlineCompleted: read failure 60% 1187 222342557 # 3 Extended offlineCompleted: read failure 60% 1180 222342559 # 4 Short offline Completed without error 00% 1178 - # 5 Extended offlineAborted by host 90% 1178 - and ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE ... Reallocated_Sector_Ct 0x0033 100 100 036Pre-fail Always - 0 ... Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I force remapping of these sectors? I assume that I have to write something directly to the sectors? We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term "block". It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Eugene Dzhurinsky wrote: On Mon, Mar 08, 2010 at 12:21:44PM +0100, Miroslav Lachman wrote: Eugeny N Dzhurinsky wrote: We have this problem from time to time on bunch of machines. As we are using gmirror, the easiest way is to force re-synchronization (rewrite) of the whole drive. The problem is when there are Pending unreadable sectors on both drives - it ends up with read error and some file(s) are corrupted, but there is no easy way (on FreeBSD) to find what file. I tried it in the past with fsdb / findblk, but it does not work as I expect or I do not fully understand the needed calculations with slices + partitions offsets / LBAs and right meaning of the term "block". It seems there are several meaning in different contexts. It would be nice if somebody with enough FS / GEOM knowledge can write some HowTo or shell script to do the calculations and operations to find file containing bad sector(s) and put it in FAQ, Handbook, or Wiki. Miroslav, thank you for the suggestion - but I am not using gmirror, that HDD is the one on my laptop. However suggestions about using dd to write something into bad block to force IDE controller do it's service stuff about remapping seems did the trick. And I was able to not calculate LBA but use it as block offset, which seemed to be correct way :) Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman<000.f...@quip.cz> writes: Yes, rewriting by dd or any other way works for reallocating or clearing pending sectors counter, but in server environment In a server environment, you'd be a fool not to have some sort of redundancy set up. I am using gmirror on low-end servers, so rewriting some sectors on one disk drive is useless and in this case I prefer resync of the whole gmirror (but it is log run - about 10 hours on busy server) I need to know the affected file, as it can be for example database file and then it is a big problem! Rewriting the sector inside InnoDB ib_data file can cause DB crash, data loss etc. How is that different from *not* rewriting the sector? If there's a bad sector somewhere in your data, your database is still going to crash. It is not about "different", it is about "I need to know the affected file" to know what actions should be taken. If it is some logfile, I can delete it and then rewrite the sector. If it is some "normal" unchanged file, I can restore it from backup, if it is database file, I must take some special action. For example, stop DB engine, try to repair/fix the DB file, dump & restore etc. So the first step is to find "what file is affected", then take some action AND rewrite the sector by dd to reallocate the sector. (or replace the drive) So... can somebody with enough knowledge write some docs / script how to find the affected file based on LBA read error from messages / SMART log? Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman<000.f...@quip.cz> writes: So... can somebody with enough knowledge write some docs / script how to find the affected file based on LBA read error from messages / SMART log? ZFS will tell you straight away, but I guess if you used ZFS, you wouldn't be asking :) Yes, but we have ZFS only on two servers, others are using UFS2 (some with gmirror, some with gjournal) For FFS, you can unmount the file system (boot from a CD or memory stick or whatever if that file system is / or /usr), run fsdb on the failing disk, use findblk to look up the inode number for the file that contains the bad sector. Note that you have to convert the LBA to an offset relative to the start of the partition. As I write in my first post to this thread, I already tried fsdb + findblk, but without success. Findblk did not returned any inode. Maybe the meaning of block is of different size or something else I can't understand. So can you please show me some real world example? I have one from the past: __ /var/log/messages: Sep 23 23:58:00 edith kernel: ad4: FAILURE - READ_DMA status=51 error=40 LBA=79725056 Sep 23 23:58:00 edith kernel: GEOM_MIRROR: Request failed (error=5). ad4[READ(offset=40819228672, length=131072)] __ SMART log: After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 6f 82 c0 44 Error: UNC at LBA = 0x04c0826f = 79725167 The LBA of bad sector is *79725167* __ Information about disk slices: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 209712447 (102398 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 209712510, size 1743807555 (851468 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63 __ According to LBA and size of s1, I thing the error is in s1 # /dev/mirror/gm0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20971520/ b: 25165824 2097152swap c: 2097124470 d: 12582912 27262976/var e: 146800640 39845888 /var/db f: 16777216 186646528 /usr g: 6288703 203423744 /tmp And LBA 79725056 is on */var/db* (between offset 39845888 and 186646528) __ s1 starts 63 sectors from the beginning of the drive and /var/db has offset 39845888. So am I right that I need to find block number *39879105* by findblk command? LBA err - s1 start - /var/db offset = findblk inside /dev/mirror/gm0s1e 79725056 - 63 - 39845888 = 39879105 __ /# fsdb -r /dev/mirror/gm0s1e ** /dev/mirror/gm0s1e (NO WRITE) Examining file system '/dev/mirror/gm0s1e' Last Mounted on /var/db current inode: directory I=2 MODE=40755 SIZE=512 BTIME=May 1 08:07:23 2009 [0 nsec] MTIME=Sep 24 15:52:01 2009 [0 nsec] CTIME=Sep 24 15:52:01 2009 [0 nsec] ATIME=Sep 24 16:24:34 2009 [0 nsec] OWNER=root GRP=wheel LINKCNT=11 FLAGS=0 BLKCNT=4 GEN=4ebc65fc findblk 39879105 findblk 39879106 findblk 39879107 findblk 39879108 . . I tried more than 256 incrementing block numbers, but findblk didn't found any inode! (length=131072 in error message means 256 sectors, right?) So there must be some misunderstanding on my part and that's why I am asking for some step-by-step documentation or script "how to find file by LBA read error message" I tried the fsdb + findblk on well known data, but again without success. I created file /tmp/test.txt, it has inum 3, than I use fsdb on gm0s1f (gm0s1f is mounted as /tmp). Command "inode 3" inside fsdb prompt returned informations about this file, command "blocks" returned 3001 as block number, but command "findblk 3001" returned nothing instead of inum 3! Where is the error? What I am doing wrong? __ ~/# echo test > /tmp/test.txt ~/# ls -i /tmp/test.txt 3 /tmp/test.txt ~/# fsdb -r /dev/mirror/gm0s1f ** /dev/mirror/gm0s1f (NO WRITE) Examining file system '/dev/mirror/gm0s1f' Last Mounted on /tmp current inode: directory I=2 MODE=41777 SIZE=512 BTIME=Feb 7 18:32:22 2008 [0 nsec] MTIME=Mar 14 10:33:22 2010 [0 nsec] CTIME=Mar 14 10:33:22 2010 [0 nsec] ATIME=Mar 14 10:33:35 2010 [0 nsec] OWNER=root GRP=wheel LINKCNT=7 FLAGS=0 BLKCNT=4 GEN=3f7c9384 fsdb (inum: 2)> inode 3 current inode: regular file I=3 MODE=100644 SIZE=5 BTIME=Mar 14 10:33:22 2010 [0 nsec] MTIME=Mar 14 10:33:22 2010 [0 nsec] CTIME=Mar 14 10:33:22 2010 [0 nsec] ATIME=Mar 14 10:33:22 2010 [0 nsec] OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=4 GEN=45c26de1 fsdb (inum: 3)> blocks Blocks for inode 3: Direct blocks: 3001 (1 frag) fsdb (inum: 3)> findblk 3001 fsd
Re: A tool for remapping bad sectors in CURRENT?
Gary Jennejohn wrote: On Sun, 14 Mar 2010 10:55:19 +0100 Miroslav Lachman<000.f...@quip.cz> wrote: [big snip] fsdb (inum: 3)> blocks Blocks for inode 3: Direct blocks: 3001 (1 frag) fsdb (inum: 3)> findblk 3001 fsdb (inum: 3)> findblk did not returned inode 3! This is almost guaranteed to be a file system block and not a disk block. Do you mean the number 3001? I am sorry for my ignorance, but it is not clear to me from fsdb manpage what "blocks" means FS block and what disk block. And how can I use (calculate with) this numbers? How can I get the right number to pass to findlbk command (in the example above) to give me back the inode 3? If FS block is 16384 bytes, then it means 16384/512 = 32 disk blocks per FS block. If 3001 is FS block, then it means 3001*32 = 96032 disk block number. Am I right? fsdb (inum: 3)> findblk 96032 fsdb (inum: 3)> Again - findblk did not returned inode 3. So what is the exact formula to get the right findblk number and then right inode number as result of findblk command? I am still lost in terms (words) and numbers :( Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman<000.f...@quip.cz> writes: The LBA of bad sector is *79725167* [...] s1 starts 63 sectors from the beginning of the drive and /var/db has offset 39845888. So am I right that I need to find block number *39879105* by findblk command? Uh, 79725167 - 63 = 79725104 and 79725104 - 39845888 = 39879216. How did you arrive at 39879105? I am sorry, it was my confusion. My calculation was for *LBA=79725056* reported in messages: ad4: FAILURE - READ_DMA status=51 error=40 LBA=79725056 79725056 - 63 - 39845888 = *39879105* Your calculation is for LBA reported by SMART log 40 51 00 6f 82 c0 44 Error: UNC at LBA = 0x04c0826f = *79725167* That's why I get different result ;) I must pay more attention to the numbers next time! It is interesting that there are two different LBAs for "same" error (appeared at the same time) Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Gary Jennejohn wrote: On Sun, 14 Mar 2010 17:18:45 +0100 Miroslav Lachman<000.f...@quip.cz> wrote: Gary Jennejohn wrote: On Sun, 14 Mar 2010 10:55:19 +0100 Miroslav Lachman<000.f...@quip.cz> wrote: [big snip] fsdb (inum: 3)> blocks Blocks for inode 3: Direct blocks: 3001 (1 frag) fsdb (inum: 3)> findblk 3001 fsdb (inum: 3)> findblk did not returned inode 3! This is almost guaranteed to be a file system block and not a disk block. Do you mean the number 3001? I am sorry for my ignorance, but it is not clear to me from fsdb manpage what "blocks" means FS block and what disk block. And how can I use (calculate with) this numbers? How can I get the right number to pass to findlbk command (in the example above) to give me back the inode 3? If FS block is 16384 bytes, then it means 16384/512 = 32 disk blocks per FS block. If 3001 is FS block, then it means 3001*32 = 96032 disk block number. Am I right? fsdb (inum: 3)> findblk 96032 fsdb (inum: 3)> Again - findblk did not returned inode 3. So what is the exact formula to get the right findblk number and then right inode number as result of findblk command? I am still lost in terms (words) and numbers :( Well, it's pretty hairy. Looking at findblk() it does this to go from disk block to file system block (this is greatly simplified) file_system_blockno = disk_blockno>> fs_fsbtodb; So conversely, you'd do disk_blockno = file_system_blockno<< fs_fsbtodb. You can get this information using "ffsinfo -l 0x001 -o some_file /dev/ataXY" (using ahci) and grep'ing for fsbtodb in some_file. The 0x001 means to only dump the first super block. I looked at a file system which has default 16kB file system blocks and fsbtodb is 2 ==> *multiply file_system_block by 4 not 32*. This is probably because it's a multiple of a 4kB block, which is the smallest usable file system block size AFAIK. BTW looking at the code leads me to conclude that fsdb will not print out anything if the disk block you're trying to find has bever been allocated to an inode ==> unused disk block, safe to overwrite. This assumes that you calculated the disk block correctly. I absolutely don't understand how you get the number 4 (it is some magic for me :]) but it works! fsdb (inum: 3)> blocks Blocks for inode 3: Direct blocks: 3001 (1 frag) 3001 * 4 = 12004 fsdb (inum: 3)> findblk 12004 12004: data block of inode 3 Thank you for this hint! Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman<000.f...@quip.cz> writes: Dag-Erling Smørgrav writes: Uh, 79725167 - 63 = 79725104 and 79725104 - 39845888 = 39879216. How did you arrive at 39879105? I am sorry, it was my confusion. My calculation was for *LBA=79725056* reported in messages: ad4: FAILURE - READ_DMA status=51 error=40 LBA=79725056 off-by-111... Are you sure 'smartctl -l error' reports only one error? There is really only one error. The example from my e-mail is half a year old, but the disk is running fine from this time. The error occured at the initial gmirror sync. No more errors shown after rewriting the disk with zeros. As you can see, there are really two different numbers LBA=79725056 in messages and LBA = 0x04c0826f = 79725167 in SMART log. r...@edith ~/# zcat /var/log/messages.3.bz2 | grep LBA Sep 23 23:58:00 edith kernel: ad4: FAILURE - READ_DMA status=51 error=40 LBA=79725056 - r...@edith ~/# smartctl -l error /dev/ad4 smartctl version 5.38 [amd64-portbld-freebsd7.2] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Error Log Version: 1 ATA Error Count: 1 CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 1 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 6f 82 c0 44 Error: UNC at LBA = 0x04c0826f = 79725167 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- c8 00 00 00 82 c0 44 00 25d+23:23:36.710 READ DMA c8 00 00 00 81 c0 44 00 25d+23:23:36.710 READ DMA c8 00 00 00 80 c0 44 00 25d+23:23:36.710 READ DMA c8 00 00 00 7f c0 44 00 25d+23:23:36.710 READ DMA c8 00 00 00 7e c0 44 00 25d+23:23:36.710 READ DMA Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Gary Jennejohn wrote: On Wed, 17 Mar 2010 12:41:33 +0100 Miroslav Lachman<000.f...@quip.cz> wrote: I absolutely don't understand how you get the number 4 (it is some magic for me :]) but it works! [...] Umm, it's standard C code: 1<< 2 = 4. It's a power of 2, in this case 2 squared. I am not a C programmer, so I didn't understand the syntax. Now it makes sense. Thank you again for the explanation. Miroslav Lachman ___ 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: A tool for remapping bad sectors in CURRENT?
Dag-Erling Smørgrav wrote: Miroslav Lachman<000.f...@quip.cz> writes: As you can see, there are really two different numbers LBA=79725056 in messages and LBA = 0x04c0826f = 79725167 in SMART log. I don't know how comfortable you are reading kernel code, but I would suggest looking through the atadisk driver to see why the numbers are different. And if you're comfortable *writing* kernel code, I would suggest implementing WORF in geom_mirror :) As I sent to Pieter, I am not a C programmer, so I cannot read kernel code. I was poor webdeveloper before I turned in to sysadmin about 5 years ago. My programming knowledge ends with PHP / SQL / JS and SH coding :) Miroslav Lachman ___ 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: Trivial PR, fix shutdown of rc services started with onestart
John Baldwin wrote: On Monday 12 April 2010 11:17:16 am Dominic Fandrey wrote: On 12/04/2010 16:53, John Baldwin wrote: [...] Considering that they are the responsible party, do they not get notified by GNATS whenever I submit a follow-up to the PR? Ah, in that case they probably do. Still, if they don't reply to the PR e- mail that list does seem to respond quickly to direct e-mails in my experience. :) I have bad experiences with freebsd-rc mailing list - no responses to my direct e-mails and no responses for PRs (PR sent more than year ago, direct e-mails 3 month ago without any reaction). I don't know who is responsible person for rc system and related PRs, but it seems there is not enough man power to check/take/commit/or close PRs related to rc. Miroslav Lachman ___ 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: Trivial PR, fix shutdown of rc services started with onestart
Doug Barton wrote: On 4/12/2010 9:45 AM, Miroslav Lachman wrote: I have bad experiences with freebsd-rc mailing list - no responses to my direct e-mails and no responses for PRs (PR sent more than year ago, direct e-mails 3 month ago without any reaction). I don't know who is responsible person for rc system and related PRs, but it seems there is not enough man power to check/take/commit/or close PRs related to rc. ... like everything else in a volunteer project. :) I personally try to comment on the 2 tails of the bell-shaped curve, things that look interesting, or things that I oppose. For everything else in the vast middle ground I generally wait to see if someone else expresses interest in it. If you are the only one person responsible for all rc stuff, then I understand that you cannot take each of them. I know you are hard working on other FreeBSD parts, so one person is not enough. :( Regarding your 2 open PRs, the first is a jail thing, and I have no experience with jails and don't feel competent to comment. I directly asked BZ with jail related PR if he can take it or close it with some denying comment, but again without reply. It is not good that there are old PRs without any response. It tends to duplicate PRs etc. Your cpu affinity patch looks interesting, but not enough to take my attention away from the 34 other things that are currently in my queue. As I wrote above, I understand that one person cannot do it all. There are other persons with similar patches to bring some new features in to rc.subr http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001816.html http://lists.freebsd.org/pipermail/freebsd-rc/2010-March/001877.html So, please don't take it personally. :) freebsd-rc@ is still the best place to start a discussion about rc.d-related stuff, but that doesn't mean that other forums can't be used as well. I tried to start some discussion about that things. I would like to learn more about FreeBSD rc stuff, but it is hard if nobody replied to my proposals / questions [1] / ideas. I also sent some proposal of iSCSI initiator rc script [2]. iSCSI initiator kernel module and userland binaries are in FreeBSD for a long time, but it is "useless" without rc scipt - again, without any response. I would like to write the script right and finish it to the commitable state, but it is hard without support of somebody skilled / without comments and discussion. [1] bgfsck vs. background-fsck http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001814.html [2] rc script for iSCSI initiator http://lists.freebsd.org/pipermail/freebsd-rc/2010-January/001841.html Miroslav Lachman ___ 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: HP, IBM and Supermicro Servers Compatibility.
Juanito Cassemiro wrote: Hi. I want to know if the IBM, HP or Supermicro Servers are compatible with FreeBSD OS. Could you send me a hardware compatibility list with compatible servers? It depends on server model, not on manufacturer in general. I have some IBM, HP, Supermicro and Sun servers in production. But it does not mean all IBM / HP / SM servers will work. You can see more on Hardware Notes http://www.freebsd.org/releases/7.3R/hardware.html http://www.freebsd.org/releases/8.0R/hardware.html Miroslav Lachman ___ 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: geom_sched usage
David Naylor wrote: On Monday 18 October 2010 21:51:25 Luigi Rizzo wrote: [...] - is there anyway to automatically attach gsched to a device on startup (i.e. in rc.conf)? no, you have to build some script yourself. Would there be any interest in having a rc.d/ script? I would find it conveniant to specify a single rc.conf line and get scheduling for all my devices. PC-BSD might find such functionality useful. See attached for my first draft at such a script, I'm willing to hash it into shape. [...] You can use `sysctl kern.disks` to find available disk devices in your rc script. Miroslav Lachman ___ 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: a few OptionalObsoleteFiles.inc improvements
Alexander Best wrote:
[...]
I'm glad to see that you're filling in some of the many missing bits
in this file.
yet another addition.
cheers.
alex
>
> .if ${MK_TCSH} == no
And what about usr/share/skel/dot.cshrc?
Miroslav Lachman
___
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: RFC regarding usage of ISO 8601 throughout the tree
Ulrich Spörlein wrote: On Wed, 05.01.2011 at 19:00:31 +0100, Julian H. Stacey wrote: Ulrich =?utf-8?B?U3DDtnJsZWlu?= wrote: !ACHTUNG BIKESHED ALERT! Hello, With the recent changes to the committer graphs, I again was reminded how much I hate the /MM/DD format (I can't help it ...). Given that I guess& hope you mean you like linear decreasing order but dislike '/' as a delimeter& want to swap from '/' to '-' as in ISO ? Exactly. this almost looks like ISO 8601, but is an unreadable variant of it, I would like to aggressively change this throughout the tree. I'd like to start with minor stuff like share/misc/*.dot. Then probably src/UPDATING, and ports/UPDATING after I've identified the consumers of these docs. Do you mean you would like to swap eg src/UPDATING 20100720 to eg 2010-07-20 ? That would be more readable. Yes, I think for lists of dates like in UPDATING or automatically generated date output like syslogd, the ISO8601 format only has advantages. I am using ISO8601 date + time format for years in my scripts, logs etc., so it would be nice to have it on all places of FreeBSD as a standard format. I think 2010-07-20 is really readable than 20100720 or 2010/07/20 and "2011-01-06 00:03:50" is better than "Jan 6 00:03:50" (in logs) +1 Miroslav Lachman ___ 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: setfacl Recursive Functionality
Shawn Webb wrote: I've just finished a patch to add recursive functionality to setfacl. Before I officially submit it, I'd like a few suggestions on how to improve the patch. The part I'm worried about involves the #define directive at top. I'm not sure what ramifications using that define might have. I needed it for my remove_invalid_inherit() function to work. Can it be extended to getfacl too? I am waiting for recursive functionality for a long time. It is available on linux and maybe some other OSes. Miroslav Lachman ___ 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: CFT: FreeBSD Package Base
David Chisnall wrote on 2019/04/30 10:22: On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. This sounds very much like local optimisation. It's now easy to create a custom base image. Great. But how do I express dependencies in ports on a specific base configuration? This is easy if I depend on a specific base package, but how does this work in your model? For example, if I have a package that depends on a library that is an optional part of the base system, how do I express that pkg needs to either refuse to install it, or install a userland pkg that includes that library in place of my existing version as part of the install process? More importantly for the container use case, if I want to take a completely empty jail and do pkg ins nginx (for example), what does the maintainer of the nginx port need to do to express the minimum set of the base system that needs to be installed to allow nginx to work? One of the goals for the pkg base concept was to allow this kind of use case, easily creating a minimal environment required to run a single service. With a monolithic base package set, you're going to need some mechanism other than packages to express the specific base subset package that you need and I think that you need to justify why this mechanism is better than using small individual packages. Will it not be maintainer's nightmare to take care of all the dependencies on the base packages for each port we have in the ports tree? Miroslav Lachman ___ 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: CFT: FreeBSD Package Base
Cy Schubert wrote on 2019/05/01 05:56: In message <292eadc6-3662-ec43-1175-53fc25248...@quip.cz>, Miroslav Lachman wri tes: David Chisnall wrote on 2019/04/30 10:22: On 29/04/2019 21:12, Joe Maloney wrote: With CFT version you chose to build, and package individual components such as sendmail with a port option. That does entirely solve the problem of being able to reinstall sendmail after the fact without a rebuild of the userland (base) port but perhaps base flavors could solve that problem assuming flavors could extend beyond python. This sounds very much like local optimisation. It's now easy to create a custom base image. Great. But how do I express dependencies in ports on a specific base configuration? This is easy if I depend on a specific base package, but how does this work in your model? For example, if I have a package that depends on a library that is an optional part of the base system, how do I express that pkg needs to either refuse to install it, or install a userland pkg that includes that library in place of my existing version as part of the install process? More importantly for the container use case, if I want to take a completely empty jail and do pkg ins nginx (for example), what does the maintainer of the nginx port need to do to express the minimum set of the base system that needs to be installed to allow nginx to work? One of the goals for the pkg base concept was to allow this kind of use case, easily creating a minimal environment required to run a single service. With a monolithic base package set, you're going to need some mechanism other than packages to express the specific base subset package that you need and I think that you need to justify why this mechanism is better than using small individual packages. Will it not be maintainer's nightmare to take care of all the dependencies on the base packages for each port we have in the ports tree? No more than it is today. Remember, people have been doing this sort of thing for decades. If the folks at Red Hat, Oracle (formerly Sun), and IBM can do it, I'm sure we can too. The dependency lists will be longer. We may require dependency lists that allow the choice of one of many prereqs or coreqs. They are experts and they are paid for their work. I am not. I am maintaining a few packages and the reality is I don't know what they need in base. Till these days I don't care about this kind of dependency. I am not system developer or programmer and I think there are more than just me who see this as a kind of problem. So in this case, pkg base gives me nothing but more work on those packages. Miroslav Lachman ___ 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: FreeBSD Core Team Response to Controversial Social Media Posts
FreeBSD Core Team Secretary wrote on 2019/05/10 03:24: The FreeBSD Core Team is aware of recent controversial statements made on social media by a FreeBSD developer. We, along with the Code of Conduct review committee, are investigating the matter and will decide what action to take. Both the Core Team and the FreeBSD Foundation would like to make it clear that views shared by individuals represent neither the Project nor the Foundation. This is incredibly stupid and I am really sad to read things like this in the mailinglist of my favourite operating system (again). What will be next? Checking if developers do not smoke weed, drink alcohol or have sex without condom? "Be well, John Spartan" What's wrong with this world? I am from the country where totalitarian regime ruled for 40 years. I was lucky to have seen freedom and lived freedom after the revolution many years ago but now I am afraid that we have Thought Police even in FreeBSD community. I never thought I'd live to fear again to speak freely. ___ 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: Inconsistent behavior with wpa / devd / network interfaces
Greg Rivers wrote on 2019/05/30 18:37: [...] Do I have something weird in my setup causing this? I don't recall ever having this issue when not using failover lagg. Running recent 13-CURRENT. I think there's a (unknown?) problem that makes lagg(4) incompatible with bridge(4). I've never been unable to make a lagg interface work as a member of a bridge. Lacking the time to pursue it, I've resorted to NATing instead. lagg and bridge can work together. I am running machine with FreeBSD 11.2 with 2 Intel NICs: em0 and em1 combined in to lagg0 lagg0 has 4 static IP addresses There is also bhyve VM on tap20, this VM has another 2 static IP addresses tap20 and lagg0 are members of the bridge. This bridge is renamed to "vm-public" vm-public: flags=8843 metric 0 mtu 1500 ether da:ae:ba:75:53:ce nd6 options=1 groups: bridge vm-switch viid-4c918@ id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap20 flags=143 ifmaxaddr 0 port 5 priority 128 path cost 200 member: lagg0 flags=143 ifmaxaddr 0 port 4 priority 128 path cost 200 Everything works without any problem. The only problem in the beginning was PF rules. I added rule to allow traffic to the VM IP addresses. Miroslav Lachman ___ 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: Statement regarding employment change and roles in the Project
Thank you for all your work on FreeBSD. Wish you luck in your new job. Kind regards Miroslav Lachman Glen Barber wrote on 2019/06/20 18:22: Dear FreeBSD community: As I have a highly-visible role within the community, I want to share some news. I have decided the time has come to move on from my role with the FreeBSD Foundation, this Friday being my last day. I have accepted a position within a prominent company that uses and produces products based on FreeBSD. My new employer has included provisions within my job description that allow me to continue supporting the FreeBSD Project in my current roles, including Release Engineering. There are no planned immediate changes with how this pertains to my roles within the Project and the various teams of which I am a member. FreeBSD 11.3 and 12.1 will continue as previously scheduled, with no impact as a result of this change. I want to thank everyone at the FreeBSD Foundation for providing the opportunity to serve the FreeBSD Project in my various roles, and their support for my decision. I look forward to continue supporting the FreeBSD Project in my various roles moving forward. ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
Ruslan Garipov wrote on 2019/11/25 15:06: Hello. I want to build kernel and world (of FreeBSD 13.0-CURRENT) on a fast virtual machine for other ones (all the virtual machines are hosted on VMware EXSi hypervisors, which have different physical CPUs). After `make -j16 buildworld` has finished successfully on the build machine, I get there, for example, /usr/obj/usr/src/amd64.amd64/tmp/legacy/bin/install program having the shlxq instruction (one from the BMI2 instruction set extensions). This eventually causes make installkernel and make installworld to fail with SIGILL on a virtual machine which must consume built world and kernel, and which is hosted on another ESXi instance, with older physical CPU (read: with CPU not implementing shlxq). The build machine (FreeBSD 13.0-CURRENT r354802) builds (x)install using the following commands (a part of buildworld): $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD -MF.depend.xinstall.o -MTxinstall.o -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c /usr/src/usr.bin/xinstall/xinstall.c -o xinstall.o $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -MD -MF.depend.getid.o -MTgetid.o -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -c /usr/src/contrib/mtree/getid.c -o getid.o $ cc -O2 -pipe -O2 -march=x86-64 -pipe -I/usr/src/contrib/mtree -I/usr/src/lib/libnetbsd -DHAVE_STRUCT_STAT_ST_FLAGS=1 -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include -static -L/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/lib -o xinstall xinstall.o getid.o -L/usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/libmd -lmd -legacy This produces xintstall with `shlxq`s: $ llvm-objdump --disassemble xinstall | grep -c shlxq 135 I believe statically linked /usr/lib/libmd.a is a stuff which brings `shlxq`s into the xinstall. I didn't examine it further, sorry... My question is: is it possible to buildworld without issuing instructions which are native for the host CPU? I have neither /etc/make.conf, nor /etc/src.conf on the build machine. Is it possible at all for FreeBSD CURRENT to be built outside a host and installed on the host later? Just as a reference: My build machine has Intel(R) Xeon(R) Gold 6150 CPU that supports BMI2: # cpucontrol -i 7 /dev/cpuctl0 cpuid level 0x7: 0x 0xd19f6ffb 0x0018 0xbc00 (Bit 08 in EBX is set) , and a consuming machine has Intel(R) Xeon(R) CPU E5-4617 CPU that doesn't support BMI2: # cpucontrol -i 7 /dev/cpuctl0 cpuid level 0x7: 0x 0x0002 0x 0xbc00 (Bit 08 in EBX is unset). Both machines install kernel and world without any problem, if they were built locally. I didn't tried this with current but I am using it with stable (11.3 at this time). Building on Xeon E3-1240v3 and installing on many different machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, some 10 years old Intel Pentium. So at least it worked in the past (11.3 amd64). Did you use this workflow in the past / did it work? I remember some issue in the past which was (accidentaly?) fixed by running "make buildworld && make builkernel && make installkernel && make installworld" on the build host (to some different DESTDIR) and then "make installkernel && make installworld" on the target host (build machine is shared via NFS) Miroslav Lachman ___ 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: buildworld on CPU-A, installworld on CPU-B ends up with SIGILL
Ruslan Garipov wrote on 2019/11/25 19:26: [...] I didn't tried this with current but I am using it with stable (11.3 at this time). Building on Xeon E3-1240v3 and installing on many different machines. Some of them are 10+ years old AMD Opteron, some Xeon E5649, some 10 years old Intel Pentium. So at least it worked in the past (11.3 amd64). Did you use this workflow in the past / did it work? No, unfortunately I didn't. Always built world/kernel on target host. I remember some issue in the past which was (accidentally?) fixed by running "make buildworld && make builkernel && make installkernel && make installworld" on the build host (to some different DESTDIR) and then "make installkernel && make installworld" on the target host (build machine is shared via NFS) Therefore, this trick somehow "fixes" /usr/obj shared on the build machine? I'll try this later. Thanks! Yes, I think so. But I am not a developer nor I know much about how build process works. Miroslav Lachman ___ 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: Broadwell Support FreeBSD 10.1
Brendan Inglese wrote on 03/23/2015 05:33: [...] If not for a while are discrete Nvidia cards such as the 760 ( Which another model has ) which I can find in http://www.gigabyte.com.au/products/product-page.aspx?pid=5156#ov stable? Last time I used X with a GTX680 it would crash twice a week. I am running PC-BSD 10.1.1 on Dell PowerEdge T20 (Haswell with E3-1225v3) with nVidia GT 630. It is running fine, no crashes at all. Miroslav Lachman ___ 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: RCTL and VIMAGE for 11.0-RELEASE
Mark Felder wrote on 08/24/2015 21:29: On Mon, Aug 24, 2015, at 14:18, Bjoern A. Zeeb wrote: On 24 Aug 2015, at 19:08 , Mark Felder wrote: What is preventing RCTL from being enabled right now? Any known/serious blockers? Its enabled in GENERIC. If RCTL is in GENERIC, can somebody look on to this problem with swapuse? https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/082019.html IMHO it shoul be fixed or better documented in man pages. Miroslav Lachman ___ 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: OpenSSH HPN
Mark Felder wrote on 11/10/2015 17:02: [...] But like I said: The code I found at openssh was so totally different that I did not continued this track, but chose to start running openssh from ports. Which does not generate warnings I have questions about the originating ip-nr. Are they still willing to accept changes to the old version that is currently in base? No, why would they do that? Exactly my question I guess I misinterpreted your suggestion on upstreaming patches. --WjW I honestly think everyone would be better served by porting blacklistd from NetBSD than trying to increase verbosity for log files. I didn't know blacklistd. It seems very interesting. It would be nice if somebody will port it to FreeBSD. Miroslav Lachman ___ 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: Need help fixing failing locale tests
John Marino wrote on 11/15/2015 15:47: On 11/15/2015 3:39 PM, Andrey Chernov wrote: As I already say, I don't want to insist on any particular point of view in such area as human behavior. I just say that it is POLA violation (even while it is upgrade) and we can let users decide by themselves, what it best for them (without me at least). I am starting to think "POLA" as an acronym is subject to abuse. By this definition, *any* change would "astonish" a user (picturing the most incompetent user impossible too). POLA is meant for unreasonable and unexplained changes. I don't think tidying up locales for the first time in a decade is unreasonable or unexplained. Let's not dilute "POLA". It's pretty good but you can apply it to anything. I agree. Everytime FreeBSD is changing something in the base, there are voices with "POLA". Removing Perl from base, removing BIND from base... these were more significant changes than changing something in locales. Miroslav Lachman ___ 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: Something in r291926 (and earlier) causes reboots during periodic daily (14 jails on system)
Alexander Leidinger wrote on 12/09/2015 09:00: Hi, with r291381 a system with 14 jails survives about 1-2 days. with r291926 this system survives 1 day. In both cases it reboots during periodic daily (the jails run periodic too, at the usual time). This is a ZFS-only (+nullfs) system There is no coredump. Watchdogd is currently not enabled on this system. In the logs I don't find any traces. The system is not really low on resources: last pid: 18031; load averages: 0.25, 0.23, 0.80 up 0+03:59:05 08:57:12 189 processes: 1 running, 188 sleeping CPU: 0.3% user, 0.0% nice, 0.4% system, 0.1% interrupt, 99.1% idle Mem: 579M Active, 709M Inact, 2311M Wired, 8253M Free ARC: 1460M Total, 418M MFU, 868M MRU, 1946K Anon, 17M Header, 155M Other Swap: 4096M Total, 4096M Free Does this ring a bell for someone or any ideas before I try to hunt this down? The same problem was reported yesterday on Stable Periodic jobs triggering panics in 10.1 and 10.2 https://lists.freebsd.org/pipermail/freebsd-stable/2015-December/083807.html Also ZFS with jails. Miroslav Lachman ___ 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: HELP: Howtwo create a passwd-suitable hash for usage with psswd -H 0?
Lowell Gilbert wrote on 02/18/2016 17:20: Allan Jude writes: On 2016-02-18 10:29, O. Hartmann wrote: I'm now down to a small C routine utilizing crypt(3). But this is not what I intend to have, since I want to use tools from the FBSD base system. [...] I have wanted to bring something like that over for a while, but looking at the source for pwhash I decided I'd want to start from scratch. "openssl passwd", maybe? It is really old implementation and cannot produce any modern hash than MD5. Miroslav Lachman ___ 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: mount_smbfs(8): support for SMBv3.02?
O. Hartmann wrote on 03/08/2016 13:53: On Tue, 8 Mar 2016 10:55:25 +0100 Edward Tomasz Napierała wrote: On 0303T1047, O. Hartmann wrote: Does FreeBSD's mount_smbfs(8) support for Microsoft's SMBv3 protocol introduced with Windows 8 and Windows Server 2012/R2? No, it only supports the obsolete SMB1 (aka CIFS) protocol. Since SMB2 is a completely different protocol, supporting it properly pretty much requires implementing it from scratch. SMB3 is one of the SMB2 revisions and thus is backward compatible with SMB2. [...] Thank you very much for this clearification. This explains much strange behaviour I faced. Do you see any chance that this gets fixed in a forseable time? Linux seems to support SMBv3 by now. Or is a support considered obsolete and handled via /net/samba43? I am not a FreeBSD expert but I am using mount_smbfs - with some troubles for a long time. The code base is really old and not well maintained. There are/were many problems with charset conversions etc. And there is no mount_smbfs in net/sambaXY packages AFAIK (smbclient is not an option in our environment were we need to access SMB mounted files from 3rd party PHP web applications) It would be really nice if somebody can bring better support for FreeBSD's SMB/CIFS mount. Maybe through FreeBSD Foundation projects. For a security appliance, I try to avoid as much packages as possible, so therefore my concerns regarding mount_smbfs. I can use packages but there is none with mount ability of SMB/CIFS or I don't know about it. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Glen Barber wrote on 03/08/2016 14:18: On Tue, Mar 08, 2016 at 03:40:16PM +0300, Slawa Olhovchenkov wrote: [...] Packaging of individual utilites is useless (total 19MB vs 30.7+2.8+20.7+2.9) and incorrect (for example, WITHOUT_ACCT not only don't build accton/lastcomm/sa but also cut off accaunting code from kernel for space saving and perforamce). Packaging individual utilities is not useless, depending on who you ask. One of the first replies I received when starting separating userland utilities into separate packages was further splitting rwho(1) and rwhod(8) into different packages, the use case being not necessarily needing (or wanting) the rwho(1) utility on systems where rwhod(8) runs. I didn't tried pkg base yet but I read posts on mailinglist. I understand the need of separating and splitting on the one side and I understand the fear of too long list of packages when one need to do some maintenance (update or upgrade). So one idea come to my mind - what about some meta-packages like "utilities, kernel, libs32, debug" hiding all details about real packages if there are some env variable or command line switch turned on? Meta-packages is used in current ports for things like PHP extensions. These ports meta-packages are not hiding real packages so this can be improved for base packages. It is just a quick idea how to satisfy both sides ;) Miroslav Lachman ___ 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: zfsboot patch for /usr
Roger Marquis wrote on 03/10/2016 00:36: Wondering if anyone has example patches for zfsboot (from usr.sbin/bsdinstall/scripts)? We're looking to change some of the default zfs subvolumes, removing /usr in favor of /usr/local in particular, and have run into a "parent does not exist" issue. It's not clear where in the script the /usr parent dir should be mkdir'd. I no nothing about this script but if you want /usr/local as ZFS filesystem, then you need to create parent (/usr in this case) and you can use property canmount=off plus different 'mountpoint' (for example /mnt/usr) to not mount /usr over existing directory on root filesystem. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Slawa Olhovchenkov wrote on 03/11/2016 14:31: On Fri, Mar 11, 2016 at 02:20:59PM +0100, Baptiste Daroussin wrote: On Fri, Mar 11, 2016 at 04:10:56PM +0300, Slawa Olhovchenkov wrote: On Fri, Mar 11, 2016 at 01:05:11PM +0100, Baptiste Daroussin wrote: [...] Case of only a few monolitic packages is essentiality simple then case of 1000 combined packages. pkg info -a on one diff with pkg info -a on the other for the full content: pkg info -a --raw on both end and diff them. That should cover your case, no? No, that may cause a much false positive: slight different versions, unimportant packets and etc. In 1000 packets this give to many noise. If you don't need version numbers, you can list just package names pkg query %n or package origins pkg query %o Anything else is on your side and even if I understand your complaints (and I agree with some of them) I don't thing it will change anything on the future of packaged base. So it is better to spend our time on working local solution to new problem. It has some pros and some cons and I hope the pros will outweigh cons. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Slawa Olhovchenkov wrote on 03/11/2016 15:05: On Fri, Mar 11, 2016 at 02:58:17PM +0100, Miroslav Lachman wrote: Slawa Olhovchenkov wrote on 03/11/2016 14:31: On Fri, Mar 11, 2016 at 02:20:59PM +0100, Baptiste Daroussin wrote: On Fri, Mar 11, 2016 at 04:10:56PM +0300, Slawa Olhovchenkov wrote: On Fri, Mar 11, 2016 at 01:05:11PM +0100, Baptiste Daroussin wrote: [...] Case of only a few monolitic packages is essentiality simple then case of 1000 combined packages. pkg info -a on one diff with pkg info -a on the other for the full content: pkg info -a --raw on both end and diff them. That should cover your case, no? No, that may cause a much false positive: slight different versions, unimportant packets and etc. In 1000 packets this give to many noise. If you don't need version numbers, you can list just package names pkg query %n or package origins pkg query %o currently: [...] base base base base base base base base base base base base base base base base base base base [...] Anything else is on your side and even if I understand your complaints (and I agree with some of them) I don't thing it will change anything on the future of packaged base. So it is better to spend our time on working local solution to new problem. It has some pros and some cons and I hope the pros will outweigh cons. I am don't talk 'this is imposible'. I am talk 'this is awkward'. What purpose for paclaging base system? packaging for packaging? Or packaging for simplify and comfortably management, maintance and upgrade? I hope it will simplified updates. Freebsd-update was so unreliable and unpredictable for me that I returned to the "make buildkernel && make buildworld" on builder machine and "make installkernel && make installworld" through NFS on destinations. And it has some cons too - recompile whole system and reinstall on all machines instead of just some small package. It has it's impact on size of backups too. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Slawa Olhovchenkov wrote on 03/11/2016 15:51: On Fri, Mar 11, 2016 at 03:39:08PM +0100, Miroslav Lachman wrote: [...] recompile whole system and reinstall on all machines instead of just I am proposed: patch packages (replaced or removed some files). some small package. It has it's impact on size of backups too. Size of backups? We have differential backups - only modified files are backed up every night. If whole userland is replaced by "make installworld" or by extracting tar, then each file is backed up again. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Bryan Drewery wrote on 03/13/2016 06:00: On 3/11/16 9:01 AM, Daniel Eischen wrote: On Fri, 11 Mar 2016, Slawa Olhovchenkov wrote: On Fri, Mar 11, 2016 at 01:05:11PM +0100, Baptiste Daroussin wrote: On Tue, Mar 08, 2016 at 05:35:59PM +, David Chisnall wrote: On 8 Mar 2016, at 15:14, Slawa Olhovchenkov wrote: In terms of comparing packages, if you’re doing that visually then you are likely to have problems anyway, unless your eyes and brain work far better than most humans. We can make that much easier by providing libxo output in pkg and allowing you to have a simple jq script that tells you what the differences are. pkg can already expose the entire content of a package in json or ucl via: $ pkg info --raw --raw-format [json|json-conpact|yaml|ucl] name Exposing the entire content of a package is not a root of cause. Question in comapring of two different setup with different behaviour and search cause of difference. Case of only a few monolitic packages is essentiality simple then case of 1000 combined packages. It would be nice to have pkg(8) show packages in tree form, with option to show just top-level meta packages or packages that have no meta. Perhaps this is possible, but it's not obvious to me. https://github.com/freebsd/pkg/blob/master/scripts/pkg_tree.sh Thank you. Can you publish it as a port? I know there is one written in Perl but I like your sh without dependencies. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Dag-Erling Smørgrav wrote on 03/14/2016 20:29: Miroslav Lachman <000.f...@quip.cz> writes: Bryan Drewery writes: https://github.com/freebsd/pkg/blob/master/scripts/pkg_tree.sh Can you publish it as a port? I know there is one written in Perl but I like your sh without dependencies. It's not very useful, in my opinion. The relationships between packages form a directed acyclic graph, not a tree, so pkg_tree.sh will either show too little (without -r) or far, far too much (with -r). If you want to visualize the package graph, you can feed the output of 'pkg query "%n %dn"' into something like graphviz. For other tasks, you are better off learning how to use 'pkg query' and possibly creating your own aliases or scripts. It's not that difficult; feel free to ask for help. (Just for kicks, I tried running 'pkg_tree.sh -rn' on my desktop, which has 934 packages installed. It's been running for ten minutes and has printed over 90,000 lines, with no end in sight.) I know it. :) I had my own similar script "ports_tree.sh" to show me dependencies according to choosen options. I know it is too verbose and I use grep -v to exclude known packages from the output. The same will apply to pkg_tree.sh as well. I use pkg info -r, pkg info -d or pkg query often. The request for port of pkg_tree.sh has not high priority for me, it is just that this shell version is better than already existing pkg_tree in Perl. (which I don't use) Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Lyndon Nerenberg wrote on 04/19/2016 05:24: On 2016-04-18 8:17 PM, Alfred Perlstein wrote: Can someone on the "too many packages" campaign here explain to me how having too fine a granularity stops you from making macro packages containing packages? Because honestly I can't see how having granularity hurts at all when if someone wanted to make it less granular all they would have to do is make some meta-packages. Meta-packages doesn't hide anything (in list of packages and problems with dependencies) It's the *I have to put it back together* part that's annoying. I didn't break something that has worked, forever. It shouldn't be incumbent on me to un-break someone else's work. +1 And you made another good point in previous e-mail about reviewed research. I would really like to see some docs about this topic. I have a feeling that some work on FreeBSD is against average users / admins and is good only for vedors of specialized or embedded devices. As many before - I am not against packaging base. It is good, but 10 - 20 packages will be enough. 800+ is too far from my feeling of "this is good feature". This seems like a nightmare to me. This was one of the reasons I don't like other OS distribuitions and I stayed with FreeBSD for more than 15 years. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
It would also be nice to get a statement of what the intended scope of these patches is from some of the people involved in the project. It's a major change to the system and it would be nice to have some kind of architectural document about what is happening. I'm not sure, for instance, what the release for 11 looks like with these changes, what changes need to be made to the installer (something of particular interest to me), how we build install media now that base is no longer self-contained (due to lack of pkg), what specific problems were intended to be solved, how package dependencies work, etc. Something like a few-page white paper would be *really* helpful for those of us who weren't at the BSDcan where this was discussed. Even a wiki page would help a lot. I really like FreeBSD, I am using it for more than 15 years on daily basis. FreeBSD had good and bad times (releases / changes) but one thing stays always the same - still bad communication about new features, work in progress etc. I think it is not too hard to publish papers about new base packages. Proposals, current state, ToDo to better inform users about upcoming changes. I think these informations already exist in some private form between developers. If these informations were more public I think there will be less annoyed posts in mailinglist and more constructive critics / ideas / patches. I did a guick search and found only one closely related page about packaged base: https://wiki.freebsd.org/FreeBSD-ng last edited 2014-03-11 Even this old page has "Known problems" mentioning the situation what we have now in this thread (fed-up people on both sides). So I think this was expected and people involved in this project could have do communication better. I had some concerns about it and some of them were explained and canceled after reading more than 100 posts in this thread. (some concerns remain). I believe if it was written in FreeBSD Wiki, there were not be so much dissapointed posts. I don't want to offend anybody on this list or FreeBSD team. I just think that things like this can and should be communicated better next time. Sysadmins and sysdevelopers have different point of view to a lot of things and it is better to talk about it before things are done and cannot be undone. Miroslav Lachman ___ 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: [CFT] packaging the base system with pkg(8)
Matthew Seaman wrote on 04/20/2016 12:43: On the release of 11.1 there would be a complete new set of system packages generated, and the upgrade process would install the new versions of those packages all round, even if the content of an individual package was identical to the one in 11.0. There's probably a handy optimization where we compare the before and after checksums for package files and don't overwrite on disk what is identical between package versions, but do update all of the bookkeeping in the pkgdb. This will be a really nice feature which can save a lot of bandwidth and storage for backups after upgrade. (but I don't know how many files are usually unchanged between upgrades) Miroslav Lachman ___ 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: why 100 packages are evil
Gerrit Kühn wrote on 04/25/2016 07:48: On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's the plan for 11.0-RELEASE. Hm... I never had any troubles with freebsd-update, it always "just worked" for me. OTOH, I remember having several issues with pkg, requiring to fix databases manually and so on. I had many issues with freebsd-update in the past so the last year I converted all machines back to "installkernel & installworld" from NFS mounted build server. It is faster and predictable than freebsd-update (in my case). I hope that pkg upgrade will be good replacement one day. But I don't think it is good enough right now. Miroslav Lachman ___ 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: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r
Paweł Tyll wrote on 07/12/2016 01:22: Those 3 things should shave off about 130MB of the 173MB needed to fit on 80-min CD-R. But... why this abstract number anyway? Why not 650MB CD-R? Why not overburnable 800MB 90-min CD-R or even 870MB 99-min CD-R? :) It is not only about the target media size. The size matters when you need to boot some recovery media from you desktop on remote server via KVM. And there is one thing I don't understand - why is the bootonly so large? I remember days when this fits to 50MB and now it is almost 235MB which renders it almost useless. For recoveries and remote installs I always use mfsbsd images (about 45MB). Miroslav Lachman ___ 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: Boot environments and zfs canmount=noauto
Andriy Gapon wrote on 07/28/2016 14:44:
I also would like to add, just in case, that I never set a BE's
mountpoint to '/'. I leave it at its default value like
/pond/ROOT/foobar. When the BE is active it would be mounted at /
anyway. And when it is not active and I want to access it for some
modifications, etc, then I can mount it simply with zfs mount and have
it at a non-interfering location. Ditto for its subordinate datasets.
I am saying this, because it seems that that is not how the FreeBSD
installer ("zfsboot") configures the default BE that it creates. I am
not sure what sysutils/beadm expects and configures in this regard. I
use my own custom script for doing beadm-like things.
beadm works with the following layout
NAME USED AVAIL REFER MOUNTPOINT
sys 10.8G 3.63G96K none
sys/ROOT 1.45G 3.63G96K none
sys/ROOT/b4pupg_20160516 8K 3.63G 606M /
sys/ROOT/b4pupg_20160523 8K 3.63G 621M /
sys/ROOT/b4pupg_20160531 8K 3.63G 643M /
sys/ROOT/b4pupg_20160616 8K 3.63G 649M /
sys/ROOT/b4pupg_20160627 8K 3.63G 655M /
sys/ROOT/b4supd_20160523 8K 3.63G 621M /
sys/ROOT/b4supd_20160728 8K 3.63G 664M /
sys/ROOT/default 1.45G 3.63G 663M /
sys/tmp104K 3.63G 104K /tmp
sys/usr 7.42M 3.63G96K none
sys/usr/home 6.72M 3.63G 6.72M /usr/home
sys/usr/obj 96K 3.63G96K /usr/obj
sys/usr/ports 428K 3.63G 332K /usr/ports
sys/usr/ports/distfiles 96K 3.63G96K /usr/ports/distfiles
sys/usr/src 96K 3.63G96K /usr/src
sys/var 9.31G 3.63G96K none
sys/var/audit 96K 3.63G96K /var/audit
sys/var/log 9.31G 3.63G 9.31G /var/log
sys/var/tmp152K 3.63G 152K /var/tmp
Note mountpoint "none" on sys/usr and sys/var. They are not mounted
intermediate directories, because /usr and /var should be part of the
BE, but some subdirectories should not be part of BE.
BEs under sys/ROOT have this properties
# zfs get all | grep mount
sys mounted no-
sys mountpoint none local
sys canmount ondefault
sys/ROOT mounted no-
sys/ROOT mountpoint none inherited from sys
sys/ROOT canmount ondefault
sys/ROOT/b4pupg_20160516 mounted no-
sys/ROOT/b4pupg_20160516 mountpoint / local
sys/ROOT/b4pupg_20160516 canmount off local
sys/ROOT/b4pupg_20160523 mounted no-
sys/ROOT/b4pupg_20160523 mountpoint / local
sys/ROOT/b4pupg_20160523 canmount off local
sys/ROOT/b4pupg_20160531 mounted no-
sys/ROOT/b4pupg_20160531 mountpoint / local
sys/ROOT/b4pupg_20160531 canmount off local
sys/ROOT/b4pupg_20160616 mounted no-
sys/ROOT/b4pupg_20160616 mountpoint / local
sys/ROOT/b4pupg_20160616 canmount off local
sys/ROOT/b4pupg_20160627 mounted no-
sys/ROOT/b4pupg_20160627 mountpoint / local
sys/ROOT/b4pupg_20160627 canmount off local
sys/ROOT/b4supd_20160523 mounted no-
sys/ROOT/b4supd_20160523 mountpoint / local
sys/ROOT/b4supd_20160523 canmount off local
sys/ROOT/b4supd_20160728 mounted no-
sys/ROOT/b4supd_20160728 mountpoint / local
sys/ROOT/b4supd_20160728 canmount off local
sys/ROOT/default mounted yes -
sys/ROOT/default mountpoint / local
sys/ROOT/default canmount ondefault
Miroslav Lachman
___
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: Destroy GPT partition scheme absolutely, how?
Hartmann, O. wrote on 09/26/2016 15:01: [...] Using a fresh/new SD or USB resolves the problem. But the question remains: how can I destroy any relevant GPT information on a Flash drive (or even harddisk) to avoid unwanted remains of an foul image installation? First guess was to write the last couple of bytes on such a flash drive by letting dd(1) counting backwards, but I couldn't figure out how to let dd(1) do such a procedure. The nightmare didn't end, while trying, the SD flash card died :-( I use dd if=/dev/zero almost everytime when I need to install system on used HDD. I rewrite about 10MB on its start and then about 10MB on the end. I have some script to do this - simply takes media size from diskinfo command, substract 10MB and then dd with seek Hope that it will help you Miroslav Lachman ___ 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: 9.0 beta2 & the new bsdinstaller
Chris Rees wrote: On 25 September 2011 14:01, Fbsd8 wrote: deeptec...@gmail.com wrote: Fbsd8 wrote: [...] the reboot starts. Don't let the reboot occur until the memstick is removed. Do NOT alter! More often than not, (1) you keep floppies, optical discs, and memory sticks in your computer without intending to boot from them, and (2) you'll want to use your BIOS's boot-once functionality (press a specific keyboard button to bring up the media choser menu for that boot; otherwise boot from the hard drives) whenever you do want to boot from floppies, optical discs, or memory sticks. You have missed the subject completely of what #6 is addressing. This has nothing to do with telling the pc hardware which media to boot from at power up time like you suggest in your post. This has to do with the logic of the new bsdinstall process and the differences between bsdinstall and sysinstall in the way the install media is removed from the pc before it reboots as part of the normal install process. Surely a reminder rather than an obstinate refusal to continue is appropriate? Example: Please remove your install media so that it is not loaded on reboot, and press any key to continue I agree with your suggestion. Reminder is helpful for beginners. But I really hate systems / applications forcing me to do something not necessary. Things like this are operators decision. System should provide choices. There are real situations, where install media cannot be removed (install via remote KVM with real local USB stick) and there is no need to not allow user to reboot from the installer. Miroslav Lachman ___ 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: RFC: Project geom-events
Lev Serebryakov wrote: [...] One thing is missed from software RAIDs is spare drives and state monitoring (yes, I know, that geom_raid supports spare drivers for metadata formats which supports them, but it not universal solution). I am still missing one thing - dropped provider is not marked as failed RAID provider and is accessible for anything like normal disk device. So in some edge cases, the system can boot from failed RAID component instead of degraded RAID. This can cause data loss or demage. Is it possible to fix it by something like your geom-events, or should it be done in each GEOM RAID class separately? But after all, I realy appreciate your work in this area! I hope I will have time to test it soon. Thank you! Miroslav Lachman ___ 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: RFC: Project geom-events
Lev Serebryakov wrote: Hello, Miroslav. You wrote 5 октября 2011 г., 1:27:03: I am still missing one thing - dropped provider is not marked as failed RAID provider and is accessible for anything like normal disk device. So in some edge cases, the system can boot from failed RAID component instead of degraded RAID. This can cause data loss or demage. What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? Something else? I am mostly using geom_mirror. If GEOM class drops underlying provider due to errors, it doesn't have chances to update metadata for it. I understand this, but if there are (stale) metadata on provider, system can read this metadata and should disallow normal operations (for example propagating slices, partitions and labels) But most of classes, if dropped provider attached again, will rebuild itself, as they track which components are actual and which ones are old. I see many times dropped provider (for example ada1) because of some DMA timeout (bad cables and so on), sometimes provider (disk ada1) detached from ATA channel and reattached after reboot. In both cases, provider has stale metadata and is marked as "broken" by geom_mirror and auto rebuild did not start. In this case, I see gm0 with all of its slices, partitions and labels and ada1 with the same slices, partitions and labels - this is the problem. Because there are two devices providing same labels and the winner is the first tasted... Even if the system (geom_mirror) knows, that ada1 is "broken disk". I think that GEOM should be more robust in this case and if metadata is found, do not publish slices, partitions, labels and so on... Do you want GEOM classes to track droppen components somewhere else and din't even try to attach them automaticaly when they re-appear? If some disk is removed, reinserted and synchronisation starts, then everything is OK. But situation where component is marked as "broken" and system and user can operate on it like on normal "good and clean" drive is wrong. The drive's content should be inacessible until operator do some action (for example gmirror clear on broken disk device). Miroslav Lachman ___ 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: RFC: Project geom-events
Lev Serebryakov wrote: Hello, Miroslav. You wrote 5 октября 2011 г., 12:24:06: What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? Something else? I am mostly using geom_mirror. [SKIPPED] Oh, I see. Unfortunately, there is no GEOM metadata infrastructure, GEOMs are too generic for this. I could design some meta-meta framework, and unify all RAID classes with "intenral" metadtata (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external geom_raid5) to use it. In such case it will work -- kernel will not pass providers with "dirty" metadtata to any GEOMs, but owners, for tasting. Of course, classes like geom_part and geom_raid could not be changed in such way -- they are forced to use pre-defined metadata formats. It is good idea, but it should be separate project. And, yes, it will change metadata format for these GEOMs, so it will not be backward-compatible. And, yes, it seems to be much more intrusive change in GEOM subsystem (because it will change tasting sequence), and should be supervised by other developers from very beginning. I could write proposal in near future, with some design notes. I am waiting years for the moment, when these GEOM problems will be fixed, so I am really glad to see your interest! It will be move to right direction even if changes will not be backward compatible. The current state is too fragile to be used in production. Gmirror alone can be used, glabel alone can be used, GPT alone can be used... but mix it all stacked together is way to hell. e.g. Using GPT on glabeled provider always ends with error message about corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I cannot use glable on devices and iSCSI device can have different number on each reboot? I wrote about it almost 2 years ago) GEOM layering possibilities are really amazing, but metadata, tasting and robustness in edge cases is not well done. If you are able to come with some fixes in GEOM metadata implementation / handling, I see better future :) Unfortunately, I am not a C programmer, so I cannot write patches, but I can test whatever you will need in this area. You are right, it should be separate project. I am looking forward to your proposal / wiki page. Thank you again for your work on GEOM improvements! Miroslav Lachman ___ 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: RFC: Project geom-events
Scot Hetzel wrote: 2011/10/5 Miroslav Lachman<000.f...@quip.cz>: I am waiting years for the moment, when these GEOM problems will be fixed, so I am really glad to see your interest! It will be move to right direction even if changes will not be backward compatible. The current state is too fragile to be used in production. Gmirror alone can be used, glabel alone can be used, GPT alone can be used... but mix it all stacked together is way to hell. e.g. Using GPT on glabeled provider always ends with error message about corrupted secondary GPT table. (But how can I use iSCSI in reliable way if I cannot use glable on devices and iSCSI device can have different number on each reboot? I wrote about it almost 2 years ago) You don't need to use glabel on GPT disks, as gpart has it's own way to label GPT disks: [...] The point was that glabel on disk device is successful, gpartitioning on glabeled device is successful, but metadata handling / device tasting is wrong after reboot and this should be fixed, not worked around. Otherwise thank you for example with GPT labels, it can be useful in some cases. Miroslav Lachman ___ 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: RFC: Project geom-events
Ivan Voras wrote: The point was that glabel on disk device is successful, gpartitioning on > glabeled device is successful, but metadata handling / device tasting is > wrong after reboot and this should be fixed, not worked around. > > Otherwise thank you for example with GPT labels, it can be useful in > some cases. Um, you do realize this is a "physical" problem with metadata location and cannot be solved in any meaningful way? Geom_label stores its label in the last sector of the device, and GPT stores the "secondary" / backup table also at the end of the device. The two can NEVER work together. The same goes for any other GEOM class which stores metadata and GPT. The only way to get this sorted out is to make a label class (or adapt glabel) which does NOT store metadata anywhere on the devices. Maybe they can store it in the file system (a file in /etc - though you then lose bootability, and have to somehow connect devices and labels), or the device hardware ID can be used as a label (but not all devices have it, and in case of "software" constructs like iSCSI the labels can be changed). Then there should be warning in documentation or error message printed by command in the time of writing metadata. I am not a GEOM expert, but isn't it wrong concept, that glabel writes its metadata and publish original device size? If some GEOM write metadata at last sector (or first), then it should shrink the published size (or offset). Or is the problem at geom_part, that it is writing metadata past the advertised end of the device? e.g. If I have disk device with size of 100 sectors and glabel metadata is stored at the last sector, then glabel should shrink the advertised size to 99 sectors - then GPT secondary table will be at sector 99 instead of 100. I know there is problem if somebody access the device by its normal device node (e.g. /dev/ada0), then secondary GPT table will be at different place, not in last sector. But this is the mistake in glabel concept and if it cannot be solved by any other way, then glabel should not be allowed to place labels on the disk device at all. (if we cannot be sure it is non conflicting) The current state is simply wrong, because user can do something what cannot work and is not documented anywhere. Miroslav Lachman ___ 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: RFC: Project geom-events
Lev Serebryakov wrote: Hello, Miroslav. You wrote 6 октября 2011 г., 16:59:19: [...] The current state is simply wrong, because user can do something what cannot work and is not documented anywhere. It is Ok in UNIX way, in general. You should be able to shoot your leg, it is good :) I am sorry for my late reply. Foot shooting is OK, if somebody wants to shoot his foot, but I don't want to shoot my foot if I am aiming at my head :) But if geom_label doesn't reduce its provider to count its own metadata, it looks like a bug! As Ivan Voras explained, it is not a bug, it is just a matter of mixing two things thant can't coexist together. So the problem is that it is not mentioned anywhere in the FreeBSD docs. (Thank you Ivan for your explanation!) And as somebody else already mentioned in this thread, it should be documented in manpages and Handbook and gpart should show warning message if user is trying to put GPT on non real disk devices. As is mentioned in the thread "Memstick image differences between 8.x and 9.x", the GPT brings more problems by requirement of second table at the end of the device (so disk image cannot be easily written by dd on bigger disk) ___ 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: [PATCH] updated /etc/rc.d/jail (ZFS support, persistent jails and other features)
Martin Matuska wrote: I have improved the jail etc script significantly (in addition to ZFS support and other improvements). - you can now set a jail_name="" parameter to set the name for your jail - the jails are still searched by "name", so you cannot manage the jail with the script if "name" in /etc/rc.conf changes while running. - the "status" subcommand now also shows the number of running processes, this way you can identify an empty jail - there are also two new subcommands - "create" and "remove", intended for persistent jail operation - if a jail is set to persistent, you can do the following sequence: create start stop remove. - non-persistent jails may also be created (won't be started) but will be removed on a "stop" http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.patch http://people.freebsd.org/~mm/patches/jail/jail_etc.v2.nowhitespace.patch Just a note - there were many attempts to add jail_myjail_name="myjail" variable to rc.conf but it was always denied with same answer: There is no reason for it, it can be done by jail_myjail_flags=" -n myjail" See this PR http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/150599 and freebsd-jail@ archive. Maybe it will change in jail v2 land or jail config by Jamie... Miroslav Lachman ___ 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: Use of newest version number such as 10.0 instead of current
Chuck Burns wrote: On Friday, November 11, 2011 08:17:52 AM you wrote: -snip- My sentence is NOT about "Current" , but 9.0 RC1 . Perhaps , you will NOT say , if a person is NOT knowledgeable , he should NOT use 9.0 RC1 . If you use a proper RC, then pkg_add will work until a new RC, and since there is no binary upgrade path for anything other than releases, you will need to reinstall, with the newly released RC. You can use freebsd-update for RC upgrades too! -snip- Up to now , my most disappointed situation is that , there is NO any tendency to lower required expertise level to use FreeBSD . Such an approach is confining FreeBSD to a small number of elite users when compared to millions of Linux users let alone hundred millions of some other operating systems which they are approaching to billions when version users are summed in spite of paying money also . GhostBSD, PCBSD are two options for "lower expertise" and, as such, are billed as desktop versions of FreeBSD. FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you can build your own system, making it either into a server, workstation, or even into a desktop system if you so desire. If you want something with point-n-click ease of use, go use one of the two desktop-oriented versions. Both GhostBSD, and PCBSD are just a desktop environment built on top of FreeBSD. PCBSD even has a 9.0 RC out now as well, if you're into testing. PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 environment. If you want something else, feel free to create your own. There is nothing in the BSD license that prevents you from doing that. Instead of complaining that SOMEONE ELSE should do something that YOU want done, why not just do it yourself. In other words, put up, or shut up. :) Really, this is not a proper worded answer to someone who just tried to request some more friendliness to new users and increase our user base. It doesn't metter if there are some other "freebsd based" projects. FreeBSD it-self has a problem - fewer users = fewer manufacturers will support FreeBSD (drivers). Miroslav Lachman ___ 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: Enhancing the user experience with tcsh
Warren Block wrote:
On Fri, 10 Feb 2012, Gonzalo Nemmi wrote:
On Thu, Feb 9, 2012 at 9:52 PM, Eitan Adler wrote:
In conf/160689 (http://www.freebsd.org/cgi/query-pr.cgi?pr=160689)
there has been some discussion about changing the default cshrc file.
In the same line that Wojciech on the PR ".cshrc should be updated for
modern hardware" I always set this ones on /usr/share/skel/dot.cshrc
bindkey "\e[1~" beginning-of-line #make Home key work;
bindkey "\e[2~" overwrite-mode #make Ins key work;
bindkey "\e[3~" delete-char #make Delete key work;
bindkey "\e[4~" end-of-line #make End key work;
Besides that I add an "if [ -d $HOME/bin ]" and add it to $PATH if it
exists, but that has nothing to do with ".cshrc should be updated for
modern hardware" ... it jsut comes in really handy.
The question becomes "how much is too much?" For example, ever since a
thread in the forums showed examples of csh/tcsh autocompletion, I've
thought the default .cshrc should be stuffed with them. Not for typing
reduction so much as self-documenting commands like
complete chown 'p/1/u/'
complete man 'C/*/c/'
complete service 'n/*/`service -l`/'
'service' autocompletes with a list of services--it helps the user by
showing valid choices. Same with 'chown', it gives a list of users.
Then there's this, which probably isn't quite right but has been useful
to me (thanks to forum members for help with it):
complete make 'n@*@`make -pn | sed -n -E "/^[#_.\/[:blank:]]+/d; /=/d;
s/[[:blank:]]*:.*//gp;"`@'
That completes with all lower-case make targets for the current directory.
Package operations are easier when the package names autocomplete:
complete pkg_delete 'c/-/(i v D n p d f G x X r)/' \
'n@*@`ls /var/db/pkg`@'
complete pkg_info 'c/-/(a b v p q Q c d D f g i I j k K r R m L s o G O
x X e E l t V P)/' \
'n@*@`\ls -1 /var/db/pkg | sed s%/var/db/pkg/%%`@'
There's lots more that could be done. Are they appropriate for a stock
.cshrc? Maybe now is the time.
I am +1 for better support of command autocompletion for FreeBSD
specific commands.
For example, I have this for services
complete service 'c/-/(e l r v)/' 'p/1/`service -l`/' 'n/*/(start stop
reload restart status rcvar onestart onestop)/'
Something for kernel modules
complete kldload 'n@*@`ls -1 /boot/modules/ /boot/kernel/ | awk -F/
\$NF\ \~\ \".ko\"\ \{sub\(\/\.ko\/,\"\",\$NF\)\;print\ \$NF\}`@'
complete kldunload 'n@*@`kldstat | awk
\{sub\(\/\.ko\/,\"\",\$NF\)\;print\ \$NF\} | grep -v Name`@'
complete kill 'c/-/S/' 'c/%/j/' 'n/*/`ps -ax | awk '"'"'{print $1}'"'"'`/'
complete killall 'c/-/S/' 'c/%/j/' 'n/*/`ps -axc | awk '"'"'{print
$5}'"'"'`/'
Or for portmaster
alias _PKGS_PkGs_PoRtS_ 'awk -F\|
\{sub\(\"\/usr\/ports\/\"\,\"\"\,\$2\)\;print\ \$2\}
/usr/ports/INDEX-`uname -r | cut -d . -f 1` && pkg_info -E \*'
complete portmaster 'c/--/(always-fetch check-depends check-port-dbdir
clean-distfiles \
clean-packages delete-build-only delete-packages force-config help \
index index-first index-only list-origins local-packagedir
no-confirm \
no-index-fetch no-term-title packages packages-build
packages-if-newer \
packages-local packages-only show-work update-if-newer version)/' \
'c/-/(a b B C d D e f F g G h H i l L m n o p r R s t u v w x)/' \
'n@*@`_PKGS_PkGs_PoRtS_`@'
The alias is there because same list of ports and packages are used for
other pkg / ports commands (portupgrade, pkg_info, pkg_delete, pkg_tree,
portell etc...)
I have collected completion for about 50 commands like: vim, where,
which, dd, find, man, limit, kill, bzip2, camcontrol, ifconfig, postfix,
postmap, mount, su, sed, sysctl, make etc..
Come of them are rough and need some tweaks.
I would like to share them with others, if there are interrest to
include it in stock FreeBSD base.
And if we are talking about better completion and history support, what
about following?
set history=1
set histdup=prev
set savehist=(1 merge)
set autolist=ambiguous
set autocorrect
set autoexpand
set complete
set correct=cmd
set color
set colorcat
set filec
At last - if you are using screen or tmux and what properly saved and
merged history from all screens after logout, you need to add
history -S
to the ~.logout file. Otherwise I have saved history only from last
screen window.
Miroslav Lachman
___
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: Enhancing the user experience with tcsh
Erich Dollansky wrote: Hi, On Friday 10 February 2012 18:05:59 Miroslav Lachman wrote: Warren Block wrote: On Fri, 10 Feb 2012, Gonzalo Nemmi wrote: I would like to share them with others, if there are interrest to include it in stock FreeBSD base. just publish them at least here. It will always be helpful for beginners and also for people like me who use BSD since years but did not see certain options tcsh has. OK, here it is http://freebsd.quip.cz/ext/2012/2012-02-10-tcshrc/ It is based on tcshrc files found on the net, so it is not all my work. The files include many commented out lines as I change them over time. You can use it as inspiration for your own set of useful cahnges in you tcshrc files. Miroslav Lachman ___ 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: Enhancing the user experience with tcsh
Eitan Adler wrote: Picking a random person to reply to. There are a lot of good suggestions in this thread, but can we please remember a few things: - Users can always add their own ~/.cshrc - Many users will get annoyed by what is someone else's amazing setup The main problem of this is: novice user don't know how to enable some "advanced" settings for default FreeBSD shell (csh / tcsh) or even don't know they exist. But all skilled persons are able to disable "annoing" new settings in few seconds. I think that default FreeBSD install should be more friendly to new users. That's why I am propossing better support of command completion "out of the box". (I will still use my own set of changes in rc files which I am deploying in a first step on all our machines) [...] For the record this is the current version of the patch I'd like to commit: Note that it slightly changed from the original (I removed the duplicate prompt setup and reorganized where the edits are made to make the diff look nicer). commit 3ea4ea3a59d14cb060244618dd89d7dd0170bee1 diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc --- a/etc/root/dot.cshrc +++ b/etc/root/dot.cshrc @@ -7,9 +7,10 @@ alias h history 25 alias j jobs -l -alias la ls -a +alias la ls -aF alias lf ls -FA -alias ll ls -lA +alias ll ls -lAF +alias ls ls -F # A righteous umask umask 22 @@ -17,15 +18,19 @@ umask 22 set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin $HOME/bin) setenvEDITOR vi -setenv PAGER more +setenv PAGER less setenvBLOCKSIZE K if ($?prompt) then # An interactive shell -- set some stuff up - set prompt = "`/bin/hostname -s`# " + set prompt = "[%n@%m]%c04%# " + set promptchars = "%#" set filec - set history = 100 - set savehist = 100 + set history = 1 + set savehist = 1 + set autolist + # Use history to aid expansion + set autoexpand set mail = (/var/mail/$USER) if ( $?tcsh ) then bindkey "^W" backward-delete-word I am fine with this change. It is better than nothing. :) Miroslav Lachman ___ 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: ZFS TRIM support committed to HEAD.
Pawel Jakub Dawidek wrote: On Sun, Sep 23, 2012 at 08:20:41PM -0400, Glen Barber wrote: Hi Pawel, [...] Great! Thanks for this. Any chance you can document the following sysctls? None od the kstat sysctls are documented, they emulate kstat framework from Solaris. We would need to modify a lot of vendor code to document those in 'sysctl -d' output. It still would be good to have them documented even elsewhere, eventhough most are rather self-explanatory. There were some "sysctl documentation" project on the net (maybe som GSoC, I am not sure). Most sysctl's are self-explanatory - unfortunately only for knowledgeable developers or authors of the code. And sometimes even a short description (sysctl -d) is not enough. It explains meaning of some counter, but not the condition where / by what this counter is triggered. I think some public page on FreeBSD Wiki bould be good starting place for documenting all useful sysctls, their meaning, tips for tuning, what one can gain or lose by changing them etc. root@kaos:/root # sysctl -d kstat.zfs.misc.zio_trim kstat.zfs.misc.zio_trim: kstat.zfs.misc.zio_trim.zio_trim_bytes: kstat.zfs.misc.zio_trim.zio_trim_success: kstat.zfs.misc.zio_trim.zio_trim_unsupported: kstat.zfs.misc.zio_trim.zio_trim_failed: Miroslav Lachman ___ 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: FreeBSD 10-CURRENT and 9-STABLE snapshots
Glen Barber wrote: Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ It would be nice to have them hosted on FreeBSD.org site as official source. Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) Miroslav Lachman ___ 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: UFS2 and Journaling in 9.1-RC3
CeDeROM wrote: On Fri, Dec 7, 2012 at 2:41 PM, Ivan Voras wrote: It looks like you are confusing GEOM journalling (-J) and UFS-SU journalling (-j). They are very different, and today you probably want to use the latter. If you are installing 9.x from scratch, it will be enabled by default. If not, you can use newfs -j or tunefs -j to enable it. "When any other means fail, read the manual" heh :-) I am still a bit confused, even after reading [1], because there is no explanation of difference between GJournal and SU / SU+J (which was introduced in FreeBSD 9.0). I understand GJournal works below filesystem level and I dont need to use fsck. SU/SU+J is part of the UDF/UDF2 filesystem. I should not use SU and GJournal at the same time. What are the advantages of SU/US+J? What is the advantage of SU+J over SU? Should I use Gjournal or SU/SU+J? Any hints welcome! :-) If I have already created UFS2 with -J, I understand I can switch it off, can I then simply turn of UFS+J (-j) with no data loss on existing filesystem? Which solution is better for drives>1TB when I dont want to wait an hour for fsck? In short - if you choose Gjournal with data and journal on the same disk, you will have about half write speed. If you choose SU+J, you will not be able to use UFS snapshot feature at this time (there is some bug and snapshots on SU+J is disabled) Other than that - SU+J is easier to Enable / Disable on existing partition but is not well testet - it is younger technology than Gjournal. Miroslav Lachman ___ 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: Enhancing the user experience with tcsh
Eitan Adler wrote: On Tue, Feb 14, 2012 at 8:19 AM, Astrodog wrote: Personally, I pay very little attention to the prompt. That being said... Plenty of people prefer widely different configurations for the prompt. I think everyone agrees that the default prompt isn't particularly informative, however, achieving consensus here is going to be almost impossible. I suggest that it be handled as a seperate discussion, perhaps? That would result in even more of a bikeshed than this thread. I'm pretty sure I'm going to go with one of the prompts posted to this thread after a bit of experimentation. Remember that the prompts are for inexperienced users and those of you with awesome prompts are not the target audience for the change. Not just prompts, but everything in default .cshrc / .tcshrc should be targeted to inexperienced new users and we should look at it from this point of view. Not from "our personal preferences". The current and future changes in .cshrc is not targeted to us - readers of freebsd-current@, but to new users comming from the world of windows and penguins. I still remember those days when I came from Win95 to FreeBSD 4.x and didn't know anything about shell's possibilities. Somebody recommends me bash and I used it as my default shell for a couple of years - until I realized, that same or better prompt, completion and history search can be achieved with already installed csh / tcsh. Just by few modifications in .cshrc. I don't think readers of this mailing list are using default unmodified .cshrc. So the question is not "what is good to me" (or to you), but "what is good for new users?". What can we serve them to make their life easier and show them the power and possibilities of tcsh. We all can still use our good old .cshrc modifications, our own prompt, colors, etc. as we already do. That's why I am proposing as much "Good features (TM)" enabled by default as possible. Because we others can easily disabled them if we don't like them. But new users can't enabled them, because they don't know about them. Miroslav Lachman ___ 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: ECC memory driver in FreeBSD 10?
Nikolay Denev wrote: On Apr 6, 2012, at 2:48 PM, O. Hartmann wrote: I'm looking for a way to force FreeBSD 10 to maintain/watch ECC errors reported by UEFI (or BIOS). Since ECC is said to be essential for server systems both in buisness and science and I do not question this, I was wondering if I can not report ECC errors via a watchdog or UEFI (ACPI?) report to syslog facility on FreeBSD. FreeBSD is supposed to be a server operating system, as far as I know, so I believe there must be something which didn't have revealed itself to me, yet. If the hardware supports it, such errors should be logged as MCEs (Machine Check Exceptions). I can say for sure it works pretty well with Dell servers, as I had one with failing RAM module, and it reported the corrected ECC errors in dmesg. Memory ECC errors are logged in to messages and you can decode it by sysutils/mcelog. I did it in the past on one of our Sun Fire X2100 M2 with FreeBSD 8.x. Miroslav Lachman ___ 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: [CFC/CFT] large changes in the loader(8) code
Pawel Jakub Dawidek wrote: On Thu, Jun 28, 2012 at 08:33:17AM -0700, Marcel Moolenaar wrote: On Jun 28, 2012, at 3:10 AM, Stefan Esser wrote: All of the above is ugly, U'm afraid :( Indeed. The only sane way is to put the metadata in a partition of its own. Every compliant OS will respect that and consequently will not scribble over the data unintentionally. Any other scheme that puts valuable data in some undocumented or unregistered location is violating the GPT spec right away and is susceptible to being clobbered unintentionally. If the user runs: # gpart create -s GPT /dev/mirror/foo for me it is obvious that he wants to partition the mirror device and not individual disks. Because the mirror was configured earlier, do you expect gmirror to somehow detect that someone is writting GPT metadata later and magically place GPT metadata on the raw disk and move mirror's metadata to some magic partition? Not to mention that the mirror itself doesn't have to be configured on top of raw disks. And not to mention that the mirror may never be partitioned. If GPT in your opinion is limited only to raw disks then I guess the best way to fix that is to refuse to configure GPT on anything except raw disks (which was already proposed by Andrey?). In my opinion this is unacceptable, but I think this is what you are suggesting. One of the GEOM design goals was to be flexible. Let the user decide in what order he wants to configure various layers. How do you know that in every possible scenerio software mirroring should come after partitioning and encryption after mirroring? Why can't we provide flexible tools to the user and let him decide? Maybe GPT nesting violates standards, but why can't we support it as an extention, really? I recognize the need to warn users if they use FreeBSD-specific features. We do that with non-standard APIs. So how about this. Let's modify gpart(8) to print a warning if GPT is configured on something else than raw disk. Let's the warning say that such configuration is non-standard and problems are expected if the disk is shared between other OSes. In my opinion that's fair. With such a warning in place, I think we can allow users to decide on their own if they really want that or not. Then, we can also improve FreeBSD boot loader to play nice with FreeBSD-specific extensions. I think this is valid point of view. FreeBSD already does things not supported by other OSes and I am completely fine with it - I am running FreeBSD on servers, not sharing anything with other OSes so I prefer extended FreeBSD specific features over 100% standard compliant behaviour crippling SW mirroring etc. I think that our tools should support / provide all standard compliant (compatible) features, but let user to choose any other extended non-compatible features if user wants it. Even if it can be seen as foot shooting by somebody else. And maybe one day our solution will be widespread and taken as a standard. Miroslav Lachman ___ 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: Change default for periodic/weekly/400.status-pkg ?
Oliver Fromme wrote: Hi, Currently, the periodic/weekly/400.status-pkg script uses the ports' INDEX file if it exists. On my machines, the INDEX file exists, and the periodic script produces output like this: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: $ That is, apparently everything is up to date, so I don't have to do anything. But this is wrong. When I change it to use /nonexistent in place of the INDEX file, I get this output: $ /etc/periodic/weekly/400.status-pkg Check for out of date packages: netpbm-manpages-10.35.85 was orphaned: LOCAL/netpbm-manpages pkg-config-0.25_1 was orphaned: devel/pkg-config $ A-ha! The first line is to be expected (netpbm-manpages is a "fake" port that I maintain locally), but the second line about pkg-config is much more important. Now this makes me look at ports/UPDATING, revealing that pkg-config was replaced by pkgconf. Therefore I propose to change the default for the periodic script to use /nonexistent. It does not change the output that usually appears, it only produces _additional_ output for installed packages whose origin disappeared. This is valuable information, I think. Also, the INDEX file could be outdated, which might lead to wrong results, so using the INDEX file by default is probably not a good idea anyway. On the other hand - we are using daily `portsnap -I update` so we have updated INDEX on all our machines, but outdated ports tree. (freezed in some point in time, so we can have same versions installed on all servers in a group) I think it should be user configurable in /etc/periodic.conf if somebody want to use INDEX or not. Or the hack with /nonexistent should be mentioned in a comment in /etc/defaults/periodic.conf and in a manpage. Miroslav Lachman ___ 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: Future of pf / firewall in FreeBSD ? - does it have one ?
Gleb Smirnoff wrote, On 07/18/2014 13:06: [...] The pf mailing list is about a dozen of active people. Yes, they are vocal on the new syntax. But there also exist a large number of common FreeBSD users who simply use pf w/o caring about syntax and reading pf mailing list. If we destroy the syntax compatibility a very large population of users would be hurt, for the sake of making a dozen happy. I don't agree on this part. Almost every bigger project / application needs to make some uncompatible changes over time. Apache, MySQL, PHP, GNOME, KDE... or FreeBSD itself with recent changes from pkg_* to pkg(ng). Backward compatibility cannot be maintained infinitely if new features should be added. I don't see the reason why PF should be exception. And I am writing this as one who really don't need any new PF features, but I am fine with syntax change in newer FreeBSD major version. There were bigger problem with pf.conf in the past - freebsd-update deleted it and machine was unprotected after reboot. So properly announced syntax change and tutorial to conversions is not problem for me and I hope for some others too. Miroslav Lachman ___ 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: ipfilter(4) needs maintainer
Rui Paulo wrote: > 2013/04/13 16:01、Scott Long のメッセージ: > >> Maybe something else, but whatever it is, it should be done. If you and >> Gleb don't want to do this, I will. > > I already started writing a guide. See here for a very incomplete version: > > http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html 1.1 ipftest PF rules can be checked with pfctl -n: -n Do not actually load rules, just parse them For example: pfctl -nvf /etc/pf.conf.tmp 3 Examples 3.1 Filtering ipf.conf and pf.conf has the same syntax for basic filtering rules, so you can use it on the right side to: block in on le0 proto tcp from 10.1.1.1/32 to any pass in proto tcp from 10.1.0.0/16 port = 23 to 10.2.0.0/16 flags A/A Miroslav Lachman ___ 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: request for your comments on release documentation
Mark Felder wrote: On Wed, 12 Jun 2013 12:49:21 -0500, Hiroki Sato wrote: [...] 3. Is there missing information which should be in the relnotes? Probably there are some missing items for each release, but this question is one at some abstraction level. Link to commit log and diff, detailed description of major incompatible changes, and so on. I try to keep up with the development and changes in releases as best I can and I haven't noticed any glaring omissions over the last several releases. I think you're doing a fine job. Also, is there a reason this isn't a "living" document that can be updated as things get MFC'd to STABLE? It would help take load off your end and maybe speed up release once the freeze has happened and we begin the final grind through release candidates. It would be nice if all release related documents (relnotes, errata, hardware notes etc.) will be "living" after release (in online version) and not considered as set in stone. There are sometimes missing items which should be included online as soon as possible, but rarely are. For example, I found two issues with OpenSSH in 8.4 release. (bugs or features, or just incompatibilities with older versions) None of them is listed anywhere and I think it is really bad, because one issue can cause sshd not started after upgrade. So the online version of these docs should be "living" and updated as some issues and questions arises on the mailing lists and forums few days / weeks after release. On the other hand, FreeBSD has good quality of docs included Release Notes. (thank you for your work!) If there is some "man power", some items can be more detailed with links to other online resources like FreeBSD wiki, but only for some important items. Miroslav Lachman ___ 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: New iSCSI stack.
Edward Tomasz Napierała wrote: Wiadomość napisana przez Ivan Voras w dniu 5 wrz 2013, o godz. 13:18: On 05/09/2013 12:27, Edward Tomasz Napierała wrote: Hello. At http://people.freebsd.org/~trasz/cfiscsi-20130904.diff you'll find a patch which adds the new iSCSI initiator and target, against 10-CURRENT. To use the new initiator, start with "man iscsictl". For the target - "man ctld". Just a naming question: "ctld" could mean anything, I'd parse it as a "control deamon" or something like that. Could you name it something which reminds the user of iscsi? Like iscsictld? As the man page says, ctld is "CAM Target Layer / iSCSI target daemon". Sure, right now it's pretty iSCSI-specific, but it doesn't need to be - it can be extended to just manage CTL configuration (e.g. for Fibre Channel), or to support other CTL-backed storage protocols, such as FCoE. It's just a helper daemon for ctl(4) - thus, ctld(8). And in case someone does "man -k iscsi", there is the "iSCSI target" in the manual page title. I understand your explanation, but still thinking rc.conf variables are really confusing and unintuitive: iscsid_enable iscsictl_enable ctld_enable I cannot tell what they control just by their names and the same apply for services names. "If I want to restart iscsi target, should I use 'service iscsid restart' or 'service iscsictl restart'? ... oh wait, it should be 'service ctld restart'" I think it should be more user friendly. Something as Apache 2.2.x has httpd and httpd.conf, but users are using 'service apache22 restart' and 'apache22_enable="YES"', because there can be more "http" daemons. My $0.02 Miroslav Lachman ___ 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: Following a panic (271945): zpool status reports 1 data error but identifies no file
On 11/06/2023 14:02, Graham Perrin wrote: See below, should I begin scrubbing? Or (before I begin) might zdb reveal something useful? The supposed error was observable after <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271945> /271945 – panic: deadlres_td_sleep_q: possible deadlock detected for 0xfe0133324ac0 (stat), blocked for 1801328 ticks// / [..] errors: Permanent errors have been detected in the following files: Can it be that the error was in file which is deleted now? Or was in snapshot which was already destroyed by some automatic script? Kind regards Miroslav Lachman
Re: Has the update procedure changed?
On 09/08/2023 08:22, Kevin Oberman wrote:
I don't see how you get this from the man page.
"Compares only files known to be
essential to the success of {build|install}world, i.e.,
/etc/group and /etc/master.passwd.
If it is potentially updating files that MIGHT be essential to a
successful buildworld, running it after buildkernel seems quite wrong.
At least I read {build|install}world as buildworld or installworld.
Correct me if I am wrong but AFAIK etcupdate -p (or mergemaster -p)
updates entries in [master.]passwd and group which are only needed to
install new files with the right owner and group set, not to build these
files. (installkernel installs everything ass root:wheel)
Also Makefile contains this steps where mergemaster -p should be run
after installkernel and reboot:
2. `make buildworld'
3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
[steps 3. & 4. can be combined by using the "kernel" target]
5. `reboot'(in single user mode: boot -s from the loader prompt).
6. `mergemaster -p'
7. `make installworld'
And man page for etcpupdate -p has this:
-p Enable “pre-world” mode. Only merge changes to files
that are necessary to successfully run ‘make
installworld’ or ‘make installkernel
Kind regards
Miroslav Lachman
Re: Proposal: Disable compression of newsyslog by default
On 23/12/2023 08:18, Xin Li wrote: Hi, Inspired by D42961, I propose that we move forward with disabling the compression by default in newsyslog, as implemented in https://reviews.freebsd.org/D43169 Historically, newsyslog has compressed rotated log files to save disk space. This approach was valuable in the early days where storage space was limited. However, the landscape has changed significantly. Modern file systems, such as ZFS, now offer native compression capabilities. Additionally, the widespread availability of larger hard drives has diminished the necessity for additional compression. Notably, the need to decompress log files for pattern searches poses a significant inconvenience, further questioning the utility of this legacy feature. In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is eligible for compression rather than directly enforcing it. It allows for a more flexible approach, wherein the actual compression method can be set to "none" or specified as one among bzip2, gzip, xz, or zstd. Therefore I would propose that we change the default compression setting to "none" in FreeBSD 15.0. This change reflects our adaptation to the evolving technological environment and user needs. It also aligns with the broader initiative to modernize our systems while maintaining flexibility and efficiency. I look forward to your thoughts and feedback on this proposal. I don't think anything needs to be changed on newsyslog. Those who want to disable compression can do so in the "default" newsyslog.conf file. Why force this change in the newsyslog code? I also don't think that the log file should not be compressed even on a compressed filesystem. Compressed log files can be handled by tools like zcat, zless, zgrep, etc. without first decompressing the log file. Text log files can still grow to large sizes, and if you have a daily backup job over a long distance network, if you use a protocol without own compression, it is still better to have compressed log files than uncompressed on a compressed filesystem. To me, it's the same as compressing large database dumps and not relying on filesystem compression. YMMV, but I really don't see any benefit of changing the newsyslog code, just change defaults in newsyslog.conf. Kind regards Miroslav Lachman
Re: noatime on ufs2
On 11/01/2024 09:54, Tomoaki AOKI wrote: On Thu, 11 Jan 2024 08:36:24 +0100 Alexander Leidinger wrote: [..] There's one possibility which nobody talked about yet... changing the default to noatime at install time in fstab / zfs set. I fully agree to not violate POLA by changing the default to noatime in any FS. I always set noatime everywhere on systems I take care about, no exceptions (any user visible mail is handled via maildir/IMAP, not mbox). I haven't made up my mind if it would be a good idea to change bsdinstall to set noatime (after asking the user about it, and later maybe offer the possibility to use relatime in case it gets implemented). I think it is at least worthwile to discuss this possibility (including what the default setting of bsdinstall should be for this option). [..] A different aspect of view. Nowadays, storages are quickly moving from HDD, aka spinning rust, to SSD. And SSD has a risk of sudden-death of wearing out. In ancient days, HDD dies not suddenly and at least some cases admins could have time to replace suspicious drives. But SSD dies basically suddenly. IMHO, this could be a valid reason to violate POLA. In limited use cases, atime is useful, at the cost of amplified write accesses. But in most cases, it doesn't have positive functionality nowadays. Anyway, we should have time to discuss whether it should be done or not until upcoming stable/15 branch. stable/14 is already here and it wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point to introduce this, unlike discussion about vi and ee on forums. The default values change over time as the needs of people, programs and hardware change. Many values for sysctls changed over time. If "noatime" can help people to not trash SSD / SD storage, I can imagine that bsdinstall will detect the storage type (simple guess can be made by diskinfo -v) and offer a "noatime" option that the user can check/uncheck. This option can be pre-selected for flash based storage. I don't care defaults for my-self, I can change them, but sane defaults should be beneficial for new users without much background knowledge. Kind regards Miroslav Lachman
Re: Removing fdisk and bsdlabel (legacy partition tools)
On 24/01/2024 19:50, Rodney W. Grimes wrote: On Wed, Jan 24, 2024 at 8:45?AM Ed Maste wrote: MBR (PC BIOS) partition tables were historically maintained with fdisk(8), but gpart(8) has long been the preferred method for working with partition tables of all types. fdisk has been declared as obsolete in the man page since 2015. Similarly BSD disklabels were historically maintained with bsdlabel. It does not yet have a deprecation notice - I have proposed a man page addition in https://reviews.freebsd.org/D43563. man page additions are not going to reach the people who may be using this. This should be a gonein(15) added to the binary. I also suspect that all of the people doing ufs installs are doing so via bsdlabel, not gpart. I have many FreeBSD installations running in a UFS-based VM, created using bsdinstall or manually using gpart. I haven't touched fdisk and bsdlabel in at least a decade. I would like to disconnect these from the build, and subsequently remove them. This is prompted by a recent bsdlabel bug report which uncovered a longstanding buffer overflow in that tool. Effort is much better focused on contemporary, maintained tools rather than investigating issues in deprecated ones. Removing these tools would happen in FreeBSD 15 only (no change in 14 or 13). Code review to disconnect fdisk: https://reviews.freebsd.org/D43575 How can you do bsdlabel -A -e /dev/foo with gpart? As far as I know that functionality never made it to gpart, neither the -A or -e. I was curious what this command does that is so special, but it seems to be of no use anymore: % bsdlabel -A /dev/ada0 bsdlabel: disks with more than 2^32-1 sectors are not supported Do we really need a tool that can't handle disks of average size (in this case 4TB)? Kind regards Miroslav Lachman
Re: Removing fdisk and bsdlabel (legacy partition tools)
On 25/01/2024 06:50, Cy Schubert wrote: In message What can they do that gpart can't do? This was quite a while ago, booted off my recovery USB attempting to repair some self caused damage. The ability to edit (vi) a file with starting addresses and lengths, visually using bsdlabel, was suited to my panicked state as I worked to recover the machine. A visual view of columns of a bsdlabel, editing a label using vi, checking and double checking numbers before committing them is handy.The visual format and the ability to adjust the numbers in an editor before committing them is handy. You can't do this with gpart, as it's transactional. And bsdinstall doesn't give one the opportunity to check the numbers in detail on a console before committing them. If you really like your editor of choice to edit partition table, you can use gpart backup and gpart restore like this: gpart backup ada0 > ada0.part vi ada0.part gpart restore -F -l < ada0.part Maybe a good GSoC project may be to replace bsdlabel's driect writes to disk with geom calls. Though, t doesn't need to be bsdlabel, but some kind of utility that displays the existing label in an editor session where changes can be made, using the editor, and committed. This could even be an enhancement to bsdinstall: call it expert mode or whatever. Manipulating partition table in editor session can be achieved by few lines of shell script as a wrapper around gpart backup & gpart restore. Kind regards Miroslav Lachman
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On 04/06/2024 23:52, John Hixson wrote: On Mon, Jun 27, 2022 at 03:27:54PM +0200, Miroslav Lachman wrote: On 16/06/2022 15:56, Rick Macklem wrote: Miroslav Lachman <000.f...@quip.cz> wrote: On 24/01/2022 16:13, Rick Macklem wrote: [...] So, I think Mark and Yuri are correct and looking at up to date Illumos sources is the next step. (As I mentioned, porting the Apple sources is beyond what I am willing to attempt.) rick Hello Rick, I would like to ask you I there is some progress with porting newer SMBFS / CIFS version to FreeBSD? Did you find Illumos sources as a possibility where to start porting? Yes. I have the stuff off Illumos-gate, which I think is pretty up-to-date and I agree that it should be easier than the Apple stuff to port into FreeBSD. I don't think it is "straightforward" as someone involved with Illumos said, due to the big differences in VFS/locking, but... Having said the above, I have not done much yet. I've been cleaning up NFS stuff, although I am nearly done with that now. I do plan on starting to work on it soon, but have no idea if/when I will have something that might be useful for others. I'm glad to hear that. We have more and more problems with current state of mount_smbfs. I would be really glad if "somebody" can do the heroic work of implementing SMBv2 in FreeBSD. Maybe it's time to start some fundraising for sponsoring this work? Well, funding isn't an issue for me (I'm just a retired guy who does this stuff as a hobby). However, if there is someone else who is capable of doing it if they are funded, I have no problem with that. I could either help them, or simply stick with working on NFS and leave SMBv23 to them. Sorry, but I cannot report real progress on this as yet, rick No need to sorry. I really appreciate your endless work on NFS and that you still have kind of interest to try porting SMBv2/3. Unfortunately I don't know anybody else trying to do this tremendous work. I am working on a from scratch implementation of smbfs. I do not have any kind of time estimate since it is in my spare time. I chose this route after spending considerable time looking at Apple and Solaris implementations and wanting something without all of the legacy 1.0 crap. I do have a very minimal working FUSE version at this point, but there is much to do, and even more to abide by the various specifications. I just thought I'd share in case anyone is interested. Thank you for the message. I'm glad someone has the courage to take the plunge. Smbfs is still very important to me. In a heterogeneous environment it is still the most common way to share data between systems. Are you planning the final version as a kernel module, or will the final version be via FUSE? I have had bad experiences with FUSE in the past with stability and performance. Best regards Miroslav Lachman
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On 05/06/2024 01:05, John Hixson wrote: Thank you for the message. I'm glad someone has the courage to take the plunge. Smbfs is still very important to me. In a heterogeneous environment it is still the most common way to share data between systems. Are you planning the final version as a kernel module, or will the final version be via FUSE? I have had bad experiences with FUSE in the past with stability and performance. The final version will be a kernel module. It will also be BSD licensed. I am not an expert at the VFS layer so I want to get the stack ironed out in FUSE before moving it into kernel space. This is really good news. I can't help with the code, but once you get something I can test, let me know. I'd be happy to help with testing. Best regards Miroslav Lachman
Re: exited on signal 11 (no core dump - other error)
On 12/07/2024 07:02, Rick Macklem wrote: On Thu, Jul 11, 2024 at 8:40 PM Zhenlei Huang wrote: Hi I observed something weird on Release 14.1. When rebooting my dev machine, I got ---<>--- Copyright (c) 1992-2023 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 FreeBSD clang version 18.1.5 (https://github.com/llvm/llvm-project.git llvmorg-18.1.5-0-g617a15a9eac9) ... em0: promiscuous mode enabled em0: promiscuous mode disabled Waiting (max 60 seconds) for system process `vnlru' to stop... done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining... 0 0 0 0 done All buffers synced. pid 50599 (devd), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 35393 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 36947 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 37990 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 80885 (sshd), jid 0, uid 1001: exited on signal 11 (no core dump - bad address) pid 79883 (sshd), jid 0, uid 0: exited on signal 11 (no core dump - bad address) pid 14245 (sshd), jid 0, uid 0: exited on signal 11 (no core dump - bad address) pid 49213 (ntpd), jid 0, uid 123: exited on signal 11 (no core dump - other error) pid 37382 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 35315 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 21366 (powerd), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 35735 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 36339 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) pid 37346 (getty), jid 0, uid 0: exited on signal 11 (no core dump - other error) Uptime: 4d1h33m9s ukbd0: detached uhub0: detached ---<>--- IIUC all processes will get signal to quit on system reboot. But what does the signal 11 mean ? Is it EDEADLK in sys/sys/errno.h ? I think signal 11 refers to SIGSEGV (segmentation violation). However, I have no idea why a bunch of processes would do that during shutdown? Something similar happens to me, but when logging into KDE Plasma. Sometimes it happens that desktop applications that start from a saved session (Firefox, Thunderbird, Telegram, Signal...) start loading and then everything crashes. The login screen reappears and when I log in again, everything crashes again until I restart the machine. The machine gets into this state randomly, about once a week. Jul 5 12:24:52 xxx kernel: pid 1647 (packagekitd), jid 0, uid 0: exited on signal 11 (core dumped) Jul 5 12:25:28 xxx kernel: pid 1897 (kalarm), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:36 xxx kernel: pid 1467 (Xorg), jid 0, uid 0: exited on signal 6 (core dumped) Jul 5 12:25:37 xxx kernel: pid 1772 (signal-desktop), jid 0, uid 1001: exited on signal 5 (core dumped) Jul 5 12:25:39 xxx pulseaudio[1630]: [] core-util.c: Failed to create secure directory (/var/run/user/1001/pulse): No such file or directory Jul 5 12:25:40 xxx kernel: pid 1776 (audacious), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:41 xxx kernel: pid 1915 (drkonqi), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:42 xxx kernel: pid 1914 (kwin_x11), jid 0, uid 1001: exited on signal 6 (core dumped) My system is 13.3-p3 amd64. Kind regards Miroslav Lachman
Re: exited on signal 11 (no core dump - other error)
On 12/07/2024 11:56, Tomoaki AOKI wrote: On Fri, 12 Jul 2024 10:20:19 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: [..] Something similar happens to me, but when logging into KDE Plasma. Sometimes it happens that desktop applications that start from a saved session (Firefox, Thunderbird, Telegram, Signal...) start loading and then everything crashes. The login screen reappears and when I log in again, everything crashes again until I restart the machine. The machine gets into this state randomly, about once a week. Jul 5 12:24:52 xxx kernel: pid 1647 (packagekitd), jid 0, uid 0: exited on signal 11 (core dumped) Jul 5 12:25:28 xxx kernel: pid 1897 (kalarm), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:36 xxx kernel: pid 1467 (Xorg), jid 0, uid 0: exited on signal 6 (core dumped) Jul 5 12:25:37 xxx kernel: pid 1772 (signal-desktop), jid 0, uid 1001: exited on signal 5 (core dumped) Jul 5 12:25:39 xxx pulseaudio[1630]: [] core-util.c: Failed to create secure directory (/var/run/user/1001/pulse): No such file or directory Jul 5 12:25:40 xxx kernel: pid 1776 (audacious), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:41 xxx kernel: pid 1915 (drkonqi), jid 0, uid 1001: exited on signal 6 (core dumped) Jul 5 12:25:42 xxx kernel: pid 1914 (kwin_x11), jid 0, uid 1001: exited on signal 6 (core dumped) My system is 13.3-p3 amd64. Kind regards Miroslav Lachman What comes in my mind is... *Hardware problem *Main memory (including memory slot) *Dedicated grhaphics memories, if any (seems that X-related processes are crashing) *Power failures / instabilities *Software problem *Mis-alignments caused by ASLR or something *Bitten by uncommon bugs in fundamental libraries like libc, xcb, glib,... *Not sure it's MFC'ed to 13.x or not, but missingly determined instruction sets for SIMD libc or something alike. I also thought about the memory modules (even though they are ECC), but a few days ago I replaced them with 4 other modules from the server and the problem persisted. Of course it could be anything else (graphic card, power supply, etc.), but it's strange that it only happens after booting when logging into KDE. When everything crashes and the login screen reappears, I try to log in again, everything crashes again (usually in the part where Signal Desktop starts, but I don't know if it's related). I can repeat this 5 or 10 times, but until I reboot, KDE doesn't fully start. When I reboot, the machine runs all day, even for several days at a time. It also happens that the screenlocker crashes Jul 11 17:32:16 xxx kernel: pid 6487 (kscreenlocker_greet), jid 0, uid 1001: exited on signal 11 Jul 11 17:32:16 xxx kernel: pid 6489 (kscreenlocker_greet), jid 0, uid 1001: exited on signal 11 Then I have to log in as root via Ctrl+Alt+F2 and run: ck-unlock-session Session1 Otherwise, when KDE is running, all applications work without crashing. Translated with DeepL.com (free version) Kind regards Miroslav Lachman
Re: exited on signal 11 (no core dump - other error)
On 12/07/2024 18:45, Tomoaki AOKI wrote: On Fri, 12 Jul 2024 14:35:15 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: On 12/07/2024 11:56, Tomoaki AOKI wrote: [..] *Hardware problem *Main memory (including memory slot) *Dedicated grhaphics memories, if any (seems that X-related processes are crashing) *Power failures / instabilities *Software problem *Mis-alignments caused by ASLR or something *Bitten by uncommon bugs in fundamental libraries like libc, xcb, glib,... *Not sure it's MFC'ed to 13.x or not, but missingly determined instruction sets for SIMD libc or something alike. I also thought about the memory modules (even though they are ECC), but a few days ago I replaced them with 4 other modules from the server and the problem persisted. Of course it could be anything else (graphic card, power supply, etc.), but it's strange that it only happens after booting when logging into KDE. When everything crashes and the login screen reappears, I try to log in again, everything crashes again (usually in the part where Signal Desktop starts, but I don't know if it's related). I can repeat this 5 or 10 times, but until I reboot, KDE doesn't fully start. When I reboot, the machine runs all day, even for several days at a time. It also happens that the screenlocker crashes Jul 11 17:32:16 xxx kernel: pid 6487 (kscreenlocker_greet), jid 0, uid 1001: exited on signal 11 Jul 11 17:32:16 xxx kernel: pid 6489 (kscreenlocker_greet), jid 0, uid 1001: exited on signal 11 Then I have to log in as root via Ctrl+Alt+F2 and run: ck-unlock-session Session1 Otherwise, when KDE is running, all applications work without crashing. Kind regards Miroslav Lachman Could MySQL related? IIRC, KDE defaulted its backend (for akonadi) to MySQL. If you're using MySQL for something other than KDE, too, and any of the database is/are heavily updated, is there any possibility that MySQL cannot flush/commit pending transactions in time? I already disabled all MySQL related services right after KDE installation. MySQL is also disabled in rc.conf, nothing needs it. The machine in question has 24GB of RAM and 8GB of swap. OS is installed on top of Samsung SSD 860 EVO 1TB. So it should be fast enough to run KDE5 Plasma desktop (it actually runs KDE for a years), these crashes first appeared after some pkg upgrade this year. I don't pkg upgrade too often because it almost always come with some apps incompatibilities etc.. But the last pkg upgrade was done about a week ago and crashes are still there. Kind regards Miroslav Lachman
Re: filemon
On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
Gary Jennejohn writes:
[..]
I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option is to include "filemon" in the kld_list variable in /etc/rc.conf
or /etc/rc.conf.d/kld. For instance,
% cat /etc/rc.conf.d/kld/filemon
kld_list="${kld_list} filemon"
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any problems
it used to solve are solved, and that the preferred way is to load
everything from loader.conf. So I'm curious, what's the right thing to
do then? (I load most of my modules from rc.conf)
Kind regards
Miroslav Lachman
Re: filemon
On 30/07/2024 14:55, Michael Gmelin wrote: On Tue, 30 Jul 2024 11:38:57 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: [..] Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, and that the preferred way is to load everything from loader.conf. So I'm curious, what's the right thing to do then? (I load most of my modules from rc.conf) I think this is what you're referring to, quoting Warner (emphasis is mine): https://lists.freebsd.org/archives/freebsd-current/2024-May/005953.html w> Also, in this case, kld_list is a terrible place to load the files. w> You're better off loading them with xxx_load=YES in loader.conf. The w> reason is that both uhid and ums will match your mouse. kld_list w> loads these in a random order (effectively) and the first one to w> load will claim the device, since there's no re-probe when the next w> one loads. **You should never use it, unless the module you're w> loading isn't supported by the boot loader (like drm-kmod)**. The old w> advice was to put everything in kld_list and it would speed up boot, w> but all the performance bugs in the boot loader have been fixed by a w> combination of moving to UEFI (which is generally faster), BIOSes w> with performance bugs disappearing 10 years ago and block caching w> being added to the boot loader. It should almost always be empty or w> just drm-mod these days (unless you somehow have special needs). w> w> By adding uhid last to this list in this way, you're guaranteeing w> you'll hit this bug because it's not after ums, and that things w> won't work. w> w> Warner Cheers Yes, this is it! I didn't remember the subject, so I couldn't find it. Thank you for the original message! Kind regards Miroslav Lachman
Re: filemon
On 30/07/2024 12:31, Dag-Erling Smørgrav wrote: Miroslav Lachman <000.f...@quip.cz> writes: Dag-Erling Smørgrav writes: This does cause the module to be loaded at boot time, but it's slower than loading it later, and it increases memory fragmentation. Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, Loader I/O performance is much better these days so loading modules pre-boot doesn't slow the boot down much any more, but it's still more than zero, and it still increases low memory fragmentation, and you still can't unload a module that was loaded pre-boot. and that the preferred way is to load everything from loader.conf. I suspect you're extrapolating here. There is a very small number of cases where loading pre-boot is required (e.g. zfs.ko if your root is on zfs) or recommended (e.g. USB HID drivers due to probe ordering issues) but in the majority of cases, it is still better (even if only slightly) to wait until after boot. Thank you for the explanation. I will continue to use kld_list. Kind regards Miroslav Lachman
Re: filemon
On 30/07/2024 16:30, Warner Losh wrote: [..] Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, and that the preferred way is to load everything from loader.conf. So I'm curious, what's the right thing to do then? (I load most of my modules from rc.conf) Either or for filemon. Either rc.conf's kld_list or loader.conf's filemon_load=YES. I've been recommending loader.conf since there's slightly less memory fragmentation, but even that effect is small. Only drm kmod has to be in kld_list. I'm a bit confused. If I understand it right, you say loader.conf causes less memory fragmentation, but DES said "it still increases low memory fragmentation". So what is true? And is this something to watch out for, or is memory fragmentation not such a big deal? Kind regards Miroslav Lachman
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 05/08/2024 18:50, Dennis Clarke wrote: On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. I have seen cirrina some time ago. I was interested in GUI. Main page shows: Run Clients GUI Start weasel Create switch Create VM Add Disk Add NIC Upload ISO Select VM, click edit, add disk, iso and nic to VM Start VM But what is weasel / how can I start it? I see only cirrinad and cirrinactl. Kind regards Miroslav Lachman
Re: Copying to a new computer
@lbutlr wrote on 2018/01/16 00:12: I am replacing an old machine with a newer machine and I want to be sure I can move the shell users to the new machine, especially since I am mostly going too be setting up the machine as new. What are the minimal files that I need to copy over so that the users and groups from the old machine are on the new machine and without having to reset all the passwords? (Most the users are in sql databases, so that's not an issue, but there are a few with shell accounts, those are the ones I'm concerned with. I was intending to stick with v11.1 at this point. You can copy these files: /etc/group /etc/login.conf /etc/master.passwd /etc/passwd And DB files /etc/login.conf.db /etc/pwd.db /etc/spwd.db Or you can recreate them with pwd_mkdb and cap_mkdb (see their man pages) If you installed some shells like bash or zsh for users, then you must installed them too and verify /etc/shells settings. Additionally you may need a copy of /etc/profile and /etc/csh.cshrc if you modified them. Miroslav Lachman ___ 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: two NIC's in a jail
Joerg Surmann wrote on 2018/03/23 13:49:
Hi all,
I have a Problem to understund how to manage 2 Networks inside a Jail.
i have create a jail (using ezjail) with a alias IP.
in rc.conf (on Host):
ifconfig_vmx0="inet 192.168.100.1 netmask 255.255.255.0"
ifconfig_vmx0_alias0="inet 192.168.100.2 netmask 255.255.255.0" <- this
is the jail ip
Inside the jail running apachhe24.
Now i add a new NIC to the System.
in rc.conf (on Host):
ifconfig_em0="inet 213.70.80.92 netmask 255.255.255.0"
in /usr/local/etc/ezjail/myjail.conf:
i add the new ip
export jail_myjail_ip="192.168.100.2,213.70.80.92"
Restart the jail and ifconfig looks fine.
vmx0 -> inet 192.168.100.2
em0 -> inet 213.70.80.92
Apache Listen on all NIC's ()
But i can see my Website only via 192.168.100.2 from intern Network.
The Host is behind a Firewall.
The IP 213.70.80.92 is enabled for incomming Traffic.
When i give the Hostname in a Browser i become "connection Timeout".
What is to do that the Host is accessable from Inet?
Are you sure Apache is listening on both IPs?
What netstat says?
# netstat -an | egrep 'tcp4.*80 .*LISTEN'
Also check what you have in httpd.conf for Listen directive
# grep -i Listen /usr/local/etc/apache24/httpd.conf
I am not using ezjail, I am using jail.conf
costa {
host.hostname = "costa.example.com";
ip4.addr= AA.BB.CCC.DDD;
ip4.addr += 192.168.222.57;
}
Real IP was replaced with AA.BB.CCC.DDD
And it works. Services inside jail must be listening on both IPs or
wildcard * (0.0.0.0)
And be sure to disable hosts services to listen on IPs and ports you
want to be served from jail.
Miroslav Lachman
___
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: two NIC's in a jail
Joerg Surmann wrote on 2018/03/23 16:45:
Thanks for replay.
netstat -an | egrep 'tcp4.*80 .*LISTEN'
say:
netstat: kvm not available: /dev/mem No such file or directory <- is
inside a jail.
tcp4 0 0 *.80 *.* LISTEN
grep -i Listen /usr/local/etc/apache24/httpd.conf
Listen 80
Listen 443
From the internal IP is no Problem.
You are right. I'm not sure on wich IP's Apache is listening.
I have change the Listen directive to the external IP in httpd.conf
Listen 213.70.80.92:80
netstat -an | egrep 'tcp4.*80 .*LISTEN'
now say:
tcp4 0 0 213.70.80.92:80 *.* LISTEN
But apache is not availble from Internet.
From Intranet... no Problem.
When i use tcpdump on Host i can see Traffic.
Whats wrong?
That's strange.
Listen 80 and Listen 443 is OK, it is the same as
Listen *:80
Listen *:443
and as you see with netstat, Apache was listening on both IPs:
*.80*.*LISTEN
Do you have something listening on port 80 in the Host?
What netstat shows in the host?
Also check Apache log files. If you didn't configure virtual host, then
you have just these two log files:
/var/log/httpd-access.log
/var/log/httpd-error.log
Use tail and then try to access your website from the internet
# tail -f /var/log/httpd-*.log
Please send what "jls -v" in the Host will show you. (there should be 2
IPs for your jail) or "jls -s" (replace any sensitive informations if
you want)
And move this discussion to proper mailing list:
freebsd-j...@freebsd.org
Miroslav Lachman
Am 23.03.2018 um 16:07 schrieb Miroslav Lachman:
Joerg Surmann wrote on 2018/03/23 13:49:
Hi all,
I have a Problem to understund how to manage 2 Networks inside a Jail.
i have create a jail (using ezjail) with a alias IP.
in rc.conf (on Host):
ifconfig_vmx0="inet 192.168.100.1 netmask 255.255.255.0"
ifconfig_vmx0_alias0="inet 192.168.100.2 netmask 255.255.255.0" <- this
is the jail ip
Inside the jail running apachhe24.
Now i add a new NIC to the System.
in rc.conf (on Host):
ifconfig_em0="inet 213.70.80.92 netmask 255.255.255.0"
in /usr/local/etc/ezjail/myjail.conf:
i add the new ip
export jail_myjail_ip="192.168.100.2,213.70.80.92"
Restart the jail and ifconfig looks fine.
vmx0 -> inet 192.168.100.2
em0 -> inet 213.70.80.92
Apache Listen on all NIC's ()
But i can see my Website only via 192.168.100.2 from intern Network.
The Host is behind a Firewall.
The IP 213.70.80.92 is enabled for incomming Traffic.
When i give the Hostname in a Browser i become "connection Timeout".
What is to do that the Host is accessable from Inet?
Are you sure Apache is listening on both IPs?
What netstat says?
# netstat -an | egrep 'tcp4.*80 .*LISTEN'
Also check what you have in httpd.conf for Listen directive
# grep -i Listen /usr/local/etc/apache24/httpd.conf
I am not using ezjail, I am using jail.conf
costa {
host.hostname = "costa.example.com";
ip4.addr = AA.BB.CCC.DDD;
ip4.addr += 192.168.222.57;
}
Real IP was replaced with AA.BB.CCC.DDD
And it works. Services inside jail must be listening on both IPs or
wildcard * (0.0.0.0)
And be sure to disable hosts services to listen on IPs and ports you
want to be served from jail.
___
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: how to make ports not install xorg or dependencies
tech-lists wrote on 2018/07/31 12:41: There used to be a way to enforce this no-xorg in make.conf but looking at /usr/share/examples/etc/make.conf I can find no reference to X Xorg x11 or xorg. I presume there's a new method. If there is, can anyone please tell me how? We are using OPTIONS_UNSET= X11 GUI CUPS DOCS EXAMPLES NLS for all of our packages (built with poudriere) As Guido Falsi already said it is not guaranteed that you will not have ports with some X libs, because some ports does not have option to disable X11 dependencies. Miroslav Lachman ___ 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: Sharing compiled builds between multiple 12-CURRENT boxes.
Dhananjay Balan wrote on 2018/08/19 00:34: Hi, I run 12-CURRENT on few machines, some more powerful that other (all of them x86_64, march varies). Is there is a way to avoid building CURRENT on all machines? Rather than building everywhere, can I just build it on the big server that I have and copy and update my laptop? Yes and we are using it (for STABLE, but it works for all versions). You can build it on you build server and export it with NFS. https://www.freebsd.org/cgi/man.cgi?query=development&sektion=7 Miroslav Lachman ___ 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: Supermicro X9SCV-Q: no boot options to define
Hartmann, O. wrote on 2019/12/11 19:07: The AMI BIOS is at 2.10.1208 from 4th Nov 2012. There is a newer firmware available, but I can't install the firmware: while being able to UEFI USB flahes, it is impossible to boot FreeDOS 1.1 from an USB flash drive, even having properly set Legacy Boot ROM in PCIe/PnP/etc options in the firmware. I never have had such a confusing BIOS/firmware. Did you try to boot some ISO media through IPMI remote media option? I don't know if X9SCV-Q have this option. I have X9SCA-F which is somewhat different than yours. Miroslav Lachman ___ 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: TLS certificates for NFS-over-TLS floating client
Hiroki Sato wrote on 2020/03/04 05:35: [...] I do not think it is a good idea to use a certificate with an embedded secret for authentication and/or authorization. In the case that the client offers a certificate upon establishing a TLS connection for authentication purpose, the authenticity will be checked on the server usually by using the CA certificate which was used to issue the client certificate. The CA cert must be put to somewhere the NFS server can read. The CA cert is secret. So if the NFS server can check the client certificate by the CA certificate, it means the NFS server can trust the client. I think no additional information is required. NFS (or any other server) should check list of revoked certificates too. Otherwise you will not be able to deny access to user which you no longer want to have an access. Authorization such as which mount point can be mounted by using the client cert can be implemented by using the CN field or other X.509 attributes, of course. It can be just a clear text. I think this is one of the most reliable and straightforward ways because in most cases both NFS servers and the clients are under the sysadmin's control. rm> Now, I'm not sure, but I don't think this certificate can be created via rm> a trust authority such that it would "verify". However, the server can rm> look for the "secret" in the certificate and allow the mount based on that. In the way described above, to use TLS client authentication, the NFS server admin has to have a certificate which allows to sign another certificate. This means that the admin must be a CA or trusted authority. In practice, one can generate a self-signed certificate by using openssl(1) and use it as its CA certificate. He can issue certificates signed by it for the NFS clients, and put his CA certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. rm> Also, even if the NFS client/server have fixed IP addresses with well known rm> DNS names, it isn't obvious to me how signed certificates can be acquired rm> for them? rm> (Lets Encrypt expects the Acme protocol to work and that seems to be rm> web site/http specific?) TLS certificates do not always have (or do not need to have) a domain name as an attribute. Data in attributes are restricted depending on the purpose, so certificates issued by Let's Encrypt can have only domain names (CN or Subject Alternative Name), for example. An example which is not supported by Let's Encrypt is a certificate for S/MIME email encryption which has an email address. Kind regards Miroslav Lachman ___ 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: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote on 2020/03/19 03:09: Miroslav Lachman wrote: [...] NFS (or any other server) should check list of revoked certificates too. Otherwise you will not be able to deny access to user which you no longer want to have an access. Yes, good point. I won't claim to understand this stuff, but from what I can see, all that is done is the CRL is appended to the CAfile (the one with the CA certificates are in being used for certificate verification via SSL__CTX_load_verify_locations(). (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html shows a CAfile and CRLfile being concatenated and then used to verify a certificate.) There is code in sendmail that loads a CRL file separately, but it seems to just put it in the X509 store returned by SSL_CTX_get_cert_store(), which is the one where the CAfile certificates are stored via SSL_CTX_load_verify_locations(), I think? (It just seems easier to append it to CAfile than do this. The sendmail code uses poorly documented functions where the man page says "SSL_CTX_load_verify_locations()" normally takes care of this.) Does this sound right? rick I think it would be better to have it in a separate file as Apache does https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationfile Seems more convenient to have CA file write protected (read only) and then separate file for list of revoked client certificates, maybe somewhere else than CA certificate. Kind regards Miroslav Lachman ___ 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: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote on 2020/03/20 20:29: Rick Macklem wrote this message on Thu, Mar 19, 2020 at 23:41 +: [...] Without a problem statement or what you're trying to accomplish, it's hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed Yes, I totally agree w/ this as the best solution. It also allows private hostnames to be used w/o leaking outside the org.. It'd be nice to have better tooling around the CA though. I still haven't found any good tools that make a CA simple to use for small installs... (and by simple, I mean single init command, and single command to issue a cert or generate a key/cert pair, all of them are like, make all thesse directories, edit these files, and run these comlicated commands) security/easy-rsa is very close to this. # easyrsa init-pki # easyrsa build-ca # easyrsa build-server-full # easyrsa build-client-full # easyrsa build-client-full # easyrsa build-client-full or # easyrsa build-client-full nopass And usually # easyrsa gen-dh With "build-ca" you will create key and certificate for you private CA With "build-server-full" you will create key and certificate for your server With "build-client-full" you will create key and certificate for clients It also supports "revoke" and "gen-crl" to revoke compromised certificate and update CRL. Yes, it could be made a bit simpler and run init-pki in the background if build-ca is run for the first time so you can save one step. I don't say easy-rsa is the best choice. I am able to use full openssl commands or write my own tools / scripts around it I choose easy-rsa on machines where somebody else needs to work with certs. [...] Kind regards Miroslav Lachman ___ 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"
PCIe NVME drives not detected on Dell R6515
I already asked on stable@ but as I tried it on 13-CURRENT with the same result I am trying to ask for help here. I have rented dedicated server Dell PowerEdge R6515 with iDRAC access only. There are 2 NVME drives which I wanted to use as ZFS root pool. They are shown in iDRAC Device Description: PCIe SSD in Slot 1 in Bay 1 Device Protocol: NVMe-MI1.0 Model:Dell Express Flash NVMe P4510 1TB SFF Bus: 130 Manufacturer: INTEL Product ID: a54 Revision: VDV1DP23 Enclosure:PCIe SSD Backplane 1 pciconf -l show many things, some of them are named "noneN@pci..." but none "nvme" The is printscreen (12.1 but 13-CURRENT is the same) https://ibb.co/tPnymL7 But I booted Linux SystemRescueCd and nvme devices are there visible in /dev/ https://ibb.co/sj22Nwg There is verbose output of Linux lspci https://ibb.co/dPZTwV1 Linux dmesg contains: nvme nvme0: pci function :81:00.0 nvme nvme1: pci function :82:00.0 nvme nvme0: 32/0/0 default/read/poll queues nvme nvme1: 32/0/0 default/read/poll queues The machine is Dell PowerEdge R6515 with AMD EPYC 7302P More details extracted from iDRAC web interface I found this informations PCIe SSD in Slot 1 in Bay 1 Bus: 82 BusProtocol: PCIE Device: 0 DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceProtocol: NVMe-MI1.0 DeviceType: PCIeSSD DriveFormFactor: 2.5 inch FailurePredicted: NO FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FreeSizeInBytes: Information Not Available Function: 0 HotSpareStatus: Information Not Available InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 Manufacturer: INTEL MaximumCapableSpeed: 8 GT/s MediaType: Solid State Drive Model: Dell Express Flash NVMe P4510 1TB SFF NegotiatedSpeed: 8 GT/s PCIeCapableLinkWidth: x4 PCIeNegotiatedLinkWidth: x4 PrimaryStatus: Ok ProductID: a54 RaidStatus: Information Not Available RAIDType: Unknown RemainingRatedWriteEndurance: 100 % Revision: VDV1DP23 SerialNumber: PHLJxxWF1PN SizeInBytes: 1000204886016 Slot: 1 State: Ready SystemEraseCapability: CryptographicErasePD PCIe SSD in Slot 1 in Bay 1 - PCI Device BusNumber: 130 DataBusWidth: 4x or x4 Description: Express Flash NVMe 1.0 TB 2.5" U.2 (P4510) DeviceDescription: PCIe SSD in Slot 1 in Bay 1 DeviceNumber: 0 DeviceType: PCIDevice FQDD: Disk.Bay.1:Enclosure.Internal.0-1 FunctionNumber: 0 InstanceID: Disk.Bay.1:Enclosure.Internal.0-1 LastSystemInventoryTime: 2020-04-17T03:21:39 LastUpdateTime: 2020-03-31T13:55:06 Manufacturer: Intel Corporation PCIDeviceID: 0A54 PCISubDeviceID: 2003 PCISubVendorID: 1028 PCIVendorID: 8086 SlotLength: 2.5 Inch Drive Form Factor SlotType: PCI Express Gen 3 SFF-8639 Can anybody shed some light what the real problem is? Is the hardware not properly detected or is the driver completely missing? NVME PCIe architecture is out of my knowledge. I really appreciate any help. Kind regards Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 17:38: Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? I have only iDRAC access to this machine, I cannot copy or export text. Can I send you printscreen images? Thank you! Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 17:54: Would that be the Intel VMD/VROC stuff? If so, there’s a driver for FreeBSD, but it’s not well tested yet. Will have to dig in further. This is AMD EPYC machine. Isn't VROC Intel only thing? On Apr 17, 2020, at 9:50 AM, Warner Losh wrote: On Fri, Apr 17, 2020 at 9:39 AM Scott Long wrote: Can you send me the output of ‘pciconf -llv’, either in 12-STABLE or 13-CURRENT? Also, can you send me the output of ‘dmesg’? There was another thread that said there was a raid card in the way... It would be cool to find a way to get it out of the way... :) I didn't find any evidence of RAID card but maybe I cannot look for it. Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Warner Losh wrote on 04/17/2020 18:15: No. It was some kind of extra card (Perteq?) managing things in a Dell server. It may be the VMD/VROC stuff, and that driver may be worth a shot, but I'm thinking not. It looks like Doug's code for that is in the tree, though https://reviews.freebsd.org/rS353380. Or are other changes needed? I've been blessed with either being able to turn this off, or not having to deal... vmd is in the kernel of 13-CURRENT installer I tried but I don't see any vmd device. Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 21:18: On Apr 17, 2020, at 11:46 AM, Miroslav Lachman <000.f...@quip.cz> wrote: Scott Long wrote on 04/17/2020 18:17: You are correct about Intel vs AMD. Comparing the full output of pciconf from FreeBSD with the fragment of lspci from Linux suggests that there’s at least one set of a PCIe switch and child devices that is not being enumerated by FreeBSD. Can you send the full output of `lspci -tvv` from linux? Sorry for my late reply. Booting the Linux SystemRescueCd is too slow. lspci -tvv output is attached I tried to connect to SOL by SSH but it shows black screen only. lspci shows drives: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] Kind regards Miroslav Lachman It looks like pcib12 and pcib13 in FreeBSD should be the bridges that have the NVMe devices behind them, but those devices aren’t showing up. I don’t see any obvious code in linux to handle those bridges, so there must be something subtle that we’re missing in FreeBSD. Maybe we’re having trouble enumerating above PCI bus 128? I think that was a problem a few years ago but I also thought it was fixed. Can you do the following in FreeBSD: pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Anything else I can provide? Thank you Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman ___ 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: PCIe NVME drives not detected on Dell R6515
Scott Long wrote on 04/17/2020 22:17: On Apr 17, 2020, at 1:47 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Kurt Jaeger wrote on 04/17/2020 21:44: Hi! pciconf -lBc pcib12 pciconf -lBc pcib13 Printscreen attached. Attachments are stripped from the list -- can you put them somewhere online ? Here it is https://ibb.co/c1dZrTf Miroslav Lachman Ok, the bridges know about their downstream bus numbers, but I see nothing that suggests that they’re being probed. The next step would be bootverbose, but that’s going to be a lot of output to collect in screen captures. Over 3000 lines long but I finally managed to make SOL work so I have it as text! https://pastebin.pl/view/90fdaafb Miroslav Lachman ___ 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"
