/var/log/ on the ext4 partition (partition 3 on the standard Debian image).Lob0426 wrote:I need the storage location of the last boot log. I cannot enter commands on that card. It will not go to a prompt.
Sorry to split hairs, but are you sure that's true? i.e. if you run rpi-update just once (ignoring any errors) and then reboot, do you get a boot failure?stevethesimtec wrote:I've run through the process twice now, and in both cases, I had to run rpi-update 3 times. You must run it until it's clean i.e. no errors reported else you risk boot failureI'm fairly sure there's no need to run rpi-update multiple times - just running it once followed by a reboot should be enough.
Either one should happily just overwrite files installed by the other as far as I know. rpi-update is always going to give you the latest "bleeding edge" build, while the latest firmware available from the Foundation apt repository may be a little older (e.g. we would wait for a few days of testing before pushing out the firmware version with SD changes). I intend to have a 'bleeding edge' apt repository though, which will update whenever the firmware repo is pushed to. You can use whichever you prefer.AndrewS wrote:If the firmware can now be updated by rpi-update or by apt-get, will apt-get get confused/upset if the two are intermixed, i.e. if you apt-get the firmware and then later on rpi-update overwrites it?asb wrote:It should be safe to do rpi-update. However, the wheezy image now has the firmware packaged as .debs meaning you will be able to apt-get update && apt-get upgrade.
Would it make sense to tweak rpi-update to just print "use apt-get instead" if it detects that the firmware .deb is installed
Well, bootc's kernel doesn't contain the fixes (yet). Just use the 3.1 kernel for now, or compile a kernel with these sources.Lob0426 wrote:@lb I have a SanDisk ultra 8GB class 6 that quit working after the new kernel. The kernel is 3.2.19+ 3. From Chris' site. No matter what I did it would fail just after the keyboard loaded. Then it times out waiting for interrupt. Hope this helps. It is a brand new card.
I did report similar problems a couple of days ago, over in this threadhttp://www.raspberrypi.org/phpBB3/viewt ... 91fb9fedbe. (It may not have had the best title) . I originally thought that it was down to my building of the kernel. However acting on the suggestion in the thread I did install a stock kernel which I rpi-updated. The errors remained. That thread didn't seem to get much of a response, so rather than posting it all again, you might find it useful to read it through. It does confirm what you are experiencing. For the reasons explained in my last post in that thread, I'm not able to do any more testing on the issue.rgh wrote:I ran rpi-update today for the first time in about 3 weeks and it has broken the sdcard interface for me... I now get frequent pauses when writing and this in the dmesg output:
[ 810.440790] mmc0: final write to SD card still running
[ 820.428004] mmc0: Timeout waiting for hardware interrupt - cmd12.
[ 820.429186] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
I never saw those messages before running rpi-update. This is with a SanDisk Ultra class 6 8GB card.
Something like this: "dd if=/dev/zero of=16MB bs=4096 count=4096; sync" seems to trigger one occurrence of those messages pretty reliably (though not every time).