Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 49

Thread: Kernel bug ? unknown partition table on some usb flash drives

  1. #21

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    Quote Originally Posted by robin_listas View Post
    On 2014-07-13 20:26, robertot5 wrote:

    > You mean watching "tail -f /var/log/messages" while running "mount -v
    > /dev/sdb /mnt/flashdrive" ?


    Absolutely! :-)


    > I just ran that and it doesn't append anything in /var/log/messages
    > mount -v /dev/sdb /mnt/flashdrive


    There has to be something. :-o

    I just tried with a stick of mine, with a valid partition table; but attempting to mount the raw device instead:


    Code:
    Telcontar:~ # mount -v /dev/sda  /mnt/tmp
    mount: /dev/sda is write-protected, mounting read-only
    mount: wrong fs type, bad option, bad superblock on /dev/sda,
    missing codepage or helper program, or other error
    
    In some cases useful info is found in syslog - try
    dmesg | tail or so.
    Telcontar:~ #
    syslog:

    Code:
    <0.4> 2014-07-13 23:57:18 Telcontar kernel - - - [440237.395486] UDF-fs: warning (device sda): udf_fill_super: No partition found (2)

    and dmesg says (the last line is the one):


    Code:
    [440223.958541] scsi 15:0:0:0: Direct-Access     TOSHIBA  TransMemory      1.00 PQ: 0 ANSI: 4
    [440223.958749] sd 15:0:0:0: Attached scsi generic sg0 type 0
    [440223.961049] sd 15:0:0:0: [sda] 15155200 512-byte logical blocks: (7.75 GB/7.22 GiB)
    [440223.961656] sd 15:0:0:0: [sda] Write Protect is off
    [440223.961659] sd 15:0:0:0: [sda] Mode Sense: 45 00 00 00
    [440223.962284] sd 15:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
    [440223.965914]  sda: sda1
    [440223.969033] sd 15:0:0:0: [sda] Attached SCSI removable disk
    [440237.395486] UDF-fs: warning (device sda): udf_fill_super: No partition found (2)
    Telcontar:~ #

    I can force the issue, and assume that it is an vfat filesystem (which it is not):


    Code:
    Telcontar:~ # mount -v -t vfat /dev/sda  /mnt/tmp
    mount: wrong fs type, bad option, bad superblock on /dev/sda,
    missing codepage or helper program, or other error
    
    In some cases useful info is found in syslog - try
    dmesg | tail or so.
    Telcontar:~ #

    And syslog says:


    Code:
    <0.3> 2014-07-14 00:01:35 Telcontar kernel - - - [440494.339191] FAT-fs (sda): invalid media value (0xb9)
    <0.6> 2014-07-14 00:01:35 Telcontar kernel - - - [440494.339195] FAT-fs (sda): Can't find a valid FAT filesystem

    which is correct and expected.


    There has to be something in the log.


    In your case, there is the possibility that your stick is formatted as "exfat", which is not supported by openSUSE and can not be mounted.

    Frankly, I expected to see in the log how mount tried several filesytem types and failed.


    Maybe... Have a look at "/etc/sysconfig/syslog", this line:

    KERNEL_LOGLEVEL=7

    You probably have "1" in there.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)
    This is weird, my syslog and dmesg doesn't say anything when mounting a good flash drive, as in your previous post.

    I tried mounting the whole raw drive as "mount -v /dev/sdb /mnt/flashdrive" and nothing showed up in syslog or dmesg, all I get is the
    Code:
    mount: wrong fs type, bad option, bad superblock on /dev/sdb,       missing codepage or helper program, or other error
    
    
           In some cases useful info is found in syslog - try
           dmesg | tail or so.
    I then mounted sdb1 on the working flash drive, it mounted correctly but, still, nothing showed up in either /var/log/messages or dmesg.

    I then unmounted sdb1, no changes in the logs.

    I then unmounted the drive using the graphical applet near the clock, the device notifier thingy and this caused a line to appear in the syslog
    Code:
    2014-07-14T04:17:13.214139+03:00 linux-jspa udisksd[2700]: Cleaning up mount point /run/media/roberto/ADATA (device 8:17 is not mounted)
    I went in /etc/sysconfig/syslog and I do not have that line, mine looks like this
    Code:
    cat /etc/sysconfig/syslog## Type:           string
    ## Default:        ""
    ## Config:         ""
    ## ServiceRestart: syslog
    #
    # Parameters for rsyslogd, except of the version compatibility (-c)
    # and the config file (-f), because they're used by sysconfig and
    # earlysysconfig init scripts.
    #
    # See also the RSYSLOGD_COMPAT_VERSION variable in this file, the
    # documentation provided in /usr/share/doc/packages/rsyslog/doc by
    # the rsyslog-doc package and the rsyslogd(8) and rsyslog.conf(5)
    # manual pages.
    #
    RSYSLOGD_PARAMS=""
    L.E: I found out that mounting the drive's partition using the device notifier applet does write to the log
    Code:
    2014-07-14T04:30:07.132309+03:00 linux-jspa udisksd[2700]: Mounted /dev/sdb1 at /run/media/roberto/ADATA on behalf of uid 1000



    Is my logging system misconfigured or something like that ? I'm running 3.15.5-1
    OpenSUSE Leap 42.2 x64 KDE

  2. #22
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    On 2014-07-14 03:36, robertot5 wrote:

    > This is weird, my syslog and dmesg doesn't say anything when mounting a
    > good flash drive, as in your previous post.


    It is weird, but even on my system I do not get the output I was
    expecting. I was used to get way, way more.

    I would suggest to try something like this:

    Code:
    mount -t vfat -v /dev/sdb /mnt/flashdrive
    Try vfat and ntfs. Or find out in Windows what filesystem it actually
    has. Maybe in Windows disk properties it tells somewhere if it is using
    a partition entry or not.

    If Windows says "exfat", then we need go a very different road, so it is
    important to find out.


    >
    > I went in /etc/sysconfig/syslog and I do not have that line, mine looks
    > like this


    Apparently they don't add it now, I checked on another system. I added
    it there; I suppose it still works, but I'm not absolutely sure.

    You can just try to add the parameter, it will not harm. It might do
    nothing, but no harm either.


    > L.E: I found out that mounting the
    > drive's partition using the device notifier applet does write to the log


    Yes, but that's trivial stuff, nothing that really helps with your issue
    with your faulty usb stick...

    We need actual debugging output from the failed mount attempt. Telling
    us "wrong fs type, bad option, bad superblock on /dev/sdb, missing
    codepage or helper program, or other error" is utterly stupid, it help
    us nought. It is one thing or another, that "something went wrong" tells
    us nothing! We already know that something went wrong. We need to know
    exactly what went wrong.

    That info previously went to syslog, but on 13.1 it is not there either :-/



    I tried "dmesg --follow -k -l debug" and got nothing. Not even a line
    that did go to syslog.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  3. #23

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    Quote Originally Posted by robin_listas View Post
    On 2014-07-14 03:36, robertot5 wrote:

    > This is weird, my syslog and dmesg doesn't say anything when mounting a
    > good flash drive, as in your previous post.


    It is weird, but even on my system I do not get the output I was
    expecting. I was used to get way, way more.

    I would suggest to try something like this:

    Code:
    mount -t vfat -v /dev/sdb /mnt/flashdrive
    Try vfat and ntfs. Or find out in Windows what filesystem it actually
    has. Maybe in Windows disk properties it tells somewhere if it is using
    a partition entry or not.

    If Windows says "exfat", then we need go a very different road, so it is
    important to find out.


    >
    > I went in /etc/sysconfig/syslog and I do not have that line, mine looks
    > like this


    Apparently they don't add it now, I checked on another system. I added
    it there; I suppose it still works, but I'm not absolutely sure.

    You can just try to add the parameter, it will not harm. It might do
    nothing, but no harm either.


    > L.E: I found out that mounting the
    > drive's partition using the device notifier applet does write to the log


    Yes, but that's trivial stuff, nothing that really helps with your issue
    with your faulty usb stick...

    We need actual debugging output from the failed mount attempt. Telling
    us "wrong fs type, bad option, bad superblock on /dev/sdb, missing
    codepage or helper program, or other error" is utterly stupid, it help
    us nought. It is one thing or another, that "something went wrong" tells
    us nothing! We already know that something went wrong. We need to know
    exactly what went wrong.

    That info previously went to syslog, but on 13.1 it is not there either :-/



    I tried "dmesg --follow -k -l debug" and got nothing. Not even a line
    that did go to syslog.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)
    It is FAT32, formatted using Windows

    I did "mount -t vfat -v /dev/sdb /mnt/flashdrive" and surprisingly I got some lines in dmesg
    Code:
    [65245.971795] FAT-fs (sdb): invalid media value (0xd8)
    [65245.971800] FAT-fs (sdb): Can't find a valid FAT filesystem
    OpenSUSE Leap 42.2 x64 KDE

  4. #24
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    On 2014-07-14 11:06, robertot5 wrote:

    > It is FAT32, formatted using Windows
    >
    > I did "mount -t vfat -v /dev/sdb /mnt/flashdrive" and surprisingly I got
    > some lines in dmesg
    >
    > Code:
    > --------------------
    > [65245.971795] FAT-fs (sdb): invalid media value (0xd8)
    > [65245.971800] FAT-fs (sdb): Can't find a valid FAT filesystem
    >
    > --------------------


    Ok!

    That is indeed progress. Not good news, unfortunately.

    Being confirmed that it is FAT, the above would have worked IF the
    filesystem was in /dev/sdb, but it is not. The filesystem then is then
    in a partition, and Linux can not read that partition table for I don't
    know what reason.


    My suggestion would be that you backup the contents, then in Linux,
    create an image of the entire disk (so that you can go back and
    reconstruct if things go badly), then erase the start of the disk with
    dd (say 100 MB), to completely destroy the partition layout, then create
    a new partition table, with one entry for one fat partition, and format
    it. All that can be done with gparted.


    Unless somebody can find out what is wrong with that partition table...


    On 2014-07-13 01:26, robertot5 wrote:

    > Found a 2008 bug report with exactly the same issue
    >
    >
    > https://bugzilla.kernel.org/show_bug.cgi?id=10808


    They mention using "disktype".

    Comment 22 is suggestive, faulty hardware.

    Comment 24 has an explanation why Windows works.

    Basically, the first read of the partition table return bad data, but
    saying it is good. Later attempts return good data. Aparently Windows
    does several runs, while Linux trusts the first one if no error is reported.

    In that case, a reformat would fail. However, your fdisk output was
    incorrect, while in the bug report fdisk gets correct data - so maybe
    your problem is not the same one.


    Comment 25 has a possible workaround.


    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  5. #25

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    Quote Originally Posted by robin_listas View Post
    On 2014-07-14 11:06, robertot5 wrote:

    > It is FAT32, formatted using Windows
    >
    > I did "mount -t vfat -v /dev/sdb /mnt/flashdrive" and surprisingly I got
    > some lines in dmesg
    >
    > Code:
    > --------------------
    > [65245.971795] FAT-fs (sdb): invalid media value (0xd8)
    > [65245.971800] FAT-fs (sdb): Can't find a valid FAT filesystem
    >
    > --------------------


    Ok!

    That is indeed progress. Not good news, unfortunately.

    Being confirmed that it is FAT, the above would have worked IF the
    filesystem was in /dev/sdb, but it is not. The filesystem then is then
    in a partition, and Linux can not read that partition table for I don't
    know what reason.


    My suggestion would be that you backup the contents, then in Linux,
    create an image of the entire disk (so that you can go back and
    reconstruct if things go badly), then erase the start of the disk with
    dd (say 100 MB), to completely destroy the partition layout, then create
    a new partition table, with one entry for one fat partition, and format
    it. All that can be done with gparted.


    Unless somebody can find out what is wrong with that partition table...


    On 2014-07-13 01:26, robertot5 wrote:

    > Found a 2008 bug report with exactly the same issue
    >
    >
    > https://bugzilla.kernel.org/show_bug.cgi?id=10808


    They mention using "disktype".

    Comment 22 is suggestive, faulty hardware.

    Comment 24 has an explanation why Windows works.

    Basically, the first read of the partition table return bad data, but
    saying it is good. Later attempts return good data. Aparently Windows
    does several runs, while Linux trusts the first one if no error is reported.

    In that case, a reformat would fail. However, your fdisk output was
    incorrect, while in the bug report fdisk gets correct data - so maybe
    your problem is not the same one.


    Comment 25 has a possible workaround.


    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)
    then erase the start of the disk with
    dd (say 100 MB)
    can you give me an example of dd command ?
    Should be something like dd if=/dev/zero of=/dev/sdb bs=1M count=100 ?
    OpenSUSE Leap 42.2 x64 KDE

  6. #26
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    On 2014-07-15 00:06, robertot5 wrote:

    >> then erase the start of the disk with
    >> dd (say 100 MB) can you give me an example of dd command ?

    > Should be something like dd if=/dev/zero of=/dev/sdb bs=1M count=100 ?


    Yep. Exactly that. :-)

    Of course, you have to be absolutely sure that "/dev/sdb" is your usb
    stick, or you will destroy something else.

    Disclaimer: I can not guarantee that re-partition and re-format will
    solve the issue. But if the stick were mine, that's what I would do. But
    then, if it did not work, it would be my money I'd waste, not yours...

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  7. #27

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    Quote Originally Posted by robin_listas View Post
    On 2014-07-15 00:06, robertot5 wrote:

    >> then erase the start of the disk with
    >> dd (say 100 MB) can you give me an example of dd command ?

    > Should be something like dd if=/dev/zero of=/dev/sdb bs=1M count=100 ?


    Yep. Exactly that. :-)

    Of course, you have to be absolutely sure that "/dev/sdb" is your usb
    stick, or you will destroy something else.

    Disclaimer: I can not guarantee that re-partition and re-format will
    solve the issue. But if the stick were mine, that's what I would do. But
    then, if it did not work, it would be my money I'd waste, not yours...

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)
    Yes it fixed the drive, and to be honest I knew that formatting it from scratch will, but the thing question is - can' we change how Linux behaves in cases like this ? Make it ignore the "bad" stuff like Windows does and just mount it ?
    OpenSUSE Leap 42.2 x64 KDE

  8. #28
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,235

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    On 07/15/2014 05:16 PM, robertot5 wrote:
    > Yes it fixed the drive, and to be honest I knew that formatting it from
    > scratch will, but the thing question is - can' we change how Linux
    > behaves in cases like this ? Make it ignore the "bad" stuff like Windows
    > does and just mount it ?


    You are welcome to create and submit a patch to the kernel for any issue. If you
    do not have the expertise to handle this, then you will need to file a feature
    request through bugzilla.kernel.org.



  9. #29
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    On 2014-07-16 00:16, robertot5 wrote:
    >
    > robin_listas;2654009 Wrote:



    > Yes it fixed the drive, and to be honest I knew that formatting it from
    > scratch will, but the thing question is - can' we change how Linux
    > behaves in cases like this ? Make it ignore the "bad" stuff like Windows
    > does and just mount it ?


    Well, if you have one of those faulty sticks, you can open a bug at
    openSUSE's bugzilla, and hope somebody traces it.

    If the stick is brand new and empty, you can create an image of it,
    compress with xz, which should compress into a very little thing, and
    attach the image to the bug report. That way, even if they take two
    years to look at it, they will have the image to study ;-)

    If you find an interested and willing developer, you could mail the
    stick to him, via surface mail.

    Or you can simply add the model names to the bug report.

    There are also some identification strings on connect - they are on some
    of your posts here:

    Code:
    usb 2-1: New USB device found, idVendor=13fe, idProduct=4100
    usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 2-1: Product: USB DISK 2.0
    usb 2-1: Manufacturer:
    usb 2-1: SerialNumber: 070D27888255C220
    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  10. #30

    Default Re: Kernel bug ? unknown partition table on some usb flash drives

    Quote Originally Posted by robin_listas View Post
    On 2014-07-16 00:16, robertot5 wrote:
    >
    > robin_listas;2654009 Wrote:



    > Yes it fixed the drive, and to be honest I knew that formatting it from
    > scratch will, but the thing question is - can' we change how Linux
    > behaves in cases like this ? Make it ignore the "bad" stuff like Windows
    > does and just mount it ?


    Well, if you have one of those faulty sticks, you can open a bug at
    openSUSE's bugzilla, and hope somebody traces it.

    If the stick is brand new and empty, you can create an image of it,
    compress with xz, which should compress into a very little thing, and
    attach the image to the bug report. That way, even if they take two
    years to look at it, they will have the image to study ;-)

    If you find an interested and willing developer, you could mail the
    stick to him, via surface mail.

    Or you can simply add the model names to the bug report.

    There are also some identification strings on connect - they are on some
    of your posts here:

    Code:
    usb 2-1: New USB device found, idVendor=13fe, idProduct=4100
    usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    usb 2-1: Product: USB DISK 2.0
    usb 2-1: Manufacturer:
    usb 2-1: SerialNumber: 070D27888255C220
    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)
    I do have an image of the flash drive made with DD.

    This particular flash drive is Team Group 4GB model C101 but I had the issues with other flash drives, know brands like Kingston, ADATA, SanDisk.
    OpenSUSE Leap 42.2 x64 KDE

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •