Launchpad has imported 11 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=730502.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-08-13T20:19:37+00:00 Sandro wrote: I've selected lvm2 as component because it seemed the most related component but I don't really know if it is the right choice. Description of problem: This morning my system worked fine. After reboot without any new install the system now tell me that no root can be found and where it should be an ext4 file system now it seems that there is a silicon_medley_raid_member. Executed S.M.A.R.T. short test by BIOS, everything is ok. Using the F15 DVD I've opened a rescue shell, executed vgck and pvck and everything seemed ok. Activated the lvm volume, called fsck.ext4 -v on vg_root, no errors found. Called fsck.ext4 -f -v on vg_root, no errors found. mount -t ext4 of vg_root works fine but if not specified, the fs type detected is silicon_medley_raid_member. I'm doing a backup of all relevant data on my system but I would understand what is happened and, if possible, restore the system without reinstalling everything. How reproducible: Always reproducible Any idea on what happened? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/0 ------------------------------------------------------------------------ On 2011-08-14T12:19:32+00:00 Milan wrote: Seems that system now see some fake raid signature on the disk, I guess mdadm update started to recognize some old SiL RAID signature. If you do not use raid, try to add rd_NO_MD to kernel boot parameters (or equivalent, see man dracut / dracut.kernel). Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/1 ------------------------------------------------------------------------ On 2011-08-17T10:11:22+00:00 Sandro wrote: rd_NO_MD and rd_NO_DM already specified in grub kernel boot parameters. The notebook has no bios raid and just 1HD, I never used RAID on this system. It seems something like this: http://ubuntuforums.org/showthread.php?t=1711929 The only difference is that I'm using ext4 instead of ext3 so ext4 works fine if specified. Maybe ext4 and silicon_medley_raid_member have similar signature and just some bits are somehow corrupted? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/2 ------------------------------------------------------------------------ On 2011-08-17T10:37:17+00:00 Sandro wrote: BLKID_DEBUG=0xffff blkid on the lvm volu,e says: libblkid: debug mask set to 0xffff. creating blkid cache (using default cache) need to revalidate lv_root (cache time 2147483648.0, stat time 1313584184.138354, time since last check 3461068058) ready for low-probing, offset=0, size=20971520000 found entire diskname for devno 0xfd01 as dm-1 whole-disk: YES, regfile: NO zeroize wiper chain safeprobe superblocks ENABLED --> starting probing loop [SUBLKS idx=-1] [0] linux_raid_member: call probefunc() buffer read: off=20971454464 len=64 buffer read: off=20971511808 len=256 buffer read: off=0 len=256 buffer read: off=4096 len=256 [1] ddf_raid_member: call probefunc() buffer read: off=20971519488 len=512 buffer read: off=20971388416 len=512 [2] isw_raid_member: call probefunc() buffer read: off=20971518976 len=48 [3] lsi_mega_raid_member: call probefunc() reuse buffer: off=20971519488 len=512 [4] via_raid_member: call probefunc() reuse buffer: off=20971519488 len=512 [5] silicon_medley_raid_member: call probefunc() reuse buffer: off=20971519488 len=512 assigning TYPE [superblocks] <-- leaving probing loop (type=silicon_medley_raid_member) [SUBLKS idx=5] chain safeprobe topology DISABLED chain safeprobe partitions DISABLED zeroize wiper returning TYPE value creating new cache tag head TYPE lv_root: devno 0xfd01, type silicon_medley_raid_member reseting probing buffers buffers summary: 1904 bytes by 7 read() call(s) lv_root: TYPE="silicon_medley_raid_member" writing cache file /etc/blkid/blkid.tab (really /etc/blkid/blkid.tab) freeing cache struct freeing dev lv_root (silicon_medley_raid_member) dev: name = lv_root dev: DEVNO="0xfd01" dev: TIME="1313584410.543761" dev: PRI="0" dev: flags = 0x00000001 tag: TYPE="silicon_medley_raid_member" freeing tag TYPE=silicon_medley_raid_member tag: TYPE="silicon_medley_raid_member" freeing tag TYPE=(NULL) tag: TYPE="(null)" Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/3 ------------------------------------------------------------------------ On 2011-08-17T10:38:34+00:00 Milan wrote: I do not think blkid detect it wrongly, perhaps just there are both signatures. Perhaps "dmraid -E" or wipefs can wipe the fake raid signature? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/4 ------------------------------------------------------------------------ On 2011-08-17T10:58:10+00:00 Sandro wrote: wipefs on lv_root shows: offset type ---------------------------------------------------------------- 0x438 ext4 [filesystem] UUID: 0fb3d4f8-fea5-4d22-ae67-91e897d67c14 0x4e1fffe60 silicon_medley_raid_member [raid] Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/5 ------------------------------------------------------------------------ On 2011-08-17T11:52:51+00:00 Heinz wrote: (In reply to comment #5) > wipefs on lv_root shows: > > > offset type > ---------------------------------------------------------------- > 0x438 ext4 [filesystem] > UUID: 0fb3d4f8-fea5-4d22-ae67-91e897d67c14 > > 0x4e1fffe60 silicon_medley_raid_member [raid] Did you try "dmraid -E" yet, like Milan proposed? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/6 ------------------------------------------------------------------------ On 2011-08-17T12:04:06+00:00 Sandro wrote: dmraid -E -r says no raid disk with name lv_root. The offset for silicon_medley_raid_member seems to be quite high. Is it safe to call wipefs -o 0x4e1fffe60 on lv_root? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/7 ------------------------------------------------------------------------ On 2011-08-17T12:47:24+00:00 Sandro wrote: called wipefs -o 0x4e1fffe60 on lv_root, now the mount command detects correctly ext4 fs. The system now can boot. Any idea on what have caused this issue or any hint on where searching the cause? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/8 ------------------------------------------------------------------------ On 2011-08-17T13:09:17+00:00 Milan wrote: That disk was probably part of fake raid array before and signature was still there. After mdadm or blkid update it starts to prefer raid signature before ext4 one. I guess the issue can be closed now, right? Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/9 ------------------------------------------------------------------------ On 2011-08-22T20:59:43+00:00 Sandro wrote: (In reply to comment #9) > That disk was probably part of fake raid array before and signature was still > there. Never used RAID on that system. If the signature was there, it was just garbage left from a previous partition not zeroed during a partition resizing / format. > After mdadm or blkid update it starts to prefer raid signature before ext4 > one. > > I guess the issue can be closed now, right? Well, the system now seems to be ok. I'm just curious about the dynamic of the incident but I can set the status to closed notabug. I've choosen notabug because I can't find any evidence that a specific package caused the issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1011007/comments/10 ** Changed in: fedora Status: Unknown => Invalid ** Changed in: fedora Importance: Unknown => Critical -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1011007 Title: blkid identifies ext4 rootfs as silicon_medley_raid_member, breaks boot Status in util-linux package in Ubuntu: Confirmed Status in Fedora: Invalid Bug description: Ubuntu does not boot /disk/by-uuid not found blkid reports silicon_medley_raid_member tryed this https://bugzilla.redhat.com/show_bug.cgi?id=730502 tips: find out what's on the disk at the specified location ubuntu@ubuntu:/media$ sudo env BLKID_DEBUG=0xffff blkid -p /dev/sda1libblkid: debug mask set to 0xffff. ready for low-probing, offset=0, size=497968742400 chain fullprobe superblocks: DISABLED chain fullprobe topology: DISABLED chain fullprobe partitions: ENABLED --> starting probing loop [PARTS idx=-1] buffer read: off=0 len=1024 reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 gpt: ---> call probefunc() reuse buffer: off=0 len=1024 gpt: <--- (rc = 1) reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 buffer read: off=28672 len=1024 reuse buffer: off=0 len=1024 reuse buffer: off=0 len=1024 <-- leaving probing loop (failed) [PARTS idx=9] chain safeprobe superblocks ENABLED --> starting probing loop [SUBLKS idx=-1] [0] linux_raid_member: call probefunc() buffer read: off=497968676864 len=64 buffer read: off=497968734208 len=64 reuse buffer: off=0 len=1024 buffer read: off=4096 len=64 [1] ddf_raid_member: call probefunc() buffer read: off=497968741888 len=40 buffer read: off=497968610816 len=40 [2] isw_raid_member: call probefunc() buffer read: off=497968741376 len=48 [3] lsi_mega_raid_member: call probefunc() reuse buffer: off=497968741888 len=40 [4] via_raid_member: call probefunc() buffer read: off=497968741888 len=51 [5] silicon_medley_raid_member: call probefunc() buffer read: off=497968741888 len=292 assigning VERSION [superblocks] assigning TYPE [superblocks] assigning USAGE [superblocks] <-- leaving probing loop (type=silicon_medley_raid_member) [SUBLKS idx=5] chain safeprobe topology DISABLED chain safeprobe partitions DISABLED returning VERSION value /dev/sda1: VERSION="25697.25960" returning TYPE value TYPE="silicon_medley_raid_member" returning USAGE value USAGE="raid" reseting probing buffers buffers summary: 42949675671 bytes by 617802423873589236 read() call(s) ubuntu@ubuntu:/media$ sudo dd if=/dev/sda1 bs=1 skip=497968741887 count=200 | od -tx1z 0000000 13 03 bf 1b 67 42 9a 00 00 00 00 2f 75 73 72 2f >....gB...../usr/< 0000020 73 72 63 2f 6c 69 6e 75 78 2d 68 65 61 64 65 72 >src/linux-header< 0000040 73 2d 32 2e 36 2e 33 38 2d 38 2d 67 65 6e 65 72 >s-2.6.38-8-gener< 0000060 69 63 2f 69 6e 63 6c 75 64 65 2f 63 6f 6e 66 69 >ic/include/confi< 0000100 67 2f 63 79 63 6c 61 64 65 73 00 00 73 79 6e 63 >g/cyclades..sync< 0000120 2e 68 00 02 00 00 00 00 4e 13 03 bf 1b 67 42 9a >.h......N....gB.< 0000140 00 00 00 00 2f 75 73 72 2f 73 72 63 2f 6c 69 6e >..../usr/src/lin< 0000160 75 78 2d 68 65 61 64 65 72 73 2d 32 2e 36 2e 33 >ux-headers-2.6.3< 0000200 38 2d 38 2d 67 65 6e 65 72 69 63 2f 69 6e 63 6c >8-8-generic/incl< 0000220 75 64 65 2f 63 6f 6e 66 69 67 2f 63 79 63 6c 6f >ude/config/cyclo< 0000240 6d 78 00 00 78 32 35 2e 68 00 02 00 00 00 00 4e >mx..x25.h......N< 0000260 13 03 bf 1b 67 42 9a 00 00 00 00 2f 75 73 72 2f >....gB...../usr/< 0000300 73 72 63 2f 6c 69 6e 75 >src/linu< 0000310 in my case it was a file linux-headers-2.6.38-8-generic.list so i simply overwriten it ubuntu@ubuntu:/media$ sudo dd if=/dev/zero bs=1 count=292 seek=497968741888 of=/dev/sda1 292+0 records in 292+0 records out 292 bytes (292 B) copied, 0.000560058 s, 521 kB/s ubuntu@ubuntu:/media$ sudo dd if=/dev/sda1 bs=1 skip=497968741887 count=200 | od -tx1z 0000000 13 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< * 0000300 00 00 00 00 00 00 00 00 >........< 0000310 200+0 records in 200+0 records out 200 bytes (200 B) copied, 0.00189193 s, 106 kB/s ProblemType: Bug DistroRelease: Ubuntu 10.04 Package: udisks 1.0.1-1ubuntu1 ProcVersionSignature: Ubuntu 2.6.32-33.70-generic 2.6.32.41+drm33.18 Uname: Linux 2.6.32-33-generic i686 Architecture: i386 Date: Sat Jun 9 21:35:05 2012 LiveMediaBuild: Ubuntu 10.04.3 LTS "Lucid Lynx" - Release i386 (20110720.1) MachineType: Dell Inc. Inspiron 1525 ProcCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/hostname.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: udisks Symptom: storage Title: Internal hard disk partition cannot be mounted manually dmi.bios.date: 06/27/2008 dmi.bios.vendor: Dell Inc. dmi.bios.version: A13 dmi.board.name: 0U990C dmi.board.vendor: Dell Inc. dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA13:bd06/27/2008:svnDellInc.:pnInspiron1525:pvr:rvnDellInc.:rn0U990C:rvr:cvnDellInc.:ct8:cvr: dmi.product.name: Inspiron 1525 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1011007/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
