SD Card containing /home corrupted on resume

Bug #342096 reported by drizek on 2009-03-13
152
This bug affects 22 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Low
Unassigned
Nominated for Jaunty by Urimas
Nominated for Karmic by Urimas
Nominated for Lucid by Omer Akram

Bug Description

Suspend/resume works on the Mini 9 as of the latest kernel update(it did not with the previous kernel). I have Jaunty installed with / partition on the internal SSD and my /home folder on an SDHC card. When I resumed the home folder was not mounted and it appears that the filesystem was corrupted. Both / and /home are formatted in ext4. I ran dmesg to see what it said(image below) I then restarted and it ran fsck on boot and gave an error. I hit Ctrl+D and when I tried to log in my /home folder had not been mounted.

I have attached pictures of dmesg | tail, fstab, and fsck.

http://omploader.org/vMWQ5Yg
http://omploader.org/vMWQ5Yw
http://omploader.org/vMWQ5ZA

This is with Jaunty, I am not sure what package the problem is with exactly. I don't know if it is ext4 or something else.

drizek (dimitrirz) on 2009-03-13
description: updated
jango (charraoalegria-netcabo) wrote :

Same problem on Acer Aspire One Januty UNR alpha 6 home folder on an SDHC filesystem was corrupted... Cant be fixed???

Thanks

drizek (dimitrirz) wrote :

Were you using ext4 as well?

I'm sure there are quite a few people who will be using Ubuntu with this partitioning setup.

jango (charraoalegria-netcabo) wrote :

No.. Im using ext2

Paul Smith (paulsmith433) wrote :

Yeah, I get same problem on my Acer Aspire One . Installed with latest download of USB install from 2009-04-17. Updated packages to latest and then encountered the problem.

I have a 16GB SDHC card, formatted to ext4 and mounted as /home. The filesystem is corrupt. It mentions about the journal being invalid. Sorry but I haven't got the output from dmesg.

It is entirely reproducable.

For some reason the install won't let me try XFS else I would have tried that.

summary: - SD Card containing /home corrupted on resume. ext4. Dell Mini 9.
+ SD Card containing /home corrupted on resume. ext4.

On Sat, 2009-04-18 at 19:14 +0000, Paul Smith wrote:
> Yeah, I get same problem on my Acer Aspire One . Installed with latest
> download of USB install from 2009-04-17. Updated packages to latest and
> then encountered the problem.
>
> I have a 16GB SDHC card, formatted to ext4 and mounted as /home. The
> filesystem is corrupt. It mentions about the journal being invalid.
> Sorry but I haven't got the output from dmesg.
>
> It is entirely reproducable.
>
> For some reason the install won't let me try XFS else I would have tried
> that.
The problem isn't the filesystem (same problem will happen for all
filesystems). It's the SDHC card. I believe the SDHC card gets shutdown
improperly before suspending, the same as if you use /home on a USB
stick. I've heard that a newer kernel should fix this, but I'm not very
sure about which.
--
Regards,
Chow Loong Jin

I confirm the problem with my aspire one on a 8Gb SDHC. Installed jaunty UNR release candidate. Packages are up to date.

It's reproductible. I was able to reproduced this with ext2, ext3 and ext4.

SD card need to be reformated each time :-(. I have lost my home... It's OK for me as a RC tester, but should be prevent in the feature

Changed in pm-utils (Ubuntu):
status: New → Confirmed
tags: added: aspireone jaunty
summary: - SD Card containing /home corrupted on resume. ext4.
+ SD Card containing /home corrupted on resume
Jose Bernardo (bernardo-bandos) wrote :

I can report the same problem on a aspire one, with the difference I only have /boot on the SSD, and / is on the SDHC card. Both times I tried suspeding it lost the partition table, which I was able to recreate just by using fdisk.

renbag (renbag) wrote :

I confirm this bug on a Dell mini9 with ubuntu-9.04-netbook-remix-i386.
After resuming from a suspend with a mounted SHDC card, the partition table on the card is corrupted.
This does not happen with the original ubuntu 8.04 shipped by Dell. Looking at the config files of the Dell 8.04 and the Ubuntu 9.04 kernels I found these relevant differences:

config-2.6.24-22-lpia (Ubuntu 8.04 Dell):
...
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_PCI=y
CONFIG_MMC_UNSAFE_RESUME=y
...

config-2.6.28-11-generic (ubuntu 9.04):
...
CONFIG_MMC=y
CONFIG_MMC_BLOCK=m
CONFIG_MMC_SDHCI=m
CONFIG_MMC_SDHCI_PCI=m
# CONFIG_MMC_UNSAFE_RESUME is not set
...

Then I build custom packages of 2.6.28-11 kernel and restricted-modules for jaunty, using the CONFIG_MMC options of the Ubuntu 8.04 kernel and this solved the problem for me.
(Community instructions for kernel compile are here: https://help.ubuntu.com/community/Kernel/Compile)

andypiper (andypiperuk) wrote :

Same issue on Acer Aspire One, with various kernels up to the latest 2.6.28-13
I've had a 16Gb SDHC go corrupt on vfat, ext2 and ext4 filesystems. Won't remount, and fsck will not fix. Luckily I've been using it as "scratch" space so far, but ultimately had intended to have /home on there!

Can we get this kernel option re-added to the default Jaunty / Ubuntu build? Is this a pm-utils package issue, or an issue with linux-image-kernel?

Unfortunately, adding this options is no longer enough. I've built 2.6.30 from the karmik git tree, used a config derived from kukilinux config, with these exact options, and I still get heavy corruption after suspend. If the sdcard isn't mounted as /home then there is no problem. There seem to be other bugs afecting SDHC and suspend/resume.

Of course, adding these options back would be a large step in the right direction for full support of netbooks...

I forgot to add, I used karmic kernel git commit 0c9f19b4dd23620fb32116922b0d93e8aca6c911 for my last kernel.

Bart de Koning (bratdaking) wrote :

Hey all, I just bumped into this problem too, with Ubuntu 9.04 unr installed fresh from a usb stick, used sda1 as / (ext2), and a sd card for /home (ext4). After my battery was empty my SD disk crashed upon resume.
obviously the problem is a lost partition table:
output of 'sudo fdisk -l'

Schijf /dev/mmcblk0: 8201 MB, 8201961472 bytes
4 koppen, 16 sectoren/spoor, 250304 cilinders
Eenheid = cilinders van 64 * 512 = 32768 bytes
Schijf-ID: 0x00000000

Schijf /dev/mmcblk0 bevat geen geldige partitietabel
(is dutch for: Disk /dev/mmcblk0 does not contain a valid partition table)

Googling around I found that this problem hurt other people with other systems as well, especially the openmoko and OLPC community, see:
http://dev.laptop.org/ticket/6532
http://docs.openmoko.org/trac/ticket/1802

As far as I understood the resume action does something tricky: it revives the SD card and checks whether the card is still in the slot, only it does the check too quick, the power is not entirely restored yet, what results in removal of the disk from the system, although the disk is actually still in and mounted resulting in overwriting of the partition table:

***
dsaxena in http://dev.laptop.org/ticket/6532:
Upon coming out of resume, the SD code, with CONFIG_MMC_UNSAFE_SUSPEND enabled, checks to see if there is a card plugged into the system and whether that card is the same as the one that was plugged into the system at suspend time. This is accomplished by reading the card ID of the device and for some reason, very possibly #1339, we fail this detection. In this case, the kernel removes the old device from the system and in this execution path, the partition information for this device is zeroed.

Even though the device is removed, the device is still mounted and upon unmount, ext2 syncs the superblock, even if the file system is sync'd beforehand. The superblock is block 0 of the partition and the block layer adds to this the partition start offset before submitting the write to the lower layers. As the partition information has already been zeroed out, we end up writing to block 0 of the disk itself, overwriting the partition table and the geometry information. I've verified this by both gathering debug output and 'dd' + 'hexdump' of corrupted and uncorrupted media.
***

The proposed fix was to build a delay of 400 ms in the resume process. Unfortunatley I am not really a programmer, so I have not really a clue how to do that yet.

In the meanwhile another (dirty) workaround I found from polarbaer in http://docs.openmoko.org/trac/ticket/1802:

***
I have the same problem with a 8GB SanDisk?-card, even when the 2008.8 is installed on the micro-SC. Since I have a Qtopia in the flash (to have a stable phone) I backed up the partitiontable via
dd if=/dev/mmcblk0 of=/home/root/backup.img bs=512 count=1
and put the restore-command
dd of=/dev/mmcblk0 if=/home/root/backup.img bs=512 count=1
to any bootup-script in Qtopia, in my case to the top of:
/etc/init.d/mountall.sh
so it fixes itself once I boot my Qtopia.

Not a fix, but at least a very bloody workaround.
***

Bart de Koning (bratdaking) wrote :

Hey all,

Short request: could somebody, who is justified to do that, change the importance of this bug to at least medium or high.
I think the bug is important enough to get some attention: people could easily lose their data this way! and accidentally clearing partition tables of disks is to my opinion a serious bug in a operating system...
(you can get it your data back by writing your partition table back to the card using dd, as described in the workaround above, but then you need at least to have a copy of the partition table, and this is not really something that an inexperienced user can do).

/home on your sd card sounds maybe stranger than it actually is. Many netbooks are equipped with flash disks that have incredibly long write access times (up to a second!). Having your firefox cache on such a disks makes browsing a hell, making SD cards interesting alternatives for your /home, as long as it does not corrupt the partition table though....

Bart de Koning (bratdaking) wrote :

Trying to solve the issue I played (on a Aspire One A110, with 9.04 UNR, and /home on a ext4 partition on a SD card) around with delaying the resume process by making a pm hook (called /etc/pm/sleep.d/99zleep -> so really the first hook that should be read on a resume) containing only a sleep command on thaw|resume. Having a delay of 20 seconds (you have to start somewhere ;-)), you see a whole lot of messages popping up on the screen (that I could not find back in my logs actually) and something odd struck my eye: immediately after resume the kernel finds a new SD card (instead of recognizing it as the old one) and puts it on /dev/mmcblk1 (while it was on /dev/mmcblk0). So what dsaxena saw on a OLPC apparently also happens on our systems.

I decided to unmount the /home before suspend and mount it again after resume, by including umount -l /home and mount /home in my 99zleep hook (as mounting occurs by UUID it does not matter that the location was switched). If you reduce the sleep time to 1 s (on longer times the machine got stuck), it is able to resume, however it does not resume your session but starts a new one by resuming into the gdm greeter. Making the sleep time shorter (to 0.5 s) the behaviour looks better -> resumes your session, however screws up the partition table again: so as soon as you want to switch off the system it hangs and on a restart the partition table of the SD card is gone again (in some cases it also damaged the journal).
I think I need the pause still earlier than I do now (so the SD card is recognized as being the same that was already there), has anybody an idea how to include a pause at the very beginning of the resume script -> before remounting any of the drives?

Jim Fulton (jim-zope) wrote :

I'm having a related problem, but it looks like I've been luckier.

I have 9.04, kernel 2.6.18-15, running on an Aspire One. I've got a 16G sdhc class 6 card in the "storage expansion" slot on the left with a 4G vfat partition in p1 and a 12G ext3 partition in p2, mounted on /home.

If the ext3 partition is mounted, suspend or hibernate hang. I have to do a hard power off to get use of the machine. Fortunately, so far, I haven't had a problem with the partition table on the sd card.

To warn you that is only a matter of time (there is a matter of randomness
involved), I use the same setup, so make a copy with the dd option of your
partition table and put it on a safe place on the sdd drive (like /root). If
it fries your bootsector you can easily retrieve it then. Make also a backup
regurarly of your /home (I can recoommend backintime for that -> use a
folder on your sdd as the backup folder, eg /var/backintime). Once it did
not only fry my bootsector but also the journal, causing serious damage to
my ext4 partition, beyond the table and what fsck can do, so then I really
had to reformat it.
It hangs during suspend or hibernate (or closing the laptop cover) because
when it comes back it recognizes your card as a new one and mounts it as a
new drive, instead of recognizing it as the old one. The systems searches
for the old one to open the /home, cannot find it and the system crashes. I
have not been lucky in fixing this yet. I need some extra waiting time as
soon as the kernel awakens, to have enough electricity running through the
card, but I don't know how to implement that. Making extra pm-util hooks
does not work, as they are called too late.

to backup your partition table:
dd if=/dev/mmcblk0 of=/root/backupSD.img bs=512 count=1
to recover:
dd of=/dev/mmcblk0 if=/root/backupSD.img bs=512 count=1
Not necessary to include that in a script or something, you can also use
that when you need it...

Cheers,
Bart

2009/8/30 Jim Fulton <email address hidden>

> I'm having a related problem, but it looks like I've been luckier.
>
> I have 9.04, kernel 2.6.18-15, running on an Aspire One. I've got a 16G
> sdhc class 6 card in the "storage expansion" slot on the left with a 4G
> vfat partition in p1 and a 12G ext3 partition in p2, mounted on /home.
>
> If the ext3 partition is mounted, suspend or hibernate hang. I have to
> do a hard power off to get use of the machine. Fortunately, so far, I
> haven't had a problem with the partition table on the sd card.
>
> --
> SD Card containing /home corrupted on resume
> https://bugs.launchpad.net/bugs/342096
> You received this bug notification because you are a direct subscriber
> of the bug.
>

AFAIK this is not a bug related with pm-utils but with ubuntu kernel configuration, and can be fixed adding:

CONFIG_MMC_UNSAFE_RESUME=y

to config generic.

Please add it as, also with the daily karmic image, without it is impossibile to hibernate or suspend while using a sd card with aufs2 filesystem (it resume with a completely corrupted card).

Bart de Koning (bratdaking) wrote :

Thanks for the information, although I do not completely like the option
(besides the point that I need to recompile my kernel). The option you point
out is actually quite a bad fix to my opinion. It does not umount your SD
card before a suspend: with possible data corruption. The question to solve
the problem adequately, is why is it remounting your SD card as a new drive,
while it is still the same drive.
The people from the OLPC and OpenMoko pointed at an explanation that the SD
card might not have yet enough power to give a proper identification on a
resume and need 400 ms more before they remount. I only do not know how to
give my resume process an additional 400 ms, before it starts remounting. If
you have a slight idea how to do that, I could give it a try.

The other possibility mentioned in your link is really interesting, to use
LVM: apparently then there are no problems at all. However that does not fix
the initial problem :-)

Thanks again,
cheers,
Bart

2009/10/10 Skumpic <email address hidden>

> http://en.gentoo-
> wiki.com/wiki/Acer_Aspire_One_A110L#SD_Cards_and_suspend
>
> --
> SD Card containing /home corrupted on resume
> https://bugs.launchpad.net/bugs/342096
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Son (son.caokim) wrote :

The LVM option is interesting. Have some one tried it yet? And if yes,
do you have any hint why we dont suffer from the same bug?

Thanks in advance

On Sun, 2009-10-11 at 12:38 +0000, Bart de Koning wrote:

> Thanks for the information, although I do not completely like the option
> (besides the point that I need to recompile my kernel). The option you point
> out is actually quite a bad fix to my opinion. It does not umount your SD
> card before a suspend: with possible data corruption. The question to solve
> the problem adequately, is why is it remounting your SD card as a new drive,
> while it is still the same drive.
> The people from the OLPC and OpenMoko pointed at an explanation that the SD
> card might not have yet enough power to give a proper identification on a
> resume and need 400 ms more before they remount. I only do not know how to
> give my resume process an additional 400 ms, before it starts remounting. If
> you have a slight idea how to do that, I could give it a try.
>
> The other possibility mentioned in your link is really interesting, to use
> LVM: apparently then there are no problems at all. However that does not fix
> the initial problem :-)
>
> Thanks again,
> cheers,
> Bart
>
> 2009/10/10 Skumpic <email address hidden>
>
> > http://en.gentoo-
> > wiki.com/wiki/Acer_Aspire_One_A110L#SD_Cards_and_suspend
> >
> > --
> > SD Card containing /home corrupted on resume
> > https://bugs.launchpad.net/bugs/342096
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>

I tried LVM and i endend up with a completely unusable SD card.

[ 162.836239] mmc0: new SDHC card at address 559c
[ 162.836285] mmc mmc0:559c: parent mmc0 should not be sleeping
[ 162.836451] mmcblk1: mmc0:559c SD08G 7.42 GiB
[ 162.836547] mmcblk1: p1
[ 163.241959] sd 1:0:0:0: [sda] Starting disk
[ 163.352104] usb 1-5: reset high speed USB device using ehci_hcd and address 3
[ 163.900098] usb 2-1: reset low speed USB device using uhci_hcd and address 2
[ 163.928076] ACPI: EC: missing confirmations, switch off interrupt mode.
[ 164.208084] PM: Image restored successfully.
[ 164.245668] Restarting tasks ... done.
[ 164.293692] PM: Basic memory bitmaps freed
[ 164.665825] MMC: killing requests for dead queue
[ 164.665844] end_request: I/O error, dev mmcblk0, sector 15548672
[ 164.665957] MMC: killing requests for dead queue
[ 164.665970] end_request: I/O error, dev mmcblk0, sector 15548784
[ 164.666035] MMC: killing requests for dead queue
[ 164.666047] end_request: I/O error, dev mmcblk0, sector 384
[ 164.666107] MMC: killing requests for dead queue
[ 164.666119] end_request: I/O error, dev mmcblk0, sector 392
[ 164.666257] MMC: killing requests for dead queue
[ 164.666271] end_request: I/O error, dev mmcblk0, sector 384
[ 164.823823] MMC: killing requests for dead queue
[ 164.823838] end_request: I/O error, dev mmcblk0, sector 384

I also tried to rebuild the mmc driver with the added 400ms timeout without any luck untill now (but i may do something wrong as i'm not a coder) :(

I'm not a "kernel hacker" so probably i'm wrong but maybe this code can "do the trick":

http://<email address hidden>/msg00055.html

Omer Akram (om26er) wrote :

is it an upstream bug? if yes then have some one upstreamed it?a

Daniel Wiberg (dannew) wrote :

Beniamino: Those patches are integrated in the latest kernel, so if that solves the problem, running this kernel should work: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.4/.

Does anybody know, if it is intended to enable CONFIG_MMC_UNSAFE_RESUME with final Ubuntu 10.04 "Lucid" release --
at least for the netbook remix?
With the currently available Alpha 2 netbook build this kernel option again is not set (acc. to /boot/config-2.6.32-10-generic).
It would be really great to get the standby mode working reliable also for systems installed on SD cards --
with Ubuntu 9.04 on my Lenovo IdeaPad S12 "resume after standby" sometimes is working well, sometimes not.
I would not like to compile the kernel on my netbook with the changed option --
is there any other option or patch to solve this problem (different from the above ones)?

Max Lindner (lokimuh) wrote :

Debian found a solution for this stuff months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504391

andymanak (andymanak) wrote :

>Max Lindner wrote on 2010-03-22: #27
>Debian found a solution for this stuff months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504391

Did this work its way across to the Ubuntu kernel yet? Or will it be in the kernel in 10.04?

Also, how would you set the card reader to removable=0?

Andres Muniz (andresmp) wrote :

Hi, this is still happening to me. I close the lid of the acer aspire One that that has an SD card in the storage expansion. This SD card holds the /home drive. When I open the lid and hit any key it knows my password and the home drive seems mounte only that it is empty. Rebooting shows the home drive normally.

$uname
Linux andres-AOA110 3.2.0-58-generic-pae #0trisquel1 SMP Tue Jan 14 02:44:33 UTC 2014 i686 i686 i386 GNU/Linux

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=10fe9052-e786-4b63-b5cc-ea33543707bd / ext4 errors=remount-ro 0 1
# /home was on /dev/mmcblk0 during installation
UUID=595fabfa-cc74-4e9c-a3ca-c7aa30c3044c /home ext4 defaults 0 2
# swap was on /dev/sda2 during installation
UUID=d37fd7ee-1bde-47e5-a2da-ac669cdbf2f2 none swap sw 0 0

Łukasz (lukaszertel-z) wrote :

Dear Launchpad friends,
I have to confirm this bug.
In Ubuntu 12.04 LTS this issue is still NOT RESOLVED.
I tried to add some scripts to unmount sdcard before suspend, but system couldn't mount it after resume.
The hard way for me is to compile kernel, but I don't want to mess up with my distro.

It's very old problem, when we can except for a solution? I can help as a beta tester if you wish.

Cheers,
Łukasz

14.04 still not resolved

James Beal (james-) wrote :

Still an issue

George Ingram (pictsidhe) wrote :

This was still a problem in 13.10. It started ok, but then stared happening on 13.10. I'd done a fake-pae install on an X40 so can't comment on previous versions. It was magically 'fixed' when I upgraded to 14.04. but it just resurfaced >:/

Suspend by shutting the lid or low power and when I resume, the system has lost track of the original mount and asks me if I want to view in file manager, as with removeable storage.

This is a 5 year old bug, a lot of people with old notebooks boost the storage with SD cards, it would be very nice if we could rely on them.

Mine is now mounted on /home/username/sd.

I started using it a permanent storage after 14.04 upgrade 'fixed' the problem.

drizek, thank you for reporting this bug to Ubuntu. Jaunty reached EOL on October 23, 2010.
See this document for currently supported Ubuntu releases: https://wiki.ubuntu.com/Releases

Is this reproducible in the latest release of Ubuntu via http://cdimage.ubuntu.com/daily-live/current/ ?

If so, please execute the following via a terminal in order for the necessary debugging information to be attached:
apport-collect 342096

affects: pm-utils (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Ivan Garavito (ivangaravito) wrote :

Hi everyone!

This bug is still Ubuntu 14.04.3 nowadays. The SD card I'm using is for music (not my /home ^_^') and it have 64 GB, but it's annoying use the method I've found its working for me:
1. Remove SD card
2. Kill processes that use the SD card
3. Reinsert SD card
4. Start new processes that use the SD card

By the way, when starting to use the SD card this way, I did include it to fstab, but it brought me the system not starting on resume or power up, so currently I'm using the way described above.

The output from kernel is:

ૐ » ~ λ dmesg | tail -n 10
[87713.372892] mmcblk0: error -110 sending status command, aborting
[87713.372898] blk_update_request: I/O error, dev mmcblk0, sector 2050
[87713.372986] EXT4-fs (mmcblk0p1): unable to read superblock
[87790.817694] mmc0: card 59b4 removed
[87794.836239] mmc0: cannot verify signal voltage switch
[87794.955839] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[87794.956111] mmcblk0: mmc0:59b4 SD64G 59.0 GiB
[87794.959661] mmcblk0: p1
[87797.141293] EXT4-fs (mmcblk0p1): recovery complete
[87797.148999] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
ૐ » ~ λ uname -a
Linux vaio 3.19.0-56-generic #62~14.04.1-Ubuntu SMP Fri Mar 11 11:03:15 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Any idea by these days? Some workaround? Some bug fix? Something out of kernel compilation?

Ivan Garavito, it will help immensely if you filed a new report with the Ubuntu repository kernel (not mainline/upstream) via a terminal:
ubuntu-bug linux

Please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.

Mat (mafeuser) wrote :

I experience the same problem running lubuntu.16.04.
Before the hibernation I have /dev/mmcblk0p1 mounted.
Then I hibernate my system and just after comming back from hibernation system informs me that new filesystem was mounted - it is the one sitting on /dev/mmcblk0p1, which should not have been unmounted. Shortly after that, system gets corrupted with I/O errors in syslog and I have to do hard restart.

Ivan Garavito, did You manage to file a separate bug on that?

regards,
Mat

Ivan Garavito (ivangaravito) wrote :

Hi Mat, I had these error when using fat32, so I switched to ext4 on my sdcard and that solved the filesystem corrupted errors.

On aug 2016, I upgraded to Ubuntu Gnome 16.04, but the problem turned to the driver, so I found the solution at https://github.com/astyonax/patched-RTS5227-5229, with some little changes it works again with no problems, just I have to recompile after each kernel update.

Hope this helps you.

regards,
Ivan Garavito

Mat (mafeuser) wrote :

Ivan,
thank You for the answer.

Unfortunatelly my sd card reader seems to be different one:

$ sudo lspci
...
05:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
...

regards,
Mat

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.