Date: Wed, 17 Jun 2015 05:27:12 +0000 From: jau789@gmail.com To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: RPI2 hanging during boot Message-ID: <vczsh8.nq2ptj.ru4zhg-qmf@mx.google.com> In-Reply-To: <7F916FD0-7072-47B3-BBC5-A313CA731F81@bsdimp.com> References: <557EAE2F.3020307@gmail.com> <7F916FD0-7072-47B3-BBC5-A313CA731F81@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems that the boot time freeze was in no way related to the build itself going somehow wrong. The build after which the problem started was done on the rpi2 itself. That again needed some extra swap space which I had added manually using a file, mdcontrol, and swapon. Before reboot I apparently forgot to release that extra swap space using swapoff and mdcontrol. At the time when this happened I did not think much of it because the same mistake had happened before without corrupting the root file system header. This time the corruption happened. The confusing thing is that fsck run on an amd64 system did not notice the problem. It simply neither complained about it nor fixed it. Mounting the fs on another system also worked. The only thing which did not work was mounting it as the root fs at boot time. And even then there was no complaints about what was going wrong. My initial attempts to fix the hanging boot problem were made by crossbuilding the system on an amd64 system and reinstalling on top of the existing file system on the SD card. Since the fs was mountable on another system but not bootable on arm, there were no signs of trouble indicated on amd64. The boot persistently failed, though. When I then decided to take the hard way backing up all the stuff I needed from the old and now faulty file system on the SD card and created a complete fresh new image with a completely new fresh ufs2 on it the boot worked again just fine. There was one extra symptom of some silent file system corruption, though. I just did not notice it until very late. Just before showing the loaded kernel modules ubldr showed a one line message, a warning about not being able to write the file system. This was a second indirect indication of the root file systems header having become somehow corrupt, though, fsck and normal mount as other than root fs paid no attention to the fact. So, it seems that if a swap area, espcially one on an md device, is not explicitly released before shutdown, there is a risk that something might be corrupted on the mounted file systems. Apparently the kernel does not do anything to properly release the swap spaces before shutdown. As a side effect this might also explain the persistent rumor that some FreeBSD users see these odd, occasional ufs corruptions on a few month intervals. When the ufs is fixed the same computer then usually keeps on going happily for a long time until the apparently random corruption hits again. Most users probably still have a swap space by default. Maybe the same problem with unreleased swap space which I suspect as the culprit to my unbootable ufs2 on an SD card applies to any and all swap spaces, even those mentioned in the fstab. --jau On 15/06/2015 20:39 Warner Losh wrote: > On Jun 15, 2015, at 4:51 AM, Jukka Ukkonen <jau789@gmail.com> wrote: > > > Has anyone else seen this happening after rebuilding the system > for an RPI2 from 11.x/head source during the last few days? > I think I noticed this on Friday, the 12th. > > The boot simply freezes after having said... > > Trying to mount root from ufs:/dev/mmcsd0s2a []... > warning: no time-of-day clock registered, system time will not be set > accurately > > Then nothing happens, no more messages, no progress. > I am quite positive that at least the source code of the > previous weekend (June 5th-7th) still booted just fine on > my RPI2 when I had rebuilt the system. > > For a long there were no problems at all during the boot, and > suddenly these odd hangs began a few days ago when I rebuilt > the system from the latest source. Since then I have updated > my local source code from the svn repository a few times and > tried rebuilding again. The boot time freeze still remains, > though. The latest attempt was done using svn revision 284408. > > I hope this rings some bells to somebody. The latest snapshot from the first few days of the month works for me, which makes sense because I think it was from June 6th. Maybe you could do a binary search to see where booting fails. There=E2=80=99s only 9 days in that window, and only about a thousand commits. Since it is a hang in the handoff to user land, I think you could easily just compile the kernel to see. I also was able to boot on RPI2 a kernel I built at BSDcan from sources from June 5th. I=E2=80=99ll update to see if I see this too. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?vczsh8.nq2ptj.ru4zhg-qmf>