This evening I suffered a power failure (and something has gone wrong
inside my once useful UPS).

On subsequent rebooting after my generator had kicked in,
I attempted to do a hitherto unproblematic
git -C /usr/ports pull
and got an error message about index file smaller than expected.

Looking this up online I tried to fix it with
removing .git/index
and then git reset HEAD
but this only caused other error messages.

So I tried to remove the ports subdirectory from /usr
so as to bring in a new git clone.

NEARLY all of /usr/ports was deleted...
everything except /usr/ports/science .
NEARLY all of /usr/ports/science was deleted...
everything except /usr/ports/science/py-tensorflow .
NEARLY all of /usr/ports/science/py-tensorflow was deleted...
everything except /usr/ports/science/py-tensorflow/files .

"Directory not empty" error messages respond to any attempt
to delete any of these...though ls in
/usr/ports/science/py-tensorflow/files
returns one straight to the shell prompt and ls -al
returns
total 0
and then the shell prompt.

These empty directories can neither be moved nor removed.

Attempting to create a file in the files directory caused a crash.

Rebooting after a plain fsck after the crash came up with error messages

savecore 982 - - reboot after panic: ufs_dirbad: /: bad dir ino 20008348 at offset 1024: mangled entry
savecore 982 - - writing core to /var/crash/vmcore.1
Sep 14 05:30:14 top savecore[982]: reboot after panic: ufs_dirbad: /: bad dir ino 20008348 at offset 1024: mangled entry
Writing crash summary to /var/crash/core.txt.1

vmcore.1 is a 1052684288 byte file I will not reproduce here.

Is there anything particular to look for in the 176587-byte core.txt.1 ?
Is there any particular fsck option that would make things work again?

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

Am Mittwoch, 14. September 2022, um 06:21:05 Uhr schrieb Louis Epstein:

> Attempting to create a file in the files directory caused a crash.
>
> Rebooting after a plain fsck after the crash came up with error
> messages
>
> savecore 982 - - reboot after panic: ufs_dirbad: /: bad dir ino
> 20008348 at offset 1024: mangled entry savecore 982 - - writing core
> to /var/crash/vmcore.1 Sep 14 05:30:14 top savecore[982]: reboot
> after panic: ufs_dirbad: /: bad dir ino 20008348 at offset 1024:
> mangled entry Writing crash summary to /var/crash/core.txt.1
>
> vmcore.1 is a 1052684288 byte file I will not reproduce here.
>
> Is there anything particular to look for in the 176587-byte
> core.txt.1 ? Is there any particular fsck option that would make
> things work again?

If you run fsck, does it ask you to delete these entries?

Marco Moock <mo01@posteo.de> wrote:
> Am Mittwoch, 14. September 2022, um 06:21:05 Uhr schrieb Louis Epstein:
>
>> Attempting to create a file in the files directory caused a crash.
>>
>> Rebooting after a plain fsck after the crash came up with error
>> messages
>>
>> savecore 982 - - reboot after panic: ufs_dirbad: /: bad dir ino
>> 20008348 at offset 1024: mangled entry savecore 982 - - writing core
>> to /var/crash/vmcore.1 Sep 14 05:30:14 top savecore[982]: reboot
>> after panic: ufs_dirbad: /: bad dir ino 20008348 at offset 1024:
>> mangled entry Writing crash summary to /var/crash/core.txt.1
>>
>> vmcore.1 is a 1052684288 byte file I will not reproduce here.
>>
>> Is there anything particular to look for in the 176587-byte
>> core.txt.1 ? Is there any particular fsck option that would make
>> things work again?
>
> If you run fsck, does it ask you to delete these entries?
>

Rebooting and saying fsck at the first prompt
gets a host of error messages with a "no" response
automatically filled in for all of them.

The start is

-=-

** /dev/ada0s1a (NO WRITE)
** SU + J Recovering /dev/ada0s1a

USE JOURNAL?no

** Skipping journal, falling through to full fsck

SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /
** Root file system
-=-

The second of 3 errors encountered in Phase 2 is
the one at issue here,in between two UNALLOCATEDs,
one in /usr/local/etc/namedb and the other in
/var/spool/clientmqueue:

DIRECTORY CORRUPTED I=20008348 OWNER=root MODE=40755
SIZE=1536 MTIME=Sep 13 19:37 2022
DIR=/usr/ports/science/py-tensorflow/files

Phase 4 meanwhile has an UNREF DIR error,
four ZERO LENGTH FILE errors,and 28 LINK COUNT FILE
errors.

So what's to be done to fix?

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

Am Mittwoch, 14. September 2022, um 08:34:28 Uhr schrieb Louis Epstein:

> Rebooting and saying fsck at the first prompt
> gets a host of error messages with a "no" response
> automatically filled in for all of them.

Can you answer them with "yes"?

Marco Moock <mo01@posteo.de> wrote:
> Am Mittwoch, 14. September 2022, um 08:34:28 Uhr schrieb Louis Epstein:
>
>> Rebooting and saying fsck at the first prompt
>> gets a host of error messages with a "no" response
>> automatically filled in for all of them.
>
> Can you answer them with "yes"?
>

As I said they were automatically filled in,
probably tied to my being in / (I am familiar
with unmounting any OTHER partition when doing
fsck but how can I unmount the / when the OS is
there?...since the system isn't responding to
a crash how do I get into a different mode?)

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:

> As I said they were automatically filled in,
> probably tied to my being in / (I am familiar
> with unmounting any OTHER partition when doing
> fsck but how can I unmount the / when the OS is
> there?...since the system isn't responding to
> a crash how do I get into a different mode?)

You cant do fsck with repairs on a mounted file system. You need to
boot a live system (any distribution you like, e.g. Ubuntu) and run
fsck there. Then you should be able to change the contents on the file
system that is broken.

On Wed, 14 Sep 2022 17:40:58 +0200, Marco Moock wrote:

> Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:
>
>> As I said they were automatically filled in, probably tied to my being
>> in / (I am familiar with unmounting any OTHER partition when doing fsck
>> but how can I unmount the / when the OS is there?...since the system
>> isn't responding to a crash how do I get into a different mode?)
>
> You cant do fsck with repairs on a mounted file system. You need to boot
> a live system (any distribution you like, e.g. Ubuntu) and run fsck
> there. Then you should be able to change the contents on the file system
> that is broken.

You can if it's mounted read only. At least, that's how you fix the root
file system.

--
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Bob Eager <news0009@eager.cx> wrote:
> On Wed, 14 Sep 2022 17:40:58 +0200, Marco Moock wrote:
>
>> Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:
>>
>>> As I said they were automatically filled in, probably tied to my being
>>> in / (I am familiar with unmounting any OTHER partition when doing fsck
>>> but how can I unmount the / when the OS is there?...since the system
>>> isn't responding to a crash how do I get into a different mode?)
>>
>> You cant do fsck with repairs on a mounted file system. You need to boot
>> a live system (any distribution you like, e.g. Ubuntu) and run fsck
>> there. Then you should be able to change the contents on the file system
>> that is broken.
>
> You can if it's mounted read only. At least, that's how you fix the root
> file system.
>
>

(problem now fixed)

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

Louis Epstein <le@top.put.com> wrote in <tftd65$3es$1@reader2.panix.com>:

> Bob Eager <news0009@eager.cx> wrote:
>> On Wed, 14 Sep 2022 17:40:58 +0200, Marco Moock wrote:
>>
>>> Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:
>>>
>>>> As I said they were automatically filled in, probably tied to my being
>>>> in / (I am familiar with unmounting any OTHER partition when doing fsck
>>>> but how can I unmount the / when the OS is there?...since the system
>>>> isn't responding to a crash how do I get into a different mode?)
>>>
>>> You cant do fsck with repairs on a mounted file system. You need to boot
>>> a live system (any distribution you like, e.g. Ubuntu) and run fsck
>>> there. Then you should be able to change the contents on the file system
>>> that is broken.
>>
>> You can if it's mounted read only. At least, that's how you fix the root
>> file system.
>>
>>
>
> (problem now fixed)

How?

--
Look, there's a difference between sensibly recognizing that nobody is
perfect and making a law that says trying to improve is illegal.
-- Ursula Georges

mikea@mikea.ath.cx wrote:
> Louis Epstein <le@top.put.com> wrote in <tftd65$3es$1@reader2.panix.com>:
>
>> Bob Eager <news0009@eager.cx> wrote:
>>> On Wed, 14 Sep 2022 17:40:58 +0200, Marco Moock wrote:
>>>
>>>> Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:
>>>>
>>>>> As I said they were automatically filled in, probably tied to my being
>>>>> in / (I am familiar with unmounting any OTHER partition when doing fsck
>>>>> but how can I unmount the / when the OS is there?...since the system
>>>>> isn't responding to a crash how do I get into a different mode?)
>>>>
>>>> You cant do fsck with repairs on a mounted file system. You need to boot
>>>> a live system (any distribution you like, e.g. Ubuntu) and run fsck
>>>> there. Then you should be able to change the contents on the file system
>>>> that is broken.
>>>
>>> You can if it's mounted read only. At least, that's how you fix the root
>>> file system.
>>>
>>>
>>
>> (problem now fixed)
>
> How?
>

Doing a full fsck in single user mode (no journal).

-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.

Louis Epstein <le@top.put.com> wrote in <tg0i1i$v0$1@reader2.panix.com>:

> mikea@mikea.ath.cx wrote:
>> Louis Epstein <le@top.put.com> wrote in <tftd65$3es$1@reader2.panix.com>:
>>
>>> Bob Eager <news0009@eager.cx> wrote:
>>>> On Wed, 14 Sep 2022 17:40:58 +0200, Marco Moock wrote:
>>>>
>>>>> Am Mittwoch, 14. September 2022, um 14:51:41 Uhr schrieb Louis Epstein:
>>>>>
>>>>>> As I said they were automatically filled in, probably tied to my being
>>>>>> in / (I am familiar with unmounting any OTHER partition when doing fsck
>>>>>> but how can I unmount the / when the OS is there?...since the system
>>>>>> isn't responding to a crash how do I get into a different mode?)
>>>>>
>>>>> You cant do fsck with repairs on a mounted file system. You need to boot
>>>>> a live system (any distribution you like, e.g. Ubuntu) and run fsck
>>>>> there. Then you should be able to change the contents on the file system
>>>>> that is broken.
>>>>
>>>> You can if it's mounted read only. At least, that's how you fix the root
>>>> file system.
>>>>
>>>>
>>>
>>> (problem now fixed)
>>
>> How?
>>
>
> Doing a full fsck in single user mode (no journal).

Thanks! I thought that was about the only way under the circumstances.

--
Segovia on his hatred of routine playing:
I have to be present at every note I play.