search

sakaki- / gentoo-on-rpi-64bit

Bootable 64-bit Gentoo image for the Raspberry Pi4B, 3B & 3B+, with Linux 5.4, OpenRC, Xfce4, VC4/V3D, camera and h/w codec support, weekly-autobuild binhost
GNU General Public License v3.0
925 stars 127 forks source link

genup: Cannot update from 1.4.1 #87

Closed zertyz closed 5 years ago

zertyz commented 5 years ago

I downloaded the latest release, 1.4.1 and, for some reason, I cannot update the system.

I'm new to Gentoo, so I might be doing something wrong.

After 1 or 2 hours, my Pi 3B+ becomes unresponsive.

I tried some number of times, even reinstalling the 1.4.1 release from scratch to find the reason, which seems to be a huge memory requirement to upgrade the system, leading it to hang due to intense swapping.

I'll try one more time, from scratch, disabling swap to see if I get some meaningful message and will report back here.

zertyz commented 5 years ago

I let it running over night (and it is still doing its things) with no hangs.

I had installed your system on and old, slow but very trusty 16 GiB Kingston USB dongle. I guess if nobody else experienced this issue, that may be the cause.

What I did: 1) Stopped all services I didn't need to have the system running over SSH, get more memory 2) Disabled barriers, atime and increased the commit for the rootfs -- I also increased the dirty ratios and timeouts 3) Increased the maximum IO size to 4GiB to reduce write aplification (that seems to be the size of the erase block of my dongle) 4) Added 3 more (and faster) usb dongles to be used as swap devices and removed the swap from the slow dongle used as rootfs 5) Changed swappiness to 1 and zswap max_pool_percent also to 1 -- since having as much buffers and cache seems to be the key factor here

With all this, the system is still responsive -- It is Emerging binary (173 of 301) so far, using just 15 MiB of swap.

Nobody else seems to be experimenting these overload hangs I mentioned because they might be using faster medium. Well, my first incarnation with your system was on a -- reasonably fast -- 32 GiB sandisk sdcard and the update also failed, but that time I did it using the GUI interface with no tweeks at all.

Nonetheless you might consider, if possible, setting your update scripts to do less things in parallel, since these cheap media perform (even more) poorly when their IO is fragmented.

PS: now that I just woke up, I just set the scheduler to "none" (instead of the default "deadline"). If I get some noticeble improvements on the update speed, I'll report back here.

zertyz commented 5 years ago

Definitely the way to go, at least in my case, is to use the "kyber" IO scheduler.

The update is proceeding much faster now.

sakaki- commented 5 years ago

Thanks for reporting these findings! What changes did you end up regarding as most useful in the end (I'll incorporate these in the next image release, which I'm beginning to think about now)? Best, sakaki

sakaki- commented 5 years ago

1.4.2 is now out. This includes a modified genup which automatically calls ionice to (hopefully) address this problem in future. Closing now. Please re-open if you still experience the issue on the new system. Thanks again for reporting, best, sakaki