When updating my Beta 4 Haiku install, either the Noto font update or an update related to a dependency of Harfbuzz triggered a layout bug where the buttons and menu items became too small to read the text. Bug report filed as #18794 (SoftwareUpdater: UI glitch when updating Noto font) – Haiku . Future comments should be added there. Solution is a reboot if you can figure out where the shut down option is on the menu.
2 Likes
I had been working on noto updates and noticed the same behaviour and mentioned it at: Update Noto fonts · Issue #9727 · haikuports/haikuports · GitHub
Thanks for reporting it here.
The same activity occurred for me too!
A reboot seemed to clear it…keeping an eye on it henceforth.
There is always the power button 
I used “Ctrl-Alt-Del” to force the TeamMonitor, left button in the bottem is the one you need for a reboot.
Is it possible to mark the Noto font package as “reboot needed” like the Haiku system packages?
That won’t fix the issue. I suspect the app_server just needs to deal with the files changing on disk properly.
You will get the same issue if you set another font as system font and update that fonts package.
Can somebody paste a screenshoot of this issue?
If you have multiple Haiku setups and you’ve recovered from the heart attack the first time this happened (or if you’re reading this before updating) the following Terminal command will just get it over with:
pkgman update noto && shutdown -r
6 Likes
Why are you copying info from the bugtracker? Those that it concerns can see the ticket?
It’s done, dude. Stick a fork in it. I just put a period at the end of the sentence.
Yes, copying the info that the ticket was closed is exactly what I was reffering too. It does not matter that the post was in “in the past” everything you write here is.
Another warning, noto-cjk has been updated, those using these packages best read comments above on how to reboot.
It is not a bug, it is expected font case. It is just a layout problem for me! Comes with different font and it would go with a different font!
Layout bug? Sounds just strange to me.
Expected? I’ve updated the default font on Windows, MacOS and Linux dozens of times and I’ve never seen this. It’s not the biggest bug in history. As long as it’s just us, it is a minor issue. We know that Haiku is very resilient and hitting the power button won’t bork your system. Well, as long as you don’t do it every day 
But let’s suppose Haiku becomes wildly popular one day. Microsoft and Apple go out of business, Linux goes back to the server room where it belongs, and we all get our faces on TIME magazine covers. Do you want to support hundreds of thousands of users complaining about their screen being unreadable? User who don’t dare hit the power button because they have been taught for years that that is the fastest way to destroy a Windows installation?
It’s a bug.
1 Like
I guess what Bruno meant is, it’s a known bug, and it resolves after a reboot. But, certainly, it’s still a bug.
In this specific case, nothing is crashed, so you can press the power button once (not keep it pressed) and you will get a clean shutdown.
I just ran into this issue tonight. Definitely a nasty bug to experience.
Well,
me also installed all dozens of updates recently, me had not experienced “layout bug”, but only in Terminal : the last confirmations of pkgman came back with non-bold version of Noto CJK - I assume as I use a bold Noto CJK version in Terminal.
It is higher and thinner than normal Noto this way I use them in Terminal … against I observed a strange figure.
At the end of the line in case Noto CJK the last character sometimes not fully drawed. Sometimes it covered by the blackground color.
The more strange circumstance is : not at the longest lines …
look at all “done.” at the end of the lines … and you will understand what I’m writing about (on the following picture) :
Maybe a developer interested in Terminal development … find it interesting ! :-))
Otherwise back from this offtopic sideways, me also had to force reboot Haiku with Power button as I got a full screen debugger window that referred an issue as he had not found a specific libxml2 directory.
There was a small patch on the full debugger window with mouse cursor, so I attemted a continue command , but that failed and debugger came back with failed message and in the prompt it had not accepted the exit command …
I was waited a little bit and then ‘pushed the button’ as I could not back into Haiku.
After that I rebooted into Haiku and all seems ok, update was successful, I shared above the re-check of packages status of installed ones.
Even with
haikuwebkit that I always downgraded back to 1.9.8
as always experienced issues and sudden crashes of Webpositive meanwhile with 1.9.8 - I had not, ever – now it seems stable with the latest 1.9.11 version, thanks to one or more packages updated altogether now from haikuports ;
and harfbuzz* packages that maybe I suspected wrong with other turmoils that happenned due to memory issue lately - it seems.
Now I had not observed in machine’s firmware Diagnostics (short) Memory tests as in a week ago, so I booted Haiku today.
Only one glitch remained from this earlier issues that forced me to not use my Dell Precion 6700M for a week.
I used
checkfs -c /boot
checkfs /boot
checkfs -c /boot
combo
as I used to do after an unwanted or forced reboot …
and now I have a remaining error message - it does not matter how many times I iterated the commands.
It hat not happened earlier , never. I could clean BFS fully earlier. Now it remains.
oss_audigyls (inode = 2690977), has invalid block run(s)
Welcome to the Haiku shell.
~> checkfs -c /boot
oss_audigyls (inode = 2690977), has invalid block run(s)
39601 nodes checked,
0 blocks not allocated,
0 blocks already set,
0 blocks could be freed
files 37384
directories 1473
attributes 415
attr. dirs 281
indices 48
direct block runs 42386 (9.30 GiB)
indirect block runs 821 (in 51 array blocks, 734.73 MiB)
double indirect block runs 0 (in 0 array blocks, 0 bájt)
~> checkfs /boot
oss_audigyls (inode = 2690977), has invalid block run(s)
39601 nodes checked,
0 blocks not allocated,
0 blocks already set,
0 blocks could be freed
files 37384
directories 1473
attributes 415
attr. dirs 281
indices 48
direct block runs 42386 (9.30 GiB)
indirect block runs 821 (in 51 array blocks, 734.73 MiB)
double indirect block runs 0 (in 0 array blocks, 0 bájt)
~> checkfs -c /boot
oss_audigyls (inode = 2690977), has invalid block run(s)
39601 nodes checked,
0 blocks not allocated,
0 blocks already set,
0 blocks could be freed
files 37384
directories 1473
attributes 415
attr. dirs 281
indices 48
direct block runs 42386 (9.30 GiB)
indirect block runs 821 (in 51 array blocks, 734.73 MiB)
double indirect block runs 0 (in 0 array blocks, 0 bájt)
~>
What is your opinion about it ?
Is there another tool or command to fix it ?