apt-get upgrade on Raspian Jessie LITE on RPi3 could cause Kernel Panic after reboot?

[Davidiio]

I don't know if it is the right place to report that problem but I haven't found any similar issue on forums where I searched except for this one #914 but it doesn't mention the jessie lite version.

I tried to install Raspbian Jessie Lite 2016-03-18 Kernel 4.1 on my Raspberry Pi 3B, after first boot I enter sudo raspi-config and expand filesystem then reboot and enter sudo apt-get update and sudo apt-get upgrade and after that, it always fails to boot again and stop on :

4.194036] ---[end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00

if I unplug the RPi and plug it again I end up with same error but different numbers on the left.
I tried to reinstall several times, also used sudo apt-get install rpi-update and sudo rpi-update, it always goes well until I do apt-get upgrade or dist-upgrade and I think hardware is ok because the non-lite jessie worked just fine and so did the NOOBS-installed version.

[pelwell]

If you can, could you try adding framebuffer_height=2160 to config.txt and rebooting? It will allow more of the kernel panic to be visible and may give more of a clue.

[Davidiio]

OK there is more of the error, I hope it helps you understand because for me it's stil mysterious :/
Thanks for your help!
it's like librt.so.1 is missing? What does that mean? I'm going to look in that /sbin/init folder but is there a way I can do that without reinstalling everything?

here it is said:

Kernel Panic on boot
Text appears on screen, but then hangs with debug messages. This can be caused by USB devices such as keyboards. Try again with nothing in the USB.

So i unplugged the RPi, unplugged usb mouse and keyboard and plugged the RPi again and end up with the same kernel panic. (And I think unplugging all usb devices you want to use in order to make your RPi boot is not a solution.)

[pelwell]

Yes, that absence of librt.so.1 is the immediate cause of the crash. Without it init dies, which is fatal.

In order to examine the filesystem you either need an Pi image which loads itself into a RAM disk or a host computer which understands the ext4 filing system (a Linux PC certainly would). I did find this application which claims to be free for personal use: https://www.paragon-software.com/home/extfs-windows/ . The website appears genuine, but I haven't tried the product and can't vouch for it.
You could also try a Linux Live CD if you have a PC to hand.

[Davidiio]

I don't get it...
I managed to navigate the sdcard content on a Debian VM and sbin/init is a symbolic link to lib/systemd/systemd which indeed try to use librt.so.1 and other libpam.so.0, libselinux.so.1 etc
I've also found librt.so.1 and his friends in lib/arm-linux-gnueabihf/ and librt.so.1 is a link to librt-2.19.so which is in the same folder, I don't really understand what is wrong?

I see here that librt.so.1 is part of libc6 package that upgrade when i do apt-get upgrade.
I could try to reinstall jessie Lite and start using apt-get --only-upgrade to upgrade all packages except libc6 to see if it really is that upgrade that doesn't work? Would that be usefull for those who maintain jessie lite?

[pelwell]

Perhaps the files are intact but for some reason the read failed.

How are you powering your Pi3? It needs a good power supply - 2.5A or greater. Do you see the red power LED flicker during boot?

[Davidiio]

I use a 5v 3.1A power supply, the red LED blinked once then the green one flicked and then red stays on and green turn off

[pelwell]

When you turn on the power the red LED should come on and stay on. If it ever goes off then you have insufficient power - the voltage is dropping below the safe level. I can think of a few possible explanations:

• You may have too many external peripherals attached to your Pi3,
• The USB cable could be faulty.
• The power supply may not be what it says it is
• The Pi3 could be faulty.

[Davidiio]

Mmmmh... These are more difficult to check but i'm goning to try.
Thanks for your help :)

[jamcole]

I had a similar issue this afternoon, but was an "Invalid Elf Header" for libpam.so.0 which is a symlink to libpam.so.0.83.1... This was on a B+ running standard jessie.

Fsck and power supply checks got me nowhere.
Replaced the file with a clean copy from another rpi which got me back in working order, but not sure what caused the issue since they're both fully apt update && apt upgraded. Interestingly, the file-size matched before overwriting the "corrupt" copy.

Just putting this comment here since it's an odd coincidence that I also just bumped into such a similar issue within the last few hours.

[PeterPablo]

@jamcole, did you by chance also check a checksum, e.g., md5? @Davidiio, may be this is a test you can do. Could the issues described here be related to #413?

[Davidiio]

I've bought the raspberry power supply, red LED stays on without blinking, but still have that kernel panic after apt-get upgrade and I was wrong, it's the same error with noobs and also with the non-lite jessie.
I tried another SD card and I had another error so it might be related to that.

@PeterPablo if you are asking me to do that :

To confirm the issue I first switched to PIO mode, this can be done fairly easily by making shdci-bcm2708.c always return 0 from dmaable() function, this will then not use DMA at all.
Unfortunately there is a further bug that effects PIO mode, this is due to the fact that the STATUS register takes a number of SD clock cycles to clock the fifo status through and therefore when we fill the fifo in sdhci_transfer_pio we cannot believe the value of SDHCI_SPACE_AVAILABLE. It will take a number of cycles to come through to that register (and for some reason it may not ever reset...) so we also need to add an unconditional break to this function

I can't do it because I really don't understand what it's all about :/ But I can try to do what popcornmix said later in the comments in #413 and see if it helps. Thanks!

[Davidiio]

Nothing worked, everytime I use apt-get upgrade i got the kernel panic.
I go try to install ubuntu mate to see if the problem comes from the raspberry (or the microSD card) or if it comes from Raspbian.

[jamcole]

@PeterPablo sorry, I was in a rush and didn't think to save the original file or get a checksum! Hopefully if anyone else comes across this issue, they'll do so.

[Davidiio]

Finally I bought a new microSDCard and I was able to use apt-get upgrade so it was indeed a card problem... for those who want to know:
Kingston SDC10G2/16GB N0579-005.A00LF TAIWAN = Does not work
Sandisk extreme plus 32 GB MicroSDHC 3 = Does work :)
for Raspberry Pi 3 B

[pelwell]

@Davidiio - I'd like to take a look at that card. If you send me your name and address - phil at raspberry pi dot org - I will send you a Sandisk 32GB in return for your non-functioning Kingston.

[chrisburrus]

Me and another person at work have been dealing with this for days. It took us forever to finalize the problem not to something on our end, but with the image itself.

We take a completely fresh raspbian-lite image, and run sudo-apt update then sudo apt-get upgrade, and it immediately kernel panics. Absolutely nothing else was done on it. This was repeated on both the Pi 2 B+ AND the Pi 3, and on multiple SD cards.

I attached a picture of the kernel panic (from the Pi 2 B+, the exact same problem of missing librt.so.1)

The exact steps I used to reproduce this:
Install a fresh copy of the latest Raspbian Jessie LITE on SD card (we tried both using linux dd command and apple pi-baker).
Boot
Log in
sudo nano /boot/config.txt (and changed the framebuffer_height=2160 as mentioned above)
reboot
log in again
sudo apt-get update
sudo apt-get upgrade
reboot
throw hands up in air

One thing that had been noticed is expanding the SD card to take up the full space using raspi-config didn't cause the kernel panic. I don't know why - there was still over 200MB of free space after the upgrade - but no more panics. However, it caused other problems sometimes (inconsistently), such as these error messages that kept repeating even past reboots. This was again on the RPI-2, but as mentioned, the same things were happening on RPI-3

Currently we're just doing the raspi-config expand hoping for the best as our workaround, heh.

[pelwell]

I have been looking at this for the last few days, using @Davidiio's card. Reproducing the problem, which manifests as file corruption, is easy but pinpointing where it goes wrong is proving difficult. But maybe today will be the day...

[EnriqueB]

I have the exact same problem with the same SD card. Hopefully you guys are able to sort it out so i dont have to buy a new one.

[pelwell]

A quick update: @Davidiio's card looks like a fake Kingston card. It seems to implement the ERASE command very slowly (0.34s for 1 sector), and my suspicion is that it is erasing more than requested. By hacking the SD driver to not advertise the ERASE capability the card becomes faster at ext4 operations involving deleting data, and the apt-get upgrade doesn't crash.

I'd like to understand the failure mode more, then find a way to recognise cards with this fault and disable ERASE support for them.

[popcornmix]

@Davidiio can you say where you bought the Kingston card from?

[Davidiio]

I got it in a small shop in Brussels where they sell computer parts and other accessories, they usualy sell good stuff and give good advices that's why I went there and the card was in it's packaging that looks perfectly "normal" (I sent it to pelwell with the card.)
Maybe they got it from a bad supplier or maybe they are not as professional as I thought they were!

[pelwell]

From what I have read, Kingston themselves have not always been good at recognising (or at least acknowledging) fakes. Without another to compare it with, the packaging looked convincing, and the card does at least appear to genuinely be a 15-16GB card. We have a contact at Kingston I've passed the details of the card to, and I'll comment again if I hear back from them.

[popcornmix]

@pelwell I have a Kingston sdcard (believed to be genuine) and it has a label on the back with some additional numbers (perhaps batch numbers).
That wasn't present on @Davidiio's card which may be suspicious.

[akobelan]

I'm having the same issue. Fresh NOOBS installation. apt-get update. Reboot for good measure. apt-get upgrade (or dist-upgrade). Reboot. Panic.

Kingston 16 Gb SDC10/16GB 94938-E06.A00LF

EDIT: Pi-3

[pelwell]

@akobelan That looks like exactly the same sort of card as @Davidiio had, which I've been analysing. The card seems to have a fairly major bug in the controller that can cause corruption in neighbouring data. I had suspected that the card was a fake, but a Kingston rep thinks it is genuine but of a new type.

I have a kernel patch that should work around it by adding an SD card quirk to say that erase is broken and shouldn't be used, but I've been reluctant to apply it without confirmation that this isn't just a defect in a single card. For this test, please download and flash Jessie Lite instead, then, before putting the card in your Pi, copy this updated kernel7.img over the existing one. You can then boot the Pi, expand the filesystem, apt-get update and apt-get upgrade as usual. This won't overwrite the kernel so the fix will still be in place.

Let me know how you get on.

[akobelan]

I'll do as you suggest this afternoon and
report back to you. Thanks!

AK

Sent from my abacus

On May 13, 2016, at 5:55 AM, Phil Elwell [email protected] wrote:

@akobelan That looks like exactly the same sort of card as @Davidiio had, which I've been analysing. The card seems to have a fairly major bug in the controller that can cause corruption in neighbouring data. I had suspected that the card was a fake, but a Kingston rep thinks it is genuine but of a new type.

I have a kernel patch that should work around it by adding an SD card quirk to say that erase is broken and shouldn't be used, but I've been reluctant to apply it without confirmation that this isn't just a defect in a single card. Could you download reflash your Jessie Lite image then, before putting the card in your Pi, copy this updated kernel7.img over the existing one. You can then boot the Pi, expand the filesystem, apt-get update and apt-get upgrade as usual. This won't overwrite the kernel so the fix will still be in place.

Let me know how you get on.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[akobelan]

Hi Phil,

I did as you suggested.

The short version, is that the Pi3 booted perfectly.

Switched locales to en_CA (UTF-8).
Switched WiFi locale to CA.
Grew the partition to the full 16 Gb.
Rebooted.
Did an "apt-get update".
Did an "apt-get upgrade".
Rebooted.

Previously, this would fail with a kernel panic.

On Fri, May 13, 2016 at 5:55 AM, Phil Elwell [email protected]
wrote:

@akobelan https://github.com/akobelan That looks like exactly the same
sort of card as @Davidiio https://github.com/Davidiio had, which I've
been analysing. The card seems to have a fairly major bug in the controller
that can cause corruption in neighbouring data. I had suspected that the
card was a fake, but a Kingston rep thinks it is genuine but of a new type.

I have a kernel patch that should work around it by adding an SD card
quirk to say that erase is broken and shouldn't be used, but I've been
reluctant to apply it without confirmation that this isn't just a defect in
a single card. Could you download reflash your Jessie Lite image then,
before putting the card in your Pi, copy this updated kernel7.img
https://drive.google.com/open?id=0B8VsfKAD4-NOcHVUcTdXb0hYaHc over the
existing one. You can then boot the Pi, expand the filesystem, apt-get
update and apt-get upgrade as usual. This won't overwrite the kernel so the
fix will still be in place.

Let me know how you get on.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1416 (comment)

[akobelan]

@pelwell Can you explain what the impact of your changes would be on the day-to-day use of the card? Do I continue using it? Do I look for an alternative?

[pelwell]

The patch is to disable the ERASE functionality, which is mainly a performance enhancement. If we disabled ERASE for all SD cards people probably wouldn't notice. I'd be a bit concerned that if this major error exists, there may be other issues as well, but as long as you don't trust mission-critical data to it you should be OK.

I've just pushed the patch to our 4.4 tree, and I'll see about pushing it upstream. Unfortunately this is too late for the latest Raspbian builds, so I wouldn't upgrade without first asking here for a patched kernel. The alternative is that you perform the upgrade then without rebooting follow it with an rpi-update to grab a fixed kernel, although again we haven't built one of those yet.

[pelwell]

New rpi-update firmware has been pushed including this patch, should you want to upgrade to a 4.4 kernel.

[pelwell]

@Berryfier Please post the output of:

grep . /sys/class/mmc_host/mmc0/mmc0:*/*

[Berryfier]

@pelwell Thank you for giving your time to this. Inputting the command line on my pi with Jessie Lite & the replaced Kernel7.img on the Kingston card, and after errors have been observed, the output is
grep: /sys/class/mmc_host/mmc0/mmc0:*.*: No such file or directory
I took a look and there is a directory
/sys/class/mmc_host/mmc0/mmc0:0003
but grep . produces no output when run from this directory

[pelwell]

What about grep . * in that directory?

[pelwell]

Or just:

cat name
cat manfid
cat oemid

[Berryfier]

No sure if it helps, but a cat of some files in /sys/class/mmc_host/mmc0/mmc0:0003 shows
fwrev 0x0
hwrev 0x3
manfid 0x000041
name SD16G
oemid 0x3432
serial 0x7c300141
type SD

[pelwell]

Yes, that is exactly the information I was looking for. Those details match one of the quirk match rules I added:

MMC_FIXUP("SD16G", 0x41, 0x3432, add_quirk_mmc, MMC_QUIRK_ERASE_BROKEN),
MMC_FIXUP("SD32G", 0x41, 0x3432, add_quirk_mmc, MMC_QUIRK_ERASE_BROKEN),
MMC_FIXUP("SD64G", 0x41, 0x3432, add_quirk_mmc, MMC_QUIRK_ERASE_BROKEN),

These rules appeared in yesterday's rpi-update firmware releases, so if you continue to see a problem after updating then there is another issue.

If you want to try the new kernel I suggest you install the recent Jessie Lite release, boot it then rpi-update straight away. Since this is a kernel version bump it shouldn't cause many (any?) deletions on the ext4 partition, so you should get away with it.

[pelwell]

From a clean Jessie Lite you run:

sudo apt-get install rpi-update
sudo rpi-update
sudo shutdown -r now

Mine rebooted without complaints, so I hope it will also work for you.

[Berryfier]

Thank you for your suggestions.
All your commands went well.
But on rebooting after installing git, after a long wait, I see Welcome to emergency mode! The log shows there are invalid key/value pairs, invalid rules, and unknown keys. It's gotten more broken faster than ever.

[Driffster]

I have the same problem with the latest Rasbian Jessie (25-05-2016) and the Kingston sd card SDC10G2-16GB N0579-003.A00LF. I already have the latest version if I try rpi-update.

here is the grep output:

grep: /sys/class/mmc_host/mmc0/mmc0:0003/block: Is a directory
/sys/class/mmc_host/mmc0/mmc0:0003/cid:4134325344313647304180128c00f9ab
/sys/class/mmc_host/mmc0/mmc0:0003/csd:400e005a5b59000073677f800a400027
/sys/class/mmc_host/mmc0/mmc0:0003/date:09/2015
grep: /sys/class/mmc_host/mmc0/mmc0:0003/driver: Is a directory
/sys/class/mmc_host/mmc0/mmc0:0003/erase_size:512
/sys/class/mmc_host/mmc0/mmc0:0003/fwrev:0x0
/sys/class/mmc_host/mmc0/mmc0:0003/hwrev:0x3
/sys/class/mmc_host/mmc0/mmc0:0003/manfid:0x000041
/sys/class/mmc_host/mmc0/mmc0:0003/name:SD16G
/sys/class/mmc_host/mmc0/mmc0:0003/oemid:0x3432
grep: /sys/class/mmc_host/mmc0/mmc0:0003/power: Is a directory
/sys/class/mmc_host/mmc0/mmc0:0003/preferred_erase_size:12582912
/sys/class/mmc_host/mmc0/mmc0:0003/scr:0235800300000000
/sys/class/mmc_host/mmc0/mmc0:0003/serial:0x4180128c
grep: /sys/class/mmc_host/mmc0/mmc0:0003/subsystem: Is a directory
/sys/class/mmc_host/mmc0/mmc0:0003/type:SD
/sys/class/mmc_host/mmc0/mmc0:0003/uevent:DRIVER=mmcblk
/sys/class/mmc_host/mmc0/mmc0:0003/uevent:MMC_TYPE=SD
/sys/class/mmc_host/mmc0/mmc0:0003/uevent:MMC_NAME=SD16G
/sys/class/mmc_host/mmc0/mmc0:0003/uevent:MODALIAS=mmc:block

[Berryfier]

The supplier of my card (MyMemory) replaced the problem Kingston card without quibble. The replacement is a Kingston SDC 10G2/16GB 31608-005.A00LF, and has etched print on its rear '16G1602'. The replacement card gives no trouble.

[pelwell]

There was an error in the quirks above - where it says add_quirk_mmc it should have said add_quirk. A patch for that will be in the next release, but until then you can add mmc_block.card_quirks=0x80000000 to cmdline.txt.

[Driffster]

@pelwell Thank you for the quick reply, unfortunately it does not work, I still get the panic. Tried it 2 times from fresh imaging of the sd card, to no avail. If you have other suggestions I am willing to try, meanwhile I will look at getting a replacement card.

[Ruffio]

@Driffster have you solved your issue with a New sd card?

[Driffster]

Yes. I reinstalled it on an Kingston GB SDCA/GB N0465-002.A00LF, which is their more expensive version (I wanted another brand but that is all they had at the store I went.. ) I had no issue updating with that card and the Raspberry works fine since.

[Ruffio]

@Driffster then please close this issue ;-) Thanks.

[Driffster]

@Ruffio
Well I can't since this is not my issue, I just had the same problem. Also the problem was not fixed, I just bought a better SD card to avoid it, which is a fine solution for me, but does not remove the underlying issue with that particular SD card.

[keebler411]

This is absolutely repeatable and not an anomaly specific to what any one person is trying. I've had the exact same issue with the exact same steps using a 16GB Kingston sd card. Although I won't go as far as to say my 16GB sd cards are exactly the same as the ones above.

However, what I do know this is: On Sunday I did the install and upgrade steps using an 8GB kingston sd card with no problems. Shipped it out. On Monday I repeated same steps with 16GB Kingston card because boss bought a whole bunch of them on sale for $5 each. Ran into the above problems.

After much trying of different things I found this thread and had an ahah moment. So I scrounged around the office and found a kingston 32GB card. Did the same install and upgrade steps as before and voila no problem. I knew from the very second step it would work because when I resized the file system the Pi 3 didn't hang for a few seconds after resizing the root file system like it did with the 16GB sd card.

So the only question that remains is: Is this a bad card design by Kingston or is it an inherent problem with Raspian/linux/RPi 3? Actually it goes much deeper than that. I've found that with even good power supplies the sd card on the raspberry pi 3 can get corrupted. I now have to use great power supplies. Soon we will be moving to compute modules with emmc memory.

[ghollingworth]

Did you try it with mmc_block.card_quirks=0x80000000 ?

We think that it should already be enabled since Phil is trying to trap your SDCard manufacturer id / card id but it's possible there is a different ID out there. Make sure you add the line to config.txt after imaging the card otherwise it can easily get corrupted again before you even do the rpi-update

Gordon

[keebler411]

But its a non-issue for me with respect to this particular 16GB card. Like others have said just avoid this card. Putting in a fix to make a $5 card work is not acceptable UNLESS the problem is not really with the card. In that case do the fix AND buy a new card. Is there any indication at all that this is a system problem and and not a card problem?

[ghollingworth]

No it is definitely a card problem, but when people go out and buy an SD card and install Raspbian on it and plug it into a Raspberry Pi and it doesn't work they invariably point the finger at Raspberry Pi rather than the card.

I'm just trying to ascertain whether the card you have is not triggering the card quirk for some reason. Or if it is a different fault again.

Gordon

[keebler411]

Okay thats cool I'm all about tracking stuff down definitively. I have to sleep sometime though.... I'll try it tomorrow (today) or the day after. Thanks for noticing the problem to begin with. And yeah I know what you mean about users. After the power supply fiasco (also bought by the boss) I went back to the store where they sold the Pis and power supplies and told them the "power supplies" they were selling were really USB chargers and they looked at me like I was stupid.

[beast19]

Hi everybody,

i know this thread is old, but I cant find a newer one and not sure if its worse to open a new one.
It seams I have the same Problem but with a different card, so as far as i got this thread here your fix wont work cause of the different IDs of my card.

I tried to install a fresh raspbian jessie light image to mi B2+, replaced the mentioned kernel, rpi-update it, reboot was ok. Then try "apt update" and "apt upgrade" without success. Upgrade just takes a long time at 93% removing som "kernalhack" but it finished without errors, However if i reboot the PI, it wont boot at all, the screen flicker a short while but the colored boot picture is missing and no shell would come up. If i reboot the PI then by removing power the colored boot screen is showing forever, still no shell.

Maybe you can help me, maybe my card is really broken, i dont know.

This is the end of the upgrade output:

Removing 'diversion of /boot/overlays/vga666.dtbo to /usr/share/rpikernelhack/overlays/vga666.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio-pullup.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio-pullup.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/w1-gpio.dtbo to /usr/share/rpikernelhack/overlays/w1-gpio.dtbo by rpikernelhack'
Removing 'diversion of /boot/overlays/wittypi.dtbo to /usr/share/rpikernelhack/overlays/wittypi.dtbo by rpikernelhack'
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.38+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.38+ /boot/kernel.img
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.4.38-v7+ /boot/kernel7.img
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.4.38-v7+ /boot/kernel7.img
Setting up libraspberrypi-bin (1.20161215-1) ...
Setting up raspi-config (20161207) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
pi@raspberrypi:~ $

This are my card details (4gb Sandisk is printed on it, worked since 2014 without problems until i try to upgrade)

pi@raspberrypi:~ $ grep . /sys/class/mmc_host/mmc0/mmc0:*/*
grep: /sys/class/mmc_host/mmc0/mmc0:b368/block: Is a directory
/sys/class/mmc_host/mmc0/mmc0:b368/cid:03000053444320201000a284f7007535
/sys/class/mmc_host/mmc0/mmc0:b368/csd:400e00325b5900001eb97f800a4000c7
/sys/class/mmc_host/mmc0/mmc0:b368/date:05/2007
grep: /sys/class/mmc_host/mmc0/mmc0:b368/driver: Is a directory
/sys/class/mmc_host/mmc0/mmc0:b368/erase_size:512
/sys/class/mmc_host/mmc0/mmc0:b368/fwrev:0x0
/sys/class/mmc_host/mmc0/mmc0:b368/hwrev:0x1
/sys/class/mmc_host/mmc0/mmc0:b368/manfid:0x000003
/sys/class/mmc_host/mmc0/mmc0:b368/name:SDC
/sys/class/mmc_host/mmc0/mmc0:b368/oemid:0x0000
grep: /sys/class/mmc_host/mmc0/mmc0:b368/power: Is a directory
/sys/class/mmc_host/mmc0/mmc0:b368/preferred_erase_size:4194304
/sys/class/mmc_host/mmc0/mmc0:b368/scr:0235800000000000
/sys/class/mmc_host/mmc0/mmc0:b368/serial:0x00a284f7
grep: /sys/class/mmc_host/mmc0/mmc0:b368/subsystem: Is a directory
/sys/class/mmc_host/mmc0/mmc0:b368/type:SD
/sys/class/mmc_host/mmc0/mmc0:b368/uevent:DRIVER=mmcblk
/sys/class/mmc_host/mmc0/mmc0:b368/uevent:MMC_TYPE=SD
/sys/class/mmc_host/mmc0/mmc0:b368/uevent:MMC_NAME=SDC
/sys/class/mmc_host/mmc0/mmc0:b368/uevent:MODALIAS=mmc:block

Maybe you can just build me another kernel with fits to my OEMID and i can give it a try.

regards
beast

[pelwell]

I'm not aware of any problems with SanDisk cards, but as it says above you can enable the quirk that avoids ERASEs for any card using a kernel command-line parameter. Add the following to /boot/cmdline.txt, keeping all of the text in a single line:

mmc_block.card_quirks=0x80000000

[Ruffio]

@Davidiio is this still an issue?

[P33M]

In the case that disabling ERASE commands still doesn't work, I'd suggest buying another $5 SD card.

Generally we recommend the use of our official accessories (which include 8 and 16GB uSD cards).

[BitBondtmUK]

Thanks for posting this important Raspberry "heads-up" as I was tempted to try exactly this! No way. I think it's clearly better to start fresh and format a clean SD. It's more stable & saves the day! Yep.

[2theMAXtheStairFax]

I had the same issue, i found that the card had become corrupted. This model differs but take note, it is also a bad model: SDCS/16GB B0658-003.A00LFTS do not trust kingston

[2theMAXtheStairFax]

And also i found that the drivers were from 2006

[2ashishs]

I was recently facing this issue on my Pi, event after formatting the SD card.
To solve, I used gparted to create partition table on the SD card of type mac - this leaves a 1mb gap at the beginning of SD card. Then I created a fat32 partition on the SD card.