Re: netbsd crashes when using fat filesys
On Wed, May 01, 2024 at 05:08:04PM +, xuser wrote: > This is as much as a I can give you > It say some thing about invalid fats > i cant see much because the screen go blank > As for the core dump i don't have enough swap space Can you provdie an image of a filesystem that shows this bug? Maybe create a new empty one (on a usb stick?) and make it bad (however that is done), then dump the stick's content and only after that try if it triggers your crash. If it does, upload the image somewhere and send the URL. Thanks, Martin
Re: Please forgive a blatant plug: I reviewed v10 for the Reg
On Wed, 1 May 2024 at 12:31, Greg Troxel wrote: > > Liam Proven writes: > > > Step 1: a binary interoperability standard, so apps from any BSD can > > execute on any other BSD (on the same CPU architecture, obviously.) > > This is not so much about the binaries about about the ABI for libc and > other core libs. But I suspec this works better than you think, if one > arranges for the other libs and deals with elf tags. You are missing my point. I am not asking "are they close?" or "are they compatible?" I am saying: let's work out the differences, make a detailed specific list, and see if it would be possible to work out a specific standard API so that *the same binaries* could run on them all. A modern BSD equivalent of the iBCS 2: https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard > All BSDs come from 386BSD and Net/2, said in a very broad brush way. I know that. I have been working in the Unix industry and thus watching this sector closely since half a decade before 386BSD was released. > It's not accurate to say that the kernels are unique. [...] Again, you misunderstand and do not see my point. I am saying: let us try to isolate and work out which parts of the 3 or 4 main BSD projects are specific to each OS and which are shared. Each BSD's kernel is its own. Yes they are all related. We know that. The clue is in the BSD name. But they are not the same any more and merging the kernels would be both an epic job, as well as one that nobody would want to do or to happen. > > * Coreutils? > > coreutils is a term for a GNU package, and many/most of those > utilities in BSDs aren't from that. Really, coreutils is the linux > reimplementation of traditional utilities. I dispute that. It's just a name. Don't fixate on the name. Thing about the thing that the name refers to. Here is one set of BSD coreutils, ported to Linux: https://github.com/DiegoMagdaleno/BSDCoreUtils Here is another: https://github.com/dcantrell/bsdutils Here's a modernised port of that: https://github.com/chimera-linux/chimerautils It is an identifiable, discrete thing. FWIW I have written about this subject as part of this article: https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/ > Lots of things are the same because they are from the same upstream, > eg. OpenSSH. But others are differnet. Again you can't really slice it > that way so easily. I submit that there is a very important difference between "you can't slice it" and "nobody has tried to slice it". > Mostly these are the same upstreams, perhaps packaged differently. I know. That is my point. > emacs runs on all of them. I'm not sure what your point is here. My point is to try to reduce the maintenance load of the 4 separate BSD projects by identifying where they overlap and moving those duplicated sections into a shared codebase, which can be collaboratively maintained by all the teams, reducing the maintenance burden on those parts by, conservatively, 75%. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
Re: Please forgive a blatant plug: I reviewed v10 for the Reg
https://archive.fosdem.org/2023/schedule/event/bsd_driver_harmony/attachments/slides/5976/export/events/attachments/bsd_driver_harmony/slides/5976/BSD_Driver_Harmony_FOSDEM.pdf Talk from Last year Yahoo Mail: Search, organise, conquer On Thu, 2 May 2024 at 3:14 pm, Liam Proven wrote: On Wed, 1 May 2024 at 12:31, Greg Troxel wrote: > > Liam Proven writes: > > > Step 1: a binary interoperability standard, so apps from any BSD can > > execute on any other BSD (on the same CPU architecture, obviously.) > > This is not so much about the binaries about about the ABI for libc and > other core libs. But I suspec this works better than you think, if one > arranges for the other libs and deals with elf tags. You are missing my point. I am not asking "are they close?" or "are they compatible?" I am saying: let's work out the differences, make a detailed specific list, and see if it would be possible to work out a specific standard API so that *the same binaries* could run on them all. A modern BSD equivalent of the iBCS 2: https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard > All BSDs come from 386BSD and Net/2, said in a very broad brush way. I know that. I have been working in the Unix industry and thus watching this sector closely since half a decade before 386BSD was released. > It's not accurate to say that the kernels are unique. [...] Again, you misunderstand and do not see my point. I am saying: let us try to isolate and work out which parts of the 3 or 4 main BSD projects are specific to each OS and which are shared. Each BSD's kernel is its own. Yes they are all related. We know that. The clue is in the BSD name. But they are not the same any more and merging the kernels would be both an epic job, as well as one that nobody would want to do or to happen. > > * Coreutils? > > coreutils is a term for a GNU package, and many/most of those > utilities in BSDs aren't from that. Really, coreutils is the linux > reimplementation of traditional utilities. I dispute that. It's just a name. Don't fixate on the name. Thing about the thing that the name refers to. Here is one set of BSD coreutils, ported to Linux: https://github.com/DiegoMagdaleno/BSDCoreUtils Here is another: https://github.com/dcantrell/bsdutils Here's a modernised port of that: https://github.com/chimera-linux/chimerautils It is an identifiable, discrete thing. FWIW I have written about this subject as part of this article: https://www.theregister.com/2023/02/13/chimera_non_gnu_linux/ > Lots of things are the same because they are from the same upstream, > eg. OpenSSH. But others are differnet. Again you can't really slice it > that way so easily. I submit that there is a very important difference between "you can't slice it" and "nobody has tried to slice it". > Mostly these are the same upstreams, perhaps packaged differently. I know. That is my point. > emacs runs on all of them. I'm not sure what your point is here. My point is to try to reduce the maintenance load of the 4 separate BSD projects by identifying where they overlap and moving those duplicated sections into a shared codebase, which can be collaboratively maintained by all the teams, reducing the maintenance burden on those parts by, conservatively, 75%. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lpro...@cix.co.uk ~ gMail/gTalk/FB: lpro...@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven IoM: (+44) 7624 277612: UK: (+44) 7939-087884 Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
Re: Please forgive a blatant plug: I reviewed v10 for the Reg
On 2024-05-02 11:44, Liam Proven wrote:
This is not so much about the binaries about about the ABI for libc and
other core libs. But I suspec this works better than you think, if one
arranges for the other libs and deals with elf tags.
You are missing my point.
I am not asking "are they close?" or "are they compatible?" I am
saying: let's
And there's the rub, right there.
You want to tell other people ("developers") what they should spend
their time on. And if you were ten times right, it wouldn't work that way.
Do the leg work yourself, and things *might* come to happen. Or not.
work out the differences, make a detailed specific list,
and see if it would be possible to work out a specific standard API so
that*the same binaries* could run on them all.
Ob-xkcd:
Re: netbsd crashes when using fat filesys
there's gotta be a better way to debug this On Thu, May 2, 2024 at 5:41 AM Martin Husemann wrote: > On Wed, May 01, 2024 at 05:08:04PM +, xuser wrote: > > This is as much as a I can give you > > It say some thing about invalid fats > > i cant see much because the screen go blank > > As for the core dump i don't have enough swap space > > Can you provdie an image of a filesystem that shows this bug? > Maybe create a new empty one (on a usb stick?) and make it bad (however > that is done), then dump the stick's content and only after that try if > it triggers your crash. If it does, upload the image somewhere and send > the URL. > > Thanks, > > Martin > -- renegade6969...@gmail.com https://www.facebook.com/profile.php?id=61556020800880 https://twitter.com/Rose29283220654
Re: netbsd crashes when using fat filesys
On Thu 02 May 2024 at 11:41:13 +0200, Martin Husemann wrote: > On Wed, May 01, 2024 at 05:08:04PM +, xuser wrote: > > This is as much as a I can give you > > It say some thing about invalid fats > > i cant see much because the screen go blank > > As for the core dump i don't have enough swap space > > Can you provdie an image of a filesystem that shows this bug? > Maybe create a new empty one (on a usb stick?) and make it bad (however > that is done), then dump the stick's content and only after that try if > it triggers your crash. If it does, upload the image somewhere and send > the URL. I had something similar recently when doing a rename of a file on a FAT file system (in this case my /efi file system). Fortunately I had it mounted with -o rump, because it was 100% repeatable. I filed http://gnats.netbsd.org/58146 for it. > Martin -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: netbsd crashes when using fat filesys
On Thu, May 02, 2024 at 08:04:28PM +0200, Rhialto wrote: > I filed http://gnats.netbsd.org/58146 for it. Why do you think those issue are related? Sounds very unlikely to me. Martin
Re: netbsd crashes when using fat filesys
On Thu, May 02, 2024 at 08:12:06PM +0200, Martin Husemann wrote: > On Thu, May 02, 2024 at 08:04:28PM +0200, Rhialto wrote: > > I filed http://gnats.netbsd.org/58146 for it. > > Why do you think those issue are related? Sounds very unlikely to me. To ellaborate on this: - the original issue reported here is *something else* mangling/breaking a FAT file system and NetBSD not dealing with the result. This can either be a bug in Solaris or in NetBSD's interpration of the FAT file system format - we just don't know (yet). An image of a file system in broken state is absolutely required here to debug the issue. If the OP can't provide such an image, we need a *working recipe* how to reproduce the issue, plus someone with a Solaris 10 installation to create the broken image, plus someone to debug the result. Currently we have neither the recipe nor someone with Solaris 10 installed willing to help. - PR 58146 looks like a NetBSD local locking issue/race condition. The file system image you offered probably will not be helpfull, we need to do carefull reading of the relevant locking paths in the code. Martin
Re: netbsd crashes when using fat filesys
rhia...@falu.nl (Rhialto) writes: >I had something similar recently when doing a rename of a file on a FAT >file system (in this case my /efi file system). Fortunately I had it >mounted with -o rump, because it was 100% repeatable. >I filed http://gnats.netbsd.org/58146 for it. Maybe that's rump. msdosfs: KASSERT(tcnp->cn_cred == cred); genfs: /* * XXX Want a better equality test. `tcnp->cn_cred == cred' * hoses p2k because puffs transmits the creds separately and * allocates distinct but equivalent structures for them. */ KASSERT(kauth_cred_uidmatch(cred, tcnp->cn_cred)); Can you still repeat the crash when you change the assertion to match the genfs check ?
Re: netbsd crashes when using fat filesys
On Thu 02 May 2024 at 20:10:10 -, Michael van Elst wrote: > rhia...@falu.nl (Rhialto) writes: > > >I had something similar recently when doing a rename of a file on a FAT > >file system (in this case my /efi file system). Fortunately I had it > >mounted with -o rump, because it was 100% repeatable. > > >I filed http://gnats.netbsd.org/58146 for it. > > > Maybe that's rump. > > msdosfs: > KASSERT(tcnp->cn_cred == cred); > > genfs: /* > * XXX Want a better equality test. `tcnp->cn_cred == cred' > * hoses p2k because puffs transmits the creds separately and > * allocates distinct but equivalent structures for them. > */ > KASSERT(kauth_cred_uidmatch(cred, tcnp->cn_cred)); > > > Can you still repeat the crash when you change the assertion > to match the genfs check ? Unless I did something wrong with rebuilding rump_msdos, the problem still exists when using that assertion instead. But the message from the assertion failure now goes into the void. (Although that somehow also happens if I use the original rump_msdos executable) Here is how I tested (I used a file system in a file this time rather than the real partition): terminal 1: $ ls -l efi.img rump_msdos -rw-r--r-- 1 rhialto wheel 134217728 May 2 22:32 efi.img -r-xr-xr-x 1 rhialto wheel 20776 May 2 22:29 rump_msdos* $ sudo ./rump_msdos -o rw -o rump ./efi.img /tmp/t rump_msdos: "./efi.img" is a relative path. rump_msdos: using "/mnt/scratch/scratch/tmp/xcrash/efi.img" instead. [ 1.000] entropy: ready terminal 2: $ cd /tmp/t $ ls -l total 4 drwxr-xr-x 1 rhialto wheel 4096 Apr 21 2021 efi/ -rwxr-xr-x 1 rhialto wheel 0 May 2 22:32 file* $ mv file file2 mv: rename file to file2: Device not configured $ ls -l ls: .: No such file or directory -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: netbsd crashes when using fat filesys
rhia...@falu.nl (Rhialto) writes: >$ sudo ./rump_msdos -o rw -o rump ./efi.img /tmp/t >rump_msdos: "./efi.img" is a relative path. >rump_msdos: using "/mnt/scratch/scratch/tmp/xcrash/efi.img" instead. >[ 1.000] entropy: ready >terminal 2: >$ cd /tmp/t >$ ls -l >total 4 >drwxr-xr-x 1 rhialto wheel 4096 Apr 21 2021 efi/ >-rwxr-xr-x 1 rhialto wheel 0 May 2 22:32 file* >$ mv file file2 >mv: rename file to file2: Device not configured I can repeat this with rump, but not with the kernel filesystem. After my suggested change, rump no longer crashes. N.B. the code change is in /usr/lib/librumpfs_msdos.so.0.0.
Re: netbsd crashes when using fat filesys
Yes it is that netbsd will crash on driver errors And I found the problem it was that solaris autofs driver would mount an LBA fat 32 as CHS fat32 And so disabling automount support in solaris fixed it. Thank you. On Thu, 2 May 2024, Martin Husemann wrote: On Thu, May 02, 2024 at 08:12:06PM +0200, Martin Husemann wrote: On Thu, May 02, 2024 at 08:04:28PM +0200, Rhialto wrote: I filed http://gnats.netbsd.org/58146 for it. Why do you think those issue are related? Sounds very unlikely to me. To ellaborate on this: - the original issue reported here is *something else* mangling/breaking a FAT file system and NetBSD not dealing with the result. This can either be a bug in Solaris or in NetBSD's interpration of the FAT file system format - we just don't know (yet). An image of a file system in broken state is absolutely required here to debug the issue. If the OP can't provide such an image, we need a *working recipe* how to reproduce the issue, plus someone with a Solaris 10 installation to create the broken image, plus someone to debug the result. Currently we have neither the recipe nor someone with Solaris 10 installed willing to help. - PR 58146 looks like a NetBSD local locking issue/race condition. The file system image you offered probably will not be helpfull, we need to do carefull reading of the relevant locking paths in the code. Martin
