# Unable to make index in ports after updating to 13.1 from 12.2



## Maelstorm (Jul 8, 2022)

After just updating from 12.2 to 13.1 and using git to reestablish the /usr/src and /usr/ports directories, I'm trying to do a make index in /usr/ports and I'm getting some really _*strange *_errors...

syslogd quit with signal 10 and dumped core.
Then when I tried it again, I was getting errors about `umount /dev` failed because /dev was busy.

The command that I used in `/usr/ports` was `make index`. This machine has been running solidly for about 2 years now.  I didn't have these problems when it was on 12.2 so I don't think it's a hardware problem.  Right now it's going flat out making readme files without a hitch using the `make readmes`command.


----------



## zirias@ (Jul 8, 2022)

index in ports has been a partially broken feature for quite some time now (IIRC, it doesn't handle port flavors correctly), so my first question would be: what do you need the index for? Maybe it would make sense to change that.

Then, a few days ago, I read index creation was completely broken in a certain snapshot distributed via portsnap. Maybe this is also the case for certain revisions in git. If that's the culprit, just update until it is fixed ;-)

I don't think I understand how any syslog or umount issues are related here? Maybe add some details, it _might_ make sense to separate these issues into other threads.


----------



## Maelstorm (Jul 8, 2022)

Zirias said:


> index in ports has been a partially broken feature for quite some time now (IIRC, it doesn't handle port flavors correctly), so my first question would be: what do you need the index for? Maybe it would make sense to change that.
> 
> Then, a few days ago, I read index creation was completely broken in a certain snapshot distributed via portsnap. Maybe this is also the case for certain revisions in git. If that's the culprit, just update until it is fixed ;-)



Ok, that makes sense.  I'll just use `make fetchindex` instead then.  As for my use case, I tend to use `make search` fairly often which is why I want the index.  It makes the searches faster.



> I don't think I understand how any syslog or umount issues are related here? Maybe add some details, it _might_ make sense to separate these issues into other threads.



I don't understand that one either.  What's interesting is that it only happens during a `make index`.  If `make index` is trying to unmount /dev, that's a problem.  And seeing a bus error is also really strange too.  I think I can count on one hand the number of times that I have seen that one.  I have done `make buildworld` and `make buildkernel` on this machine with no problems.


----------



## scottro (Jul 8, 2022)

I found that using gitup wasn't making an index, so went back to portsnap, which has always worked for me.  Reading your post, I just tried portsnap fetch and portsnap update and it built the INDEX-13. I had been using gitup for ports, but as mentioned, I found it wasn't building the index


----------



## zirias@ (Jul 8, 2022)

scottro, gitup is just a tool to easily update from whatever is in git. There will never be an index in git, cause the contents of the index depend on several factors, like the OS version you're running, but also local port configurations.

As said before, it's broken anyways with port flavors.

I don't know what kind of index portsnap installs for you, probably the same you could fetch using `make fetchindex` from the top of your ports tree, so if you want that, just do it that way. It will be the index matching your OS version and all-default port options.


----------



## SirDice (Jul 8, 2022)

portsnap(8) doesn't _build_ the index, it simply downloads the index file (similar to `make fetchindex`). Which is fine if you don't have different DEFAULT_VERSIONS set in /etc/make.conf. 

`make index` sometimes fails. It happens. Usually it's relatively quickly fixed. Just `git pull` or `gitup` the ports tree and try again.

Freshly pulled ports tree:

```
root@molly:/usr/ports # make index
Generating INDEX-13 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
{...}
--- describe.x11-themes ---
--- describe.x11-toolkits ---
--- describe.x11-wm ---
 Done.
root@molly:/usr/ports #
```


----------



## Maelstorm (Jul 8, 2022)

Well, I went digging in the make code for the ports, and I found it.  There's actually two programs called make_index.  A binary version in /usr/libexec, and a perl version in /usr/ports/Tools.  It seems that when it gets to certain directories it tries to umount /dev.  The umount command is defined in the scripts.  I let it go further and then there was an error about it trying to create /dev/null.  It's quite consistent, so it definately seems to be a bug.  I think the syslogd error may have been spurious.

But there's something else.  If I login over the network using ssh and try it.  After about two minutes, my ssh session gets disconnected.  But when I try it from the console, I get umount /dev errors.  They all seem to be in the same spot.

Go figure.  

Now that I think about it, since it seems to be very consistent about when the errors happen, I wonder if it's a problem with the data that the script is processing.  Similar to a bug in image processing software where a maliciously crafted image triggers the bug and gets the software to execute code inside the image.  I wonder if that's throwing the script for a loop.


----------



## SirDice (Jul 8, 2022)

`make index` failing is often caused by a port that doesn't behave. With 50.000+ ports and numerous daily commits to the ports tree it just breaks every now and then.


----------



## VladiBG (Jul 8, 2022)

for ports i'm still using `portsnap auto` it's working ok for me in 13.1-RELEASE. I read some time ago that it's going to be deprecated in 13.0 but this doesn't happen.


----------



## SirDice (Jul 8, 2022)

VladiBG said:


> I read some time ago that it's going to be deprecated in 13.0 but this doesn't happen.


That was the original planning. But that turned out to be a bit too hasty. It's still slated to be removed though, some time in the near future.


----------

