Re: a zfs thank you :)
On Tue, Aug 20, 2024 at 12:18 AM Steffen Nurpmeso wrote:
>
> Jan Bramkamp wrote in
> :
> |On 31.07.24 17:02, void wrote:
> |> I was pleasantly surprised when I installed a new [1] zfs-on-root
> |> -current
> |> to rpi4 that when adduser was invoked, I was given the option to
> |> encrypt the homedir. This is a great feature for my context [2].
> |>
> |> It doesn't automount on boot but I think this is more of a feature
> |> rather than a bug. One can have a different password to the GELI one used
> |> to boot up the whole system.
> |>
> |> I have not tested yet whether one can have the user, once logged in,
> |> mount
> |> their homedir with doas(1). Right now, I mount the homedir like so:
> |>
> |> zfs load-key -a (prompts for password)
> |> zfs mount -a
> |>
> |> as root.
> |>
> |> I could I guess make a doas line for the user for zfs load-key -r
> |> zfsfile/system.
> |> Can anyone suggest any better ideas please?
>
> |There is the pam_zfs_key.so PAM session module that should do exactly
> |what you're looking for if your users login with a password. It should
> |similar to the pam_ssh.so module if you're already familiar with that
> |one. Unless users provide the password there isn't much file system or
> |disk encryption can do for you against hardware theft since the
> |Raspberry Pi doesn't have any secure key storage nor would the kernel be
> |able to know when it has been stolen and stop auto-loading the keys.
>
> To suggest a screen locker for "warm" security.
> Ie here this is (on Linux, in /root/bin/zzz.sh upon lid close etc)
>
> if command -v X >/dev/null 2>&1 && command -v slock >/dev/null 2>&1; then
> had_z=
> for p in $(pgrep X); do
> uid=$(awk '/^Uid:/{print $2}' < /proc/$p/status)
> disp=$(sed -Ee 's/^.*DISPLAY=:([[:digit:]]+).*$/\1/' <
> /proc/$p/environ)
> [ -z "$disp" ] && disp=$(xargs -0 printf '%s\n' <
> /proc/$p/cmdline |
> awk '/^:[[:digit:]]+/{sub(":", ""); print}')
> if [ -z "$disp" ]; then
> [ -n "$had_z" ] && continue
> had_z=y
> disp=0
> elif [ $disp = 0 ]; then
> [ -n "$had_z" ] && continue
> had_z=y
> fi
> act "DISPLAY=:$disp $SUPER -u $uid slock >/dev/null 2>&1 &"
> done
> fi
>
> Unfortunately there is no other easy way i know to lock all
> X sessions otherwise.
>
> This is the problem i have with "encrypted home directories" per
> se, i do not use that, but have several encfs directories, like,
> say, ~/.sec.arena, which i mount via fuse as a normal user, and
> $HOME is nothing but a symlink farm like
> .xinitrc -> sec.arena/configs.git/home/.xinitrc
> so before i mount this that is all hollow.
> The zzz.sh script also does (simplified)
>
> if command -v encfs >/dev/null 2>&1; then
> grep encfs /proc/mounts | cut -d ' ' -f 2 | {
> while read line; do
> act "{ sync $line/.; umount $line; } >/dev/null 2>&1 &"
> done
> }
> fi
>
> so that all these are unmounted upon LID close etc. (Unless some
> process uses any directory within as CWD/pwd(1), then not. Force
> unmounting does not work.)
>
> Ie that is all pretty uncomfortable (it is even more complicated
> in practice), but like this data i care of a bit more is not
> mounted when the LID is opened. (And data i really need to take
> care off is never mounted all the time. And "of course" the hard
> disk partition as such is also "cold" encrypted.)
>
> Ie, i just feel better that way. If you steal the laptop you can
> switch to another console, and, i mean, here is no automounter for
> USB sticks or what, no code runs then (i hope), but i do not know,
> but anyway, if all that time an encrypted home directory of myself
> would be unencrypted, that feels a bit odd.
>
> Anyhow. To remark that PAM sessions can easily be bypassed by any
> shell script (script /dev/null 2>&1 &), and, i looked
> at the ZFS PAM module in particular a few years ago, it did not
> do anything REAPER-alike by then. That is "script" may be running
> when the ZFS user logs out, and the PAM module will then likely
> unmount the ZFS home directory.
> One should at least hear about this situation once.
>
> It would be cool if the PAM implementations i know (Open and
> Linux) would consider adding a dedicated session reaper, with all
> session related modules stopping doing lots of dances, but instead
> relying on some generic PAM library support mechanism.
> Sounds a bit like a sophisticated and relevant Google Summer of
> Code or something project.
It feels like you're reimplementing ConsoleKit. I'm not sure if it can
react to lid closing out of the box, but it manages sessions and
locks/unlocks them depending o
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Wed, Jun 5, 2024 at 12:52 AM John Hixson wrote: > > 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. > > - John Thanks for sharing. We're building a FreeBSD based product and SMB2/3 support is very important to us. Maybe we can combine our efforts on this matter? I also contacted the FreeBSD Enterprise Working Group about this. The Greg's reply was > The verbal offer to donate an up to date fork of this still stands, but the > timing remains unclear. I continue asking. It is still unclear to me if the code is already written by some party and now the negotiation is going on about licensing it as BSD.
Re: CURRENT on laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230
On Wed, Mar 27, 2024 at 12:38 PM Matthias Apitz wrote: > > > Hello, > > I bought the laptop ASUS VivoBook Pro 14 90NB0VZ2-M01230 and managed to > boot FreeBSD with boot verbose messages from an USB key and I'm able to > login. The /var/log/messages are here > http://www.unixarea.de/ASUS-VivoBook-Pro-14-messages.txt `pciconf -lv` would be useful too.
Re: amd64 SIMD libc work has landed
On Mon, Dec 25, 2023 at 5:38 PM Robert Clausecker wrote: > > Greetings! > > I am happy to announce that the FreeBSD Foudation sponsored amd64 libc > SIMD enhancement work has landed in CURRENT following extensive testing. > > Big thanks to all those who assisted in testing and reviewing the > changes, especially to mjg@ and kib@. Congratulations on concluding this project. > If there are any problems resulting from this changeset, please do not > hesitate to file a bug report. So, to try this out it is enough to just "git pull && make buildworld && make buildkernel" ? > ... at run time by setting the environment variable ARCHLEVEL to "scalar" > (using hand-written scalar assembly implementations instead) or at > compile time by building world WITHOUT_MACHDEP_OPTIMIZATIONS. Whoa, I'm excited to see the knob I introduced getting more use cases.
Re: port www/qt5-webengine fails reproducible at the same place compilation
On Thu, Sep 21, 2023 at 4:47 PM Matthias Apitz wrote: > > Should I file a new PR? You should check git log: https://cgit.freebsd.org/ports/commit/?id=190bd2d090115c5c38661198d16fd55288aeb9c1 This commit is just several commits later than the one you're building.
OpenSSL 3 ports fallout
Some of the ports I'm using are failing to build after OpenSSL 3 import due to the following problem. OpenSSL headers that are shipped in base contain declarations of various deprecated functions for which libcrypto.so doesn't contain definitions. Some of them are RSA_generate_key and ERR_* family. These declarations aren't guarded by any #ifdef and are visible for ports software. VirtualBox and net-p2p/cardano-node detect these functions, try to use them and then fail to link due to undefined references. I believe this should be fixed in the base rather than patching each port?
Re: Deprecating smbfs(5) and removing it before FreeBSD 14
On Thu, Oct 28, 2021 at 6:39 PM Miroslav Lachman <000.f...@quip.cz> wrote: > I am working for one company where smbfs is heavily used to connect > Windows / MacOS / Linux / FreeBSD (12.2) machines and we are really sad > that FreeBSD's mount_smbfs does not support SMBv2 / SMBv3 protocols (so > we are using SMBv1 with all the risk). I tried fusefs alternatives from > the ports tree in the past but it never worked as is needed. From our > point of view smbnetfs cannot replace mount_smbfs. > I cannot found any good examples of how to configure it to mount about > 20 shares from /etc/fstab on boot as user root from different hosts with > different login, passwords and mount options to defined mount points. > Everything seems to be very differently designed to work for non-root > user with configuration in users home, not system wide and mounting in > some strange hierarchy. (and bad performance was cited by many on other > platforms too) > It was discussed in the past in some other FreeBSD mailinglist that it > is not so easy to implement SMBv2 in to mount_smbfs. But is there any > possibility to make it as some sponsored work? What about FreeBSD > Foundation? There were some paid projects in the past. Or some other > bounty program. Is there anybody who have the skill to implement it if > there is good amount of $? > > If I am "well informed" FreeBSD is the only widely used OS not > supporting SMBv2. (MacOS, Linux, Solaris have it supported) > I will be really glad "if somebody can fix it" in the base. > > (or at least document how to use smbnetfs the way mount_smbfs is used) > > Kind regards > Miroslav Lachman > > I'm also aware of a local company that actively uses smbfs. Removing it would probably cause them to switch to Linux, which is a pity.
Re: Alternate Screen
On Sat, May 15, 2021 at 11:07 PM Kevin Oberman wrote: > We went through this "alternate screen" thing about 12 or more years ago > and almost everyone hated it except those used to Linux behavior. I don't > think it ever made it into a release after all of the screams of pain. It > drives me crazy when editing on the Linux Mint VM I run from time to time. > I've never been able to figure out why anyone would find it an improvement > an I suspect it was inserted in some Unix code back in the days of the > VT100 or VT220 terminal which were super popular and supported it. I guess > it's because someone thought it was a cool thing and that terminal based > editors were the perfect use. > > In any case, please make it STOP! > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkober...@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > Sorry for the noise, but in my case it turned out to be specific to my terminal emulator - Konsole. It has an option called "reflow lines when terminal resized". Turning it off restored an old behavior for me. ___ 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: Alternate Screen
On Thu, May 13, 2021 at 5:02 PM Eric van Gyzen wrote: > There was a recent discussion about a terminal database update and the > new Alternate Screen behavior. I'm curious about the resolution, but I > can't find that discussion. Would someone kindly send a clue-by-four > via overnight express? > > Ultimately, I'd like to know how to get the old behavior back, with no > alternate screen, and thereby reduce my blood pressure. > When I enter `ee`, I can't scroll in my Konsole window anymore. Instead, the cursor inside the text editor is moving. Is this relevant to that "alternate screen" problem? ___ 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: CURRENT crashes at early boot on Lenovo T540p: rtsx to blame - 13.0-RELEASE crashes same way!
Just to add to this thread: I'm running CURRENT with rtsx device and driver and it works fine for me. ___ 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: 13.0 RC4 might be delayed
On Mon, Mar 29, 2021 at 4:37 AM David G Lawrence via freebsd-current < freebsd-current@freebsd.org> wrote: > > > On 27/03/21 06:04, David G Lawrence via freebsd-current wrote: > > >>> On Fri, Mar 26, 2021 at 1:01 PM Graham Perrin < > grahamper...@gmail.com> > > >>> wrote: > > >>> > > On 26/03/2021 03:40, The Doctor via freebsd-current wrote: > > > ??? if people are having issues with ports like ??? > > > > If I'm not mistaken: > > > > * 13.0-RC3 seems to be troublesome, as a guest machine, with > > emulators/virtualbox-ose 6.1.18 as the host > > > > * no such trouble with 12.0-RELEASE-p5 as a guest. > > > > I hope to refine the bug report this weekend. > > > > >>> > > >>> Had nothing but frequent guest lockups on 6.1.18 with my Win7 > system. > > >>> That > > >>> was right after 6.1.18 was put into ports. Fell back to legacy (v5) > and > > >>> will try again shortly to see if it's any better. > > >> > > >> Kevin, > > >> > > >> ?? Make sure you have these options in your /etc/sysctl.conf : > > >> > > >> vfs.aio.max_buf_aio=8192 > > >> vfs.aio.max_aio_queue_per_proc=65536 > > >> vfs.aio.max_aio_per_proc=8192 > > >> vfs.aio.max_aio_queue=65536 > > >> > > >> ?? ...otherwise the guest I/O will random hang in VirtualBox. > This > > >> issue was > > >> mitigated in a late 5.x VirtualBox by patching to not use AIO, but > the > > >> issue > > >> came back in 6.x when that patch wasn't carried forward. > > > > > > Sorry I lost that patch. Can you point me to the patch? Maybe it can > be > > > easily ported. > > > > > > > I found the relevant commit. Please give me some time for testing and > > I'll put this patch back in the tree. > >If you're going to put that patch back in, then AIO should probably be > made an option in the port config, as shutting AIO off by default will > have a significant performance impact. Without AIO, all guest IO will > be become synchronous. > Are you sure about that? Without AIO, VBox uses a generic POSIX backend, which is based on pthread, I think. ___ 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: Today's 13-STABLE panic on boot
On Sat, Feb 6, 2021 at 4:55 PM Oleh Hushchenkov wrote: > Indeed, this fixes the panic, but now I have many messages like: > > rtsx0: Controller timeout for CMD8 > rtsx0: Controller timeout for CMD8 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller timeout for CMD55 > rtsx0: Controller timeout for CMD1 > rtsx0: Controller timeout for CMD1 > rtsx0: Controller timeout for CMD1 > rtsx0: Controller timeout for CMD1 > mmc0: No compatible cards found on bus > > Is it normal? I don't have any SD cards to test. So, I will disable > the card reader in BIOS. > > Thanks for the hint! > > You might want to report this to the driver's original author: https://github.com/hlh-restart/rtsx/ ___ 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: git tools for building in base?
On Fri, Dec 18, 2020 at 7:50 PM Warner Losh wrote: > On Fri, Dec 18, 2020, 7:27 AM Guido Falsi wrote: > > > On 18/12/20 14:02, Miroslav Lachman wrote: > > > On 25/11/2020 06:54, Thomas Mueller wrote: > > > > > >> NetBSD users face a similar problem with their upcoming switch from > > >> cvs to hg (Mercurial). > > > > > > Do anybody have a link to some documents stating why FreeBSD chose Git > > > and why NetBSD chose Mercurial? I am using both tools at $WORK, I am > > > just curious what leads to these decisions. > > > > > > > This is a draft document discussing exactly this (I'm not the author, > > imp was) > > > > https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md > > > My blog > http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html > > And this video I did > https://youtu.be/uj1Ricrq0bs that starts with an old in joke... > > Warner > I can't find anything about Mercurial in all three links. ___ 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: Deprecating ftpd in the FreeBSD base system?
On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert wrote: > I've been advocating removing FTP (and HTTP) from libfetch as well. People > should be using HTTPS only. > Isn't this a bit too much? I often find myself in need to download something starting with "http://"; or "ftp://"; and use fetch for this. ___ 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: editors/libreoffice PDF export/printing broken
On Mon, Jun 22, 2020 at 9:04 PM Kostya Berger wrote: > r362292In editors/libreoffice 6.4.4 PDF export is broken, including also > PDF print to file. Tried with locally built 6.4.4 and pre-built package > 6.4.4.2 from official repo (separate installation for testing purposes). > Symptoms: of all content only graphics/tables elements get exported to > PDF. No text. PS printing is all right.As regards PDF printing to file in > general, it still works fine in Firefox. Only LO is affected. I filed a bug > report as well. > > With kindest regards, > Kostya Berger > Hum, can't reproduce this on my side. Can you do `pkg upgrade`, maybe some dependency is out of date? ___ 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: New format for binaries?
On Tue, Jul 9, 2019 at 1:33 AM Unidef wrote: > Instead of just cc files*c -o file > > We can do > > cc files*. -o file.c > > And cpp file*cpp -o file.cpp > > We can hook it up to a MySQL or a neural database? A neural database is a > multi dimensional multi directional binary tree with a master function with > a character array and a (double long *) malloc(double long * NEURAL_SIZE); > index variable, and there’s a search function that searches by character > array > > Hopefully this doesn’t sound like spam so don’t yell at me.. <0 (dr evil > emote) > > Unidef > This does look like a spam generated using some AI algorithm. The first part is probably written by hand, and other one is generated. I just wondering what's the point of this. For everyone else, message looking much like this was sent to llvm-dev@ mail list too. > Sent from my iPhone > ___ > 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" > ___ 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: Core: Yes please, Code of Conduct committee: No Thanks.
On Tue, May 21, 2019 at 2:28 PM Dima Pasechnik
wrote:
> On Sat, May 11, 2019 at 3:25 PM Julian H. Stacey wrote:
> >
> > FreeBSD Core Team Secretary wrote:
> > > 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.
> >
> > Core@ statements always welcome.
> >
> > But Code of Conduct committee merit no automatic credence since:
> >
> > Code of Conduct aims were cloned from an ultra feminist group of
> > non FreeBSD members, part paid by foundation, then shoved on
> > FreeBSD before discussion, by a voluble few in FreeBSD
>
> The present matter has nothing to do with feminism.
I don't see who states that.
Anyway, as someone
> who has been chased upon by a gang of youths screaming "zhidovskaya
> morda" ("Jewish snout") (Moscow, USSR, circa 1975, tough
> neighbourhood, and well, I have a Jewish grandmother) I absolutely do
> not appreciate the sort of thoughtless "freedom of speech" blah blah,
> as far as expressions of hate towards particular ethnic groups are .
>
Just wondering how old were you and "haters" were. In my childhood I was
laughed on because having too big ears, another girl - because she was fat,
and another guy - because his dad was an alcoholic. I'd argue that being
bulled by "jewish snout" words instead of "fatty" puts you in some special
position amongst these people and me.
Yes, the phenomenom is bad in its nature, but it is also so common and
insignificant, that IMO it doesn't serve all that fuss.
Because they always incite violence.
> And yes, in USSR persons with ethnically Jewish parents had "Jew"
> written in their internal IDs (just like in Nazi Germany). Under this
> commonly accepted definition, saying "I hate Jews", as Mr. Kamp did on
> twitter, is full-blown racism,
I'd like to hear how it is "commonly accepted". I don't remember accepting
anything related.
and Mr. Kamp ought to offer an apology
> for this - while he does not do it in
> http://phk.freebsd.dk/sagas/israel/
>
> While in some jurisdictions hate speech is legally protected, it does
> not take away the hate in hate speech, and people generally don't like
> being hated. Hate originating from a freebsd.* domain is not good for
> the project.
>
freebsd.* domain can be registered by any individual, so hate originating
from such domains can't (well, shouldn't) affect the project in any way.
On the contrary, hate originating from *.freebsd.org, it does affect the
project. Luckily, this is not the case.
> Let me point few things in the latter:
>
> * there is nothing like "the jewish religion" - there is a religion
> called Judaism, as Mr. Kamp ought to understand before
> making statements on these. Everyone can convert to Judaism, by the way.
>
Thanks for valuable information. It is completely off-topic and I doubt
anyone here have any interest in this.
> * Jews who are not Israeli citizens are about as responsible for
> policies of Israel as descendants of Vikings areresponsible for
> policies of Scandinavian states of today.
>
> * I don't know anything about the legal status of the domain
> "freebsd.dk" --- nevertheless I don't think it does do much good to
> the reputation of FreeBSD to have these slightly illiterate writings
> there (although it might be bringing Mr.Kamp lucrative contracts from
> such pillars of democracy and free thought and speech as Saudi Arabia,
> Syria, and Iran :-))
>
> Best,
> Dima
> http://users.ox.ac.uk/~coml0531/
>
>
>
>
> >
> > The new CoC terms were hotly disputed. core@ failed to remove it
> > before many tuned out, despairing of the politics [& lack of core@
> > backbone, probably themselves scared of being labeled anti-whatever],
> >
> > New CoC putch-ists took seats on CoC
> >
> > FreeBSD had a CoC before the putch with the new feminist etc CoC.
> > https://www.freebsd.org/internal/code-of-conduct.html
> > CoC could be replaced with the old one from SVN, or from
> >
> https://web.archive.org/web/*/https://www.freebsd.org/internal/code-of-conduct.html
> >
> > Cheers,
> > Julian
> > --
> > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich
> Aachen Kent
> > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in
> EU.
> > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers
> died.
> > ___
> > 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"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/ma
Re: r336921 broke booting on MBP 2017, EFIRT related
I met similar panic on my ASUS ROG GL553VE: module_register_init: MOD_LOAD (vesa, 0x80a9dd30, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 Fatal trap 12: page fault while in kernel mode cpuid = 7; apic id = 07 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x7b3cede8 stack pointer= 0x28:0x81edb7e8 frame pointer= 0x28:0x0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process= 0 (swapper) [ thread pid 0 tid 10 ] Stopped at 0x7b3cede8:cmpq%r10,(%r8,%rdx,8) It then hanged, so I could'nt even get a backtrace. However, removing "option EFIRT" from the config fixed it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: OpenVPN produces garbage on TAP on -current
On Sun, Aug 5, 2018 at 11:51 PM, Lars Schotte wrote: > Here a bit of paste: > https://paste.fedoraproject.org/paste/Hn4M2JqZ~5xccLWOVD1xUw/raw > just to illustrate how it does not work. > > TAP device works good inside OS (FreeBSD current) however, everything > that comes over OpenVPN is just garbage. > I'm using CURRENT from June 10 and tap device works fine for me with OpenVPN 2.4.6_1 > -- > Lars Schotte > Mudroňova 13 > 92101 Piešťany > ___ > freebsd-po...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" > ___ 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: Runtime loader issue
On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > In review PR 228007, it came to my attention some individuals are > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > issue". See > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > The problem can be summarized by the following > > % gfortran7 -o z h.f90 > % ./z > /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ > /usr/local/lib/gcc7/libgfortran.so.4 not found > > gfortran7 is installed from ports/lang/gcc7. This is not > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > Specifically, there is a shared library name clash. > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > % ldd z > z: >libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) >libm.so.5 => /lib/libm.so.5 (0x200a17000) >libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) >libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) >libc.so.7 => /lib/libc.so.7 (0x200ca3000) > > So, the runtime loader finds 6 instead of 716, tries to link, > fails, and issues an error message. There are a number ways to > fix this issue. > > 1) By far, the best solution would be to stop hijacking the libgcc >name in libraries installed on FreeBSD that are not related to >actual GCC software. > > % ls -l /lib/libgcc* /usr/lib/libgcc* > (trimming lines) > /lib/libgcc_s.so.1 > /usr/lib/libgcc.a@ -> libcompiler_rt.a > /usr/lib/libgcc_eh.a > /usr/lib/libgcc_eh_p.a > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > >Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm >aware that clang does not work on all archs and the ancient gcc >lives on. > > 2) Given the expected push back againt solution 1), this solution >proposes bumping the library version for /lib/libgcc_s.so.1 from >1 to some larger value, say, 10. It is unlikely that GCC will >bump its shared library number anytime soon. GCC bumped it from >0 to 1 some 16 years ago. > >https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > >This solution, however, papers over the general problem with >name clashes. > > 3) This solution is to actually fix the runtime loader. If an error >occurs with loading a shared library, then iterate over the entries >in the hints file to check to see if another hint would satisfy >the linking. Here, instead of issuing the above error, the loader >would find entry 716, and load the correct libgcc_s.so.1. > >Admittedly, I haven't looked to see how difficult this solution >would be. > > 4) Bump the shared library number of the individual ports. As a proof >of concept, I've done this with ports/lang/gcc6. > > % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc > --- libgcc/config/t-slibgcc.orig2018-05-08 12:47:42.334495000 -0700 > +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 > @@ -20,7 +20,7 @@ > > SHLIB_EXT = .so > SHLIB_SOLINK = @shlib_base_name@.so > -SHLIB_SOVERSION = 1 > +SHLIB_SOVERSION = 2 > SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) > SHLIB_MAP = @shlib_map_file@ > SHLIB_OBJS = @shlib_objs@ > > % ldconfig -r | grep gcc_ > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 >766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 > > % gfortran6 -o z h.f90 > % ./z > hello > % ldd z > z: >libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) >libm.so.5 => /lib/libm.so.5 (0x20096c000) >libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a) >libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) >libc.so.7 => /lib/libc.so.7 (0x200df7000) > >This works for this particular name conflict. Hopefully, FreeBSD >never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, >however, introduces an incompatibility with what is actually distributed >by GCC. > > Finally, can people stop referring to the above error as > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. > Our libgcc also lacks some functionality compared to the original one: https://reviews.freebsd.org/D11482 > -- > Steve > ___ > freebsd-hack...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ 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"
