Description of problem: When trying to update the kernel-core, or when in a level different of rescue the filesystem disappears from the system. Version-Release number of selected component (if applicable): rpm -qa| grep -i kernel kernel-4.8.6-300.fc25.armv7hl kernel-core-4.8.6-300.fc25.armv7hl kernel-modules-4.8.6-300.fc25.armv7hl How reproducible: Every time Steps to Reproduce: 1. Boot 2. Update kernel 3. Actual results: After few seconds the filesystem disappears Expected results: Additional info: I'm testing this in a Orange Pi PC Updating / installing... 1:kernel-core-4.9.6-200.fc25 ################################# [100%] [ 331.629423] mmc0: Card stuck in programming state! mmc_do_erase [ 333.369417] mmc0: Card stuck in programming state! mmc_do_erase [ 335.414457] mmc0: Card stuck in programming state! mmc_do_erase [ 336.189457] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout [ 336.964452] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout [ 337.719453] sunxi-mmc 1c0f000.mmc: fatal err update clk timeout [ 337.726555] mmc0: tried to reset card, got error -5 [ 337.731555] blk_update_request: I/O error, dev mmcblk0, sector 2219456 [ 337.738353] mmc0: card 59b4 removed [ 337.738410] EXT4-fs warning (device mmcblk0p4): ext4_end_bio:314: I/O error ) [ 337.738421] Buffer I/O error on device mmcblk0p4, logical block 19837 [ 337.738453] Buffer I/O error on device mmcblk0p4, logical block 19838 [ 337.738460] Buffer I/O error on device mmcblk0p4, logical block 19839 [ 337.738493] EXT4-fs warning (device mmcblk0p4): ext4_end_bio:314: I/O error ) [ 337.738498] Buffer I/O error on device mmcblk0p4, logical block 19841 [ 337.738504] Buffer I/O error on device mmcblk0p4, logical block 19842 [ 337.738510] Buffer I/O error on device mmcblk0p4, logical block 19843 [ 337.738515] Buffer I/O error on device mmcblk0p4, logical block 19844 [ 337.738520] Buffer I/O error on device mmcblk0p4, logical block 19845 [ 337.738525] Buffer I/O error on device mmcblk0p4, logical block 19846 [ 337.738530] Buffer I/O error on device mmcblk0p4, logical block 19847 [ 337.738625] EXT4-fs warning (device mmcblk0p4): ext4_end_bio:314: I/O error ) [ 337.738708] EXT4-fs (mmcblk0p4): Delayed block allocation failed for inode 15 [ 337.738712] JBD2: Detected IO errors while flushing file data on mmcblk0p4-8 [ 337.738715] EXT4-fs (mmcblk0p4): This should not happen!! Data will be lost [ 337.738715] [ 337.738961] Aborting journal on device mmcblk0p4-8.
> Additional info: > I'm testing this in a Orange Pi PC What sort of SD card do you have? I've been running Fedora on my Orange Pi PC for around 6 months without major issues. I use either Samsung EVO or Sandisk Ultra Class 10 mSD cards. That said the upstream support for the H3 and related SoCs is still improving so this might improve with time (probably in the 4.11 kernel time frame though)
I think is not a SD Card problem, is class 10 and I test it in a x86_64 computer, and I can install and update a new system using this card as the system boot and don't have any errors or problems.
I am not using Fedora, but Debian, and I had the same problem on another board (Olimex A20-OLinuXIno-LIME2) which also uses sunxi-mmc. I switched the µSD card, and that didn't fix the issue (furthermore, I could read and write to that µSD card using a different). I reverted to a much older linux kernel (4.4, from 4.9) and I had no such issue so far. Therefore, I think it is not a hardware problem, but a regression in the sunxi-mmc driver in the mainline kernel. I have not filed a bug upstream (nor in Debian yet).
Instead of closing this bug can we try to debug the problem? if there are insufficient data please point me to the right procedure to get more data. Thanks.
(In reply to Nuno Dias from comment #4) > Instead of closing this bug can we try to debug the problem? if there are > insufficient data please point me to the right procedure to get more data. I hadn't updated it over 6 weeks. We don't see the issue on any other of the many devices.
There are at least one other user reporting the same issue in Debian with a different device, so instead of closing the bug with INSUFFICIENT_DATA maybe WONTFIX should be the correct status, because the bug is there, a search in Google for this error will give more users with the same bug.
> different device, so instead of closing the bug with INSUFFICIENT_DATA maybe > WONTFIX should be the correct status, because the bug is there, a search in It is INSUFFICIENT_DATA because at the moment we don't have enough data to reproduce it reliably, and it's not WONTFIX because we will if we can get enough data to be able to reliably reproduce it.