Bug#830300: RE: Bug#830300: bug in mdadm

[Любен Каравелов]

I will give it a try in 5 days (currently I am away from the machine and don't 
want to experiment if it can boot or not with the new conig) and will report 
back. Thanks for the suggestion.

- Цитат от Michael Biebl (bi...@debian.org), на 26.07.2016 в 15:36 -

> On Sat, 9 Jul 2016 19:47:07 +0300
> =?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
> wrote:
>> Hi,
>> 
>> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) 
>> is using Intel RAID0 setup:
>> 
>> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
>> [RAID mode] (rev 04)
>> 
>> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
>> working out of the box). My understanding is that for some reason mdadm is 
>> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
>> assembly to bypass this check with the envvars until this was also broken by 
>> the last mdadm update.
>> 
>> BTW, I also tried another workaround but it does not work also for me with 
>> the last debian mdadm package:
>> https://bbs.archlinux.org/viewtopic.php?id=202597
>> 
>> For the moment I downgraded the mdadm and put it on hold.
>> 
>> Any other suggestions are welcome.
>> 
> 
> You mentioned you tried the workaround from the arch forum, I suspect
> you meant https://bbs.archlinux.org/viewtopic.php?pid=1565988#p1565988
> specifically.
> Keep in mind, that you need to rebuild the initramfs (via
> update-initramfs -u) after changing the udev rule.
> 
> 
> # lsinitramfs /boot/initrd.img-$(uname -r) | grep env
> shows that the initramfs installs the env utility under /bin/env and not
> /usr/bin/env. So this would need to be considered when changing
> 64-md-raid-assembly.rules.
> 
> Maybe it's better to use --force instead, as upstream suggests.
> The attached rules files should do that (please double check).
> Please copy that to /etc/udev/rules.d/, update your initramfs via
> update-initramfs -u and try again.
> 
> Regards,
> Michael
> 
> 
> 
> *) It's usually also better to copy the file to /etc/udev/rules.d/ and
> edit it there, so the file is not overwritten on upgrades.
> 
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
--
Luben Karavelov

Bug#830300: RE: Bug#830300: bug in mdadm

[Michael Biebl]

On Sat, 9 Jul 2016 19:47:07 +0300
=?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
wrote:
> Hi,
> 
> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) is 
> using Intel RAID0 setup:
> 
> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
> [RAID mode] (rev 04)
> 
> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
> working out of the box). My understanding is that for some reason mdadm is 
> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
> assembly to bypass this check with the envvars until this was also broken by 
> the last mdadm update.
> 
> BTW, I also tried another workaround but it does not work also for me with 
> the last debian mdadm package:
> https://bbs.archlinux.org/viewtopic.php?id=202597
> 
> For the moment I downgraded the mdadm and put it on hold.
> 
> Any other suggestions are welcome.
> 

You mentioned you tried the workaround from the arch forum, I suspect
you meant https://bbs.archlinux.org/viewtopic.php?pid=1565988#p1565988
specifically.
Keep in mind, that you need to rebuild the initramfs (via
update-initramfs -u) after changing the udev rule.


# lsinitramfs /boot/initrd.img-$(uname -r) | grep env
shows that the initramfs installs the env utility under /bin/env and not
/usr/bin/env. So this would need to be considered when changing
64-md-raid-assembly.rules.

Maybe it's better to use --force instead, as upstream suggests.
The attached rules files should do that (please double check).
Please copy that to /etc/udev/rules.d/, update your initramfs via
update-initramfs -u and try again.

Regards,
Michael



*) It's usually also better to copy the file to /etc/udev/rules.d/ and
edit it there, so the file is not overwritten on upgrades.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
# do not edit this file, it will be overwritten on update

# Don't process any events if anaconda is running as anaconda brings up
# raid devices manually
ENV{ANACONDA}=="?*", GOTO="md_inc_end"
# assemble md arrays

SUBSYSTEM!="block", GOTO="md_inc_end"

# handle potential components of arrays (the ones supported by md)
ENV{ID_FS_TYPE}=="linux_raid_member", GOTO="md_inc"

# "noiswmd" on kernel command line stops mdadm from handling
#  "isw" (aka IMSM - Intel RAID).
# "nodmraid" on kernel command line stops mdadm from handling
#  "isw" or "ddf".
IMPORT{cmdline}="noiswmd"
IMPORT{cmdline}="nodmraid"

ENV{nodmraid}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="ddf_raid_member", GOTO="md_inc"
ENV{noiswmd}=="?*", GOTO="md_inc_end"
ENV{ID_FS_TYPE}=="isw_raid_member", GOTO="md_inc"
GOTO="md_inc_end"

LABEL="md_inc"

# remember you can limit what gets auto/incrementally assembled by
# mdadm.conf(5)'s 'AUTO' and selectively whitelist using 'ARRAY'
ACTION=="add|change", IMPORT{program}="/sbin/mdadm --force --incremental 
--export $devnode --offroot ${DEVLINKS}"
ACTION=="add|change", ENV{MD_STARTED}=="*unsafe*", ENV{MD_FOREIGN}=="no", 
ENV{SYSTEMD_WANTS}+="mdadm-last-resort@$env{MD_DEVICE}.timer"
ACTION=="remove", ENV{ID_PATH}=="?*", RUN+="/sbin/mdadm -If $name --path 
$env{ID_PATH}"
ACTION=="remove", ENV{ID_PATH}!="?*", RUN+="/sbin/mdadm -If $name"

LABEL="md_inc_end"


signature.asc
Description: OpenPGP digital signature

Bug#830300: RE: Bug#830300: bug in mdadm

[Любен Каравелов]

- Цитат от Michael Biebl (bi...@debian.org), на 16.07.2016 в 15:10 -

> On Sat, 9 Jul 2016 19:47:07 +0300
> =?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
> wrote:
>> Hi,
>> 
>> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) 
>> is using Intel RAID0 setup:
>> 
>> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
>> [RAID mode] (rev 04)
>> 
>> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
>> working out of the box). My understanding is that for some reason mdadm is 
>> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
>> assembly to bypass this check with the envvars until this was also broken by 
>> the last mdadm update.
>> 
> 
> Have you filed a bug report back then?
> Seems to me that fixing the root cause is a better approach then keeping
> this workaround alive (and 3.4-2 out of testing).
> 
> Michael
> 

No, I have not. It seems that it's know that it misses
to detect some controllers:

http://marc.info/?l=linux-raid=143872588405500=2

The man page suggest upgrading the BIOS and I have done so
to the latest available version without any effect. 

BTW, here are the details of my controller:

~ # mdadm --detail-platform
   Platform : Intel(R) Rapid Storage Technology
Version : 12.7.0.1936
RAID Levels : raid0 raid1
Chunk Sizes : 4k 8k 16k 32k 64k 128k
2TB volumes : supported
  2TB disks : supported
  Max Disks : 6
Max Volumes : 2 per array, 4 per controller
 I/O Controller : /sys/devices/pci:00/:00:1f.2 (SATA)
  Port0 : /dev/sda (135178400807)
  Port1 : /dev/sdb (135178400963)
  Port2 : - no device attached -
  Port3 : - no device attached -

~ # lspci -v
...
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
[RAID mode] (rev 04)
Subsystem: ASUSTeK Computer Inc. 82801 Mobile SATA Controller [RAID 
mode]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 43
I/O ports at f0b0 [size=8]
I/O ports at f0a0 [size=4]
I/O ports at f090 [size=8]
I/O ports at f080 [size=4]
I/O ports at f060 [size=32]
Memory at f7d22000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Power Management version 3
Capabilities: [a8] SATA HBA v1.0
Kernel driver in use: ahci
Kernel modules: ahci
...
~ # dmidecode
# dmidecode 3.0
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
24 structures occupying 1689 bytes.
Table at 0xDAE7C018.

Handle 0x, DMI type 0, 24 bytes
BIOS Information
Vendor: American Megatrends Inc.
Version: UX301LAA.211
Release Date: 06/05/2015
Address: 0xF
Runtime Size: 64 kB
ROM Size: 6144 kB
Characteristics:
PCI is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
BIOS ROM is socketed
EDD is supported
5.25"/1.2 MB floppy services are supported (int 13h)
3.5"/720 kB floppy services are supported (int 13h)
3.5"/2.88 MB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
ACPI is supported
USB legacy is supported
Smart battery is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 4.6
...

and here is my mdadm.conf:

~ # cat /etc/mdadm/mdadm.conf   

 root@zenbook
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST 

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY metadata=imsm UUID=518b7355:90f15f1b:d74e62c6:e0c9c9da
ARRAY /dev/md/ASUS_OS container=518b7355:90f15f1b:d74e62c6:e0c9c9da member=0 
UUID=6274cc4a:a22ed1d4:7a1173d6:f24c1fc7

# This file was auto-generated on Tue, 12 Aug 2014 21:01:58 -0700
# by mkconf 3.3-2


Thanks in 

Bug#830300: RE: Bug#830300: bug in mdadm

[Michael Biebl]

On Sat, 9 Jul 2016 19:47:07 +0300
=?utf-8?B?0JvRjtCx0LXQvSDQmtCw0YDQsNCy0LXQu9C+0LI=?= 
wrote:
> Hi,
> 
> The problem I am trying to solve is that my laptop (ASUS Zenbook UX301LAA) is 
> using Intel RAID0 setup:
> 
> 00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller 
> [RAID mode] (rev 04)
> 
> But it stopped working 5-6 months ago (3.3.2-5 was the last version that was 
> working out of the box). My understanding is that for some reason mdadm is 
> not recognizing the setup as being a IMSM RAID and I was forcing the RAID 
> assembly to bypass this check with the envvars until this was also broken by 
> the last mdadm update.
> 

Have you filed a bug report back then?
Seems to me that fixing the root cause is a better approach then keeping
this workaround alive (and 3.4-2 out of testing).

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature