[Bug 1800836] Re: systemd-networkd doesn't process IPv6 RA properly
This bug is still present on Ubuntu 18.04.5 LTS with systemd 237-3ubuntu10.50. Please reopen. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1800836 Title: systemd-networkd doesn't process IPv6 RA properly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1800836/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906986] Re: defective ir-keytable udev rule → custom keytable does not get loaded
Probably. My (fully updated) 20.04.1 LTS box is still at version 1.18.0-2build1, though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1906986 Title: defective ir-keytable udev rule → custom keytable does not get loaded To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1906986/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1906986] [NEW] defective ir-keytable udev rule → custom keytable does not get loaded
Public bug reported:
ir-keytable v1.18.0-2build1 ships /lib/udev/rules.d/60-ir-keytable.rules
containing the following rule:
ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a
/etc/rc_maps.cfg -s $name"
After upgrading to Focal, this does not get triggered at boot, nor if I
(re)insert my receiver when the system is running. Therefore, the custom
keytable does not get loaded.
This is the udev events that occur when I insert the receiver:
$ sudo udevadm monitor
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
KERNEL[1195.829011] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
KERNEL[1195.834989] add /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
KERNEL[1195.874055] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
KERNEL[1195.875019] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
KERNEL[1195.875183] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
KERNEL[1196.134164] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
KERNEL[1196.134448] bind /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
KERNEL[1196.134704] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.158923] add /devices/pci:00/:00:14.0/usb1/1-3 (usb)
UDEV [1196.174559] add /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
UDEV [1196.194750] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/lirc0 (lirc)
UDEV [1196.196268] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11 (input)
UDEV [1196.197180] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/wakeup/wakeup21 (wakeup)
UDEV [1196.224577] add
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/rc/rc0/input11/event3 (input)
UDEV [1196.231346] bind /devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0
(usb)
UDEV [1196.244978] bind /devices/pci:00/:00:14.0/usb1/1-3 (usb)
Note how there's no «(rc)» displayed on any of the lines, which means
that the «SUBSYSTEM=="rc"» condition from the udev rule filters all of
the above events.
I found a rule that works at https://www.mail-archive.com/linux-
me...@vger.kernel.org/msg117165.html:
ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*",
ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s
$env{.rc_sysdev}"
Creating a custom /etc/udev/rules.d/60-ir-keytable.rules file containing
this rule solves the problem; now my custom keymap is loaded at boot, as
it did before (when I was running Bionic).
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ir-keytable 1.18.0-2build1 [modified: usr/bin/ir-keytable]
ProcVersionSignature: Ubuntu 5.4.0-56.62-generic 5.4.73
Uname: Linux 5.4.0-56-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.13
Architecture: amd64
CasperMD5CheckResult: skip
Date: Sun Dec 6 18:05:06 2020
SourcePackage: v4l-utils
UpgradeStatus: Upgraded to focal on 2020-12-06 (0 days ago)
** Affects: v4l-utils (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906986
Title:
defective ir-keytable udev rule → custom keytable does not get loaded
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/v4l-utils/+bug/1906986/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1889968] Re: [regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes I/O errors
** Attachment added: "Output from 'lshw'" https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.4/+bug/1889968/+attachment/5397631/+files/lshw.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1889968 Title: [regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes I/O errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.4/+bug/1889968/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1889968] [NEW] [regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes I/O errors
Public bug reported:
Somewhere between 4.15.0-112-generic and 5.3.0-62-generic the kernel
config option SATA_MOBILE_LPM_POLICY was changed from 0 (the upstream
default) to 3. This is causing frequent SATA link resets, resulting in
I/O stalls and errors. For example:
ata1.00: exception Emask 0x0 SAct 0xdc SErr 0x5 action 0x6 frozen
ata1: SError: { PHYRdyChg CommWake }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/20:90:d8:62:c6/00:00:24:00:00/40 tag 18 ncq dma 16384 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/20:98:60:26:1e/00:00:00:00:00/40 tag 19 ncq dma 16384 in
res 40/00:01:06:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/08:a0:78:85:11/00:00:03:00:00/40 tag 20 ncq dma 4096 out
res 40/00:00:00:4f:c2/00:01:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: cmd 61/10:b0:80:60:c6/00:00:24:00:00/40 tag 22 ncq dma 8192 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/08:b8:d0:13:ac/00:00:02:00:00/40 tag 23 ncq dma 4096 in
res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
ata1: hard resetting link
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: configured for UDMA/100
ata1.00: device reported invalid CHS sector 0
ata1.00: device reported invalid CHS sector 0
sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 0:0:0:0: [sda] tag#23 Sense Key : Illegal Request [current]
sd 0:0:0:0: [sda] tag#23 Add. Sense: Unaligned write command
sd 0:0:0:0: [sda] tag#23 CDB: Read(10) 28 00 02 ac 13 d0 00 00 08 00
blk_update_request: I/O error, dev sda, sector 44831696 op 0x0:(READ) flags
0x80700 phys_seg 1 prio class 0
ata1: EH complete
Available workarounds:
1) downgrading to 4.15.0-*-generic
2) appending 'ahci.mobile_lpm_policy=n' to the kernel command line, where 'n'
is either 0, 1 or 2.
The meanings of policy numbers can be found at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/Kconfig?h=v5.8-rc7#n118:
0 => Keep firmware settings
1 => Maximum performance
2 => Medium power
3 => Medium power with Device Initiated PM enabled
4 => Minimum power
The computer in question is an Intel NUC DN2820FYK (running the latest
system firmware version), containing an embedded Intel Corporation Atom
Processor E3800 Series SATA AHCI Controller (rev 0e) controller. The
hard drive is a HITACHI HTS723232L9SA60.
I have confirmed that the issue persists in the latest mainline kernel
build (5.8.0-050800rc7-generic).
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-5.4.0-42-generic 5.4.0-42.46~18.04.1
ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44
Uname: Linux 5.4.0-42-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.15
Architecture: amd64
Date: Sat Aug 1 10:51:29 2020
SourcePackage: linux-signed-hwe-5.4
UpgradeStatus: Upgraded to bionic on 2020-06-28 (33 days ago)
** Affects: linux-signed-hwe-5.4 (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug bionic
** Attachment added: "Kernel messages (contains further examples of the errors)"
https://bugs.launchpad.net/bugs/1889968/+attachment/5397627/+files/dmesg.txt
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1889968
Title:
[regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes
I/O errors
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.4/+bug/1889968/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1889968] Re: [regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes I/O errors
** Attachment added: "Output from 'smartctl -a /dev/sda'" https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.4/+bug/1889968/+attachment/5397632/+files/smartctl_-a__dev_sda.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1889968 Title: [regression] Changed CONFIG_SATA_MOBILE_LPM_POLICY=3 default causes I/O errors To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-signed-hwe-5.4/+bug/1889968/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] Re: AppArmor breaks the default Unbound installation in a live session
I can confirm that the following commands fixes the problem so Ubound can start again: echo 'alias / -> /upper/,' >> /etc/apparmor.d/tunables/alias apparmor_parser -r -T -W /etc/apparmor.d/usr.sbin.unbound I noticed that when it starts, another AppArmor-related error message is logged: [ 257.707923] audit: type=1107 audit(1567174888.349:247): pid=976 uid=103 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/org/freedesktop/systemd1" interface="org.freedesktop.systemd1.Manager" member="GetDynamicUsers" mask="send" name="org.freedesktop.systemd1" pid=6735 label="/usr/sbin/unbound" peer_pid=1 peer_label="unconfined" exe="/usr/bin/dbus-daemon" sauid=103 hostname=? addr=? terminal=?' However, it does not appear to cause any problems as far as I could tell. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation in a live session To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] Re: AppArmor breaks the default Unbound installation in a live session
That does not work, same error message when attempting to restart unbound. The apparmor_parser command results in the following being logged to the system journal: aug. 28 16:08:02 ubuntu audit[6536]: AVC apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/unbound" pid=6536 comm="apparmor_parser" aug. 28 16:08:02 ubuntu kernel: audit: type=1400 audit(1567008482.755:240): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="/usr/sbin/unbound" pid=6536 comm="apparmor_parser" Also, the /etc/apparmor.d/force-complain/usr.sbin.unbound does not exist, so the rm -f command is a no-op. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation in a live session To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] Re: AppArmor breaks the default Unbound installation in a live session
Sure, I can test if you tell me how, ideally spoon-fed. Like I said, I have no experience with AppArmor so I don't know how to install alias rules. By the way, I finished the my blog post, of the six DNSSEC validators I tested it was only Unbound that didn't work in the live environment (but of course it might be that none of the others are using AppArmor): https://www.redpill-linpro.com/techblog/2019/08/27/evaluating-local- dnssec-validators.html Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation in a live session To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] Re: AppArmor breaks the default Unbound installation
I don't know anything about AppArmor, so I am afraid I can't help you with that. I was just researching DNSSEC validators for a blog post I'm working on, testing them on both Fedora and Ubuntu (using a live VM). Since Unbound didn't seem to work (unless I did 'aa-complain /usr/sbin/unbound') I thought I'd submit a bug. I didn't realise the problem was caused by my use of the live media, as I was under the impression that the live media was expected to work the same as a regular installation. In any case, I'll be able to finish my blog post so it's not important for me that this issue is fixed. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] Re: AppArmor breaks the default Unbound installation
Correct, as mentioned under «Steps to reproduce» I did my testing using live media in a virtual machine. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841364] [NEW] AppArmor breaks the default Unbound installation
Public bug reported: Immediately after installing Unbound, it starts up normally. However, if you try to restart it afterwards (without changing anything), it fails with the following error message: Aug 25 10:41:26 ubuntu unbound[6650]: /etc/unbound/unbound.conf:10: error: cannot open include file '/etc/unbound/unbound.conf.d/*.conf': No such file or directory Aug 25 10:41:26 ubuntu unbound[6650]: read /etc/unbound/unbound.conf failed: 1 errors in configuration file Aug 25 10:41:26 ubuntu unbound[6650]: [1566729686] unbound[6650:0] fatal error: Could not read config file: /etc/unbound/unbound.conf. Maybe try unbound -dd, it stays on the commandline to see more errors, or unbound-checkconf There *are* files matching the above glob pattern, however: root@ubuntu:~# echo /etc/unbound/unbound.conf.d/*.conf /etc/unbound/unbound.conf.d/qname-minimisation.conf /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf unbound-checkconf, on the other hand, determines the configuration to be fine: root@ubuntu:~# unbound-checkconf unbound-checkconf: no errors in /etc/unbound/unbound.conf In the kernel log I can see that AppArmor is the probable culprit: Aug 25 10:41:26 ubuntu kernel: audit: type=1400 audit(1566729686.377:239): apparmor="DENIED" operation="open" profile="/usr/sbin/unbound" name="/upper/etc/unbound/unbound.conf.d/" pid=6650 comm="unbound" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Steps to reproduce: 1. Download ubuntu-19.04-desktop-amd64.iso from https://ubuntu.com/download/desktop 2. Boot the downloaded ISO file in a virtual machine 3. Start gnome-terminal 4. sudo -i 5. apt-add-repository universe 6. apt -y install unbound 7. systemctl status unbound # verify that it is runnning 8. systemctl restart unbound 9. systemctl status unbound # verify that it failed to start 10. journalctl -kn1 # display AppArmor error message ** Affects: unbound (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841364 Title: AppArmor breaks the default Unbound installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1841364/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1828345] Re: [4.4.0-144 regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207
We had another server running 4.4.0-148-generic crash just now. It has a different role then the firewalls that we originally saw the crash with. After an automatic reboot, it got back up with 4.4.0-150-generic (which had been installed at an earlier stage but not rebooted into), and crashed twice in rapid succession. I'm including the traces printed to the serial console below: Crash #1: [760425.631142] [ cut here ] [760425.68] kernel BUG at /build/linux-JhELCR/linux-4.4.0/net/core/skbuff.c:1207! [760425.698342] invalid opcode: [#1] SMP [760425.722139] Modules linked in: cpuid xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 bridge stp llc ebtable_filter ebtables hpwdt nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables xt_tcpudp xt_multiport xt_conntrack iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 ip_tables x_tables bonding intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul gpio_ich ghash_clmulni_intel aesni_intel ftdi_sio aes_x86_64 lrw cdc_ether gf128mul usbserial usbnet mii glue_helper input_leds hpilo joydev ablk_helper i7core_edac cryptd edac_core shpchp serio_raw 8250_fintek acpi_power_meter lpc_ich ipmi_ssif mac_hid ipmi_devintf ipmi_si ipmi_msghandler nf_nat_h323 nf_conntrack_h323 nf_nat_sip nf_conntrack_sip nf_nat nf_conntrack lp parport autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear ixgbe dca amdkfd amd_iommu_v2 radeon i2c_algo_bit hid_generic ttm drm_kms_helper syscopyarea sysfillrect vxlan ip6_udp_tunnel sysimgblt fb_sys_fops udp_tunnel usbhid uas ptp hpsa pps_core psmouse drm usb_storage hid bnx2 mdio scsi_transport_sas fjes [760426.325859] CPU: 9 PID: 0 Comm: swapper/9 Tainted: G I 4.4.0-148-generic #174-Ubuntu [760426.377154] Hardware name: HP ProLiant DL360 G7, BIOS P68 05/21/2018 [760426.413661] task: 880c0461d940 ti: 880c04634000 task.ti: 880c04634000 [760426.456870] RIP: 0010:[] [] pskb_expand_head+0x243/0x250 [760426.504553] RSP: 0018:880c1f903b80 EFLAGS: 00010202 [760426.535588] RAX: 0002 RBX: 880c0007ed00 RCX: 02080020 [760426.577271] RDX: 0140 RSI: RDI: 880c0007ed00 [760426.618845] RBP: 880c1f903bb8 R08: 0001 R09: 000a [760426.660361] R10: 880bffcf6a00 R11: R12: 880c0007ed00 [760426.702862] R13: 0001 R14: 0011 R15: 880c0007ed00 [760426.743881] FS: () GS:880c1f90() knlGS: [760426.789899] CS: 0010 DS: ES: CR0: 80050033 [760426.822597] CR2: 7ffccac51ff8 CR3: 01e0a000 CR4: 00020670 [760426.863053] Stack: [760426.874826] 81efb140 880c1f903db0 880c0007ed00 880c0007ed00 [760426.917091] 0001 0011 0001 880c1f903c00 [760426.960119] 81740e10 880c002d29c0 00010001 880c0007ed00 [760427.003239] Call Trace: [760427.017831] [760427.029143] [] __pskb_pull_tail+0x50/0x350 [760427.064432] [] _decode_session6+0x26a/0x400 [760427.097198] [] __xfrm_decode_session+0x39/0x50 [760427.132864] [] icmpv6_route_lookup+0xf0/0x1c0 [760427.168344] [] icmp6_send+0x5e1/0x940 [760427.198021] [] ? check_preempt_curr+0x54/0x90 [760427.232489] [] ? ttwu_do_activate.constprop.87+0x5d/0x70 [760427.272075] [] ? try_to_wake_up+0x49/0x400 [760427.304593] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [760427.345205] [] icmpv6_send+0x21/0x30 [760427.375673] [] ip6_expire_frag_queue+0xe0/0x120 [760427.411187] [] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6] [760427.452645] [] call_timer_fn+0x37/0x140 [760427.48] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [760427.532271] [] run_timer_softirq+0x234/0x330 [760427.570814] [] __do_softirq+0x109/0x2b0 [760427.608307] [] irq_exit+0xa5/0xb0 [760427.641799] [] smp_apic_timer_interrupt+0x50/0x70 [760427.682907] [] apic_timer_interrupt+0xcc/0xe0 [760427.721035] [760427.732319] [] ? cpuidle_enter_state+0x11b/0x2d0 [760427.777027] [] cpuidle_enter+0x17/0x20 [760427.812803] [] call_cpuidle+0x32/0x60 [760427.847096] [] ? cpuidle_select+0x19/0x20 [760427.883583] [] cpu_startup_entry+0x296/0x360 [760427.921417] [] start_secondary+0x177/0x1b0 [760427.958469] Code: 75 1a 41 8b 87 cc 00 00 00 49 03 87 d0 00 00 00 e9 e2 fe ff ff b8 f4 ff ff ff eb bc 4c 89 ef e8 84 9c ab ff b8 f4 ff ff ff eb ad <0f> 0b 90 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 [760428.073481] RIP [] pskb_expand_head+0x243/0x250 [760428.112534] RSP [760428.151392] ---[ end trace ae05fc32238b1676 ]--- [760428.182175] Kernel panic - not syncing: Fatal exception in interrupt [760428.224421] Kernel Offset: disabled [760428.248096] Rebooting in 120 seconds.. Crash #2:
[Bug 1828345] Re: [4.4.0-144 regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207
** Summary changed: - [possible regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207 + [4.4.0-144 regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1828345 Title: [4.4.0-144 regression] kernel BUG at [...]/linux-lts- xenial-4.4.0/net/core/skbuff.c:1207 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-xenial/+bug/1828345/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1828345] Re: [possible regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207
Hi Peter, and thanks for confirming the bug. We first experienced this issue in 4.4.0-144 so if you're saying 4.4.0-143 is stable that would mean the bug was introduced in 4.4.0-144. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1828345 Title: [possible regression] kernel BUG at [...]/linux-lts- xenial-4.4.0/net/core/skbuff.c:1207 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-xenial/+bug/1828345/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1828345] Re: [possible regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207
And a third crash, this time after upgrading to 4.4.0-146-generic. Uptime just 21h41m. Backtrace looks the same. I've now reverted back to 4.4.0-116-generic. I'll let you know if we experience similar crashes with this version. [78056.952451] [ cut here ] [78056.975336] kernel BUG at /build/linux-lts-xenial-Y8MnSS/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207! [78057.024383] invalid opcode: [#1] SMP [78057.046515] Modules linked in: ip6table_raw ip6table_mangle ip6t_REJECT nf_reject_ipv6 iptable_raw xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_mark iptable_mangle xt_comment ipt_REJECT nf_reject_ipv4 xt_NFLOG xt_limit xt_tcpudp xt_iprange ip_set_hash_net hpwdt nfnetlink_log ip6table_filter ip6_tables xt_set ip_set nfnetlink xt_multiport xt_conntrack iptable_filter ip_tables x_tables dm_crypt nf_conntrack_irc nf_conntrack_tftp nf_conntrack_ftp nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 intel_powerclamp nf_conntrack coretemp kvm_intel kvm ipmi_ssif ipmi_devintf irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 hpilo lrw gpio_ich gf128mul ipip glue_helper shpchp tunnel4 ipmi_si ip_tunnel ablk_helper serio_raw ipmi_msghandler cryptd i7core_edac 8250_fintek edac_core 8021q lpc_ich acpi_power_meter garp mrp stp llc mac_hid bonding raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear amdkfd amd_iommu_v2 radeon i2c_algo_bit ttm drm_kms_helper ixgbe syscopyarea dca sysfillrect sysimgblt vxlan fb_sys_fops ip6_udp_tunnel udp_tunnel ptp hpsa drm pps_core psmouse bnx2 mdio scsi_transport_sas fjes [78057.630237] CPU: 14 PID: 0 Comm: swapper/14 Not tainted 4.4.0-146-generic #172~14.04.1-Ubuntu [78057.676457] Hardware name: HP ProLiant DL360 G7, BIOS P68 07/02/2013 [78057.710242] task: 88011a90cc80 ti: 88011a928000 task.ti: 88011a928000 [78057.751071] RIP: 0010:[] [] pskb_expand_head+0x227/0x260 [78057.797573] RSP: 0018:88011bbc3b90 EFLAGS: 00010202 [78057.825843] RAX: 0002 RBX: 8800b8641000 RCX: 02080020 [78057.864650] RDX: 0140 RSI: RDI: 8800b8641000 [78057.902584] RBP: 88011bbc3bc8 R08: 0001 R09: 88011a5f6e80 [78057.940809] R10: R11: 0040 R12: [78057.979197] R13: 8800b8641000 R14: 0001 R15: 8800b2f5c6ce [78058.018261] FS: () GS:88011bbc() knlGS: [78058.061413] CS: 0010 DS: ES: CR0: 80050033 [78058.090850] CR2: 7f6086a9afb8 CR3: 01e0c000 CR4: 00020670 [78058.128810] Stack: [78058.140078] 88011bbc3de0 88011bbc3de0 8800b8641000 88011bbc3ca0 [78058.179734] 0001 0001 8800b2f5c6ce 88011bbc3c10 [78058.219346] 81713a70 880218455f28 00010005 8800b8641000 [78058.258709] Call Trace: [78058.272106] [78058.282744] [] __pskb_pull_tail+0x50/0x350 [78058.314577] [] _decode_session6+0x2e6/0x490 [78058.346575] [] __xfrm_decode_session+0x33/0x50 [78058.378788] [] icmpv6_route_lookup+0xf4/0x1d0 [78058.411200] [] icmp6_send+0x5f1/0x920 [78058.440073] [] ? kmem_cache_free+0x1dd/0x200 [78058.471604] [] ? destroy_conntrack+0xb0/0x100 [nf_conntrack] [78058.512149] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [78058.550814] [] icmpv6_send+0x21/0x30 [78058.578855] [] ip6_expire_frag_queue+0xe0/0x120 [78058.612372] [] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6] [78058.651923] [] call_timer_fn+0x37/0x140 [78058.681306] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [78058.724450] [] run_timer_softirq+0x213/0x320 [78058.761756] [] __do_softirq+0xe5/0x2b0 [78058.795657] [] irq_exit+0x96/0xa0 [78058.828108] [] smp_apic_timer_interrupt+0x50/0x70 [78058.867152] [] apic_timer_interrupt+0xcc/0xe0 [78058.903881] [78058.914272] [] ? poll_idle+0x40/0x80 [78058.952138] [] cpuidle_enter_state+0x9f/0x280 [78058.987977] [] cpuidle_enter+0x17/0x20 [78059.021555] [] call_cpuidle+0x32/0x60 [78059.056082] [] ? cpuidle_select+0x19/0x20 [78059.091593] [] cpu_startup_entry+0x290/0x350 [78059.128795] [] start_secondary+0x16c/0x190 [78059.164726] Code: ff ff ff 90 e9 54 ff ff ff 48 89 d7 48 89 55 c8 e8 bf b2 a8 ff 84 c0 48 8b 55 c8 75 97 eb 91 41 81 cf 00 20 00 00 e9 2a fe ff ff <0f> 0b 0f 0b 44 89 fe 4c 89 ef e8 7a ec ff ff 85 c0 74 12 48 89 [78059.277870] RIP [] pskb_expand_head+0x227/0x260 [78059.314117] RSP [78059.353516] ---[ end trace e2f55d38532b6f9c ]--- [78059.381878] Kernel panic - not syncing: Fatal exception in interrupt [78059.420570] Kernel Offset: disabled [78059.442784] ---[ end Kernel panic - not syncing: Fatal exception in interrupt [78059.483700] [ cut here ] [78059.512129] WARNING: CPU: 14 PID: 0 at /build/linux-lts-xenial-Y8MnSS/linux-lts-xenial-4.4.0/arch/x86/kernel/smp.c:125
[Bug 1828345] [NEW] [possible regression] kernel BUG at [...]/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207
Public bug reported: Following a kernel upgrade from linux-image-4.4.0-116-generic to linux- image-4.4.0-144-generic, our IPTables-based firewall have become unstable and have crashed twice with identical-looking backtraces after a short uptime. When running linux-image-4.4.0-116-generic the firewall had been up and running stable with an uptime of well over a year. Therefore, I highly suspect that this is a bug that has been introduced between the two versions mentioned. These are the backtraces printed to the serial console when it crashed. Crash #1 (after approx. 3 days of uptime): [258363.286572] [ cut here ] [258363.311248] kernel BUG at /build/linux-lts-xenial-YWfqtJ/linux-lts-xenial-4.4.0/net/core/skbuff.c:1207! [258363.362309] invalid opcode: [#1] SMP [258363.385411] Modules linked in: ip6table_raw ip6table_mangle ip6t_REJECT nf_reject_ipv6 iptable_raw xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_mark iptable_mangle xt_comment ipt_REJECT nf_reject_ipv4 xt_NFLOG xt_limit xt_tcpudp xt_iprange ip_set_hash_net hpwdt nfnetlink_log ip6table_filter ip6_tables xt_set ip_set nfnetlink xt_multiport xt_conntrack iptable_filter ip_tables x_tables dm_crypt intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul nf_conntrack_irc nf_conntrack_tftp nf_conntrack_ftp crc32_pclmul ghash_clmulni_intel hpilo aesni_intel aes_x86_64 nf_conntrack_ipv6 acpi_power_meter mac_hid lrw 8250_fintek nf_defrag_ipv6 shpchp gpio_ich gf128mul serio_raw nf_conntrack_ipv4 i7core_edac glue_helper nf_defrag_ipv4 edac_core nf_conntrack ablk_helper cryptd lpc_ich ipmi_ssif ipmi_devintf ipmi_si ipmi_msghandler ipip tunnel4 ip_tunnel 8021q garp mrp stp llc bonding raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear amdkfd amd_iommu_v2 radeon ixgbe i2c_algo_bit ttm dca drm_kms_helper vxlan syscopyarea ip6_udp_tunnel sysfillrect udp_tunnel sysimgblt ptp fb_sys_fops hpsa pps_core psmouse drm mdio bnx2 scsi_transport_sas fjes [258363.967279] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0-144-generic #170~14.04.1-Ubuntu [258364.011349] Hardware name: HP ProLiant DL360 G7, BIOS P68 07/02/2013 [258364.045068] task: 81e15500 ti: 81e0 task.ti: 81e0 [258364.085793] RIP: 0010:[] [] pskb_expand_head+0x227/0x260 [258364.132139] RSP: 0018:88011ba03b90 EFLAGS: 00010202 [258364.162253] RAX: 0002 RBX: 8800bff20e00 RCX: 02080020 [258364.201311] RDX: 0140 RSI: RDI: 8800bff20e00 [258364.240352] RBP: 88011ba03bc8 R08: 0001 R09: 8800d872 [258364.279499] R10: R11: 0040 R12: [258364.319220] R13: 8800bff20e00 R14: 0001 R15: 8800d327fdce [258364.358038] FS: () GS:88011ba0() knlGS: [258364.401198] CS: 0010 DS: ES: CR0: 80050033 [258364.432486] CR2: 7fcdc0672543 CR3: 01e0c000 CR4: 00020670 [258364.470918] Stack: [258364.481920] 88011ba03de0 88011ba03de0 8800bff20e00 88011ba03ca0 [258364.521426] 0001 0001 8800d327fdce 88011ba03c10 [258364.561323] 81713aa0 8802195c3b28 00010005 8800bff20e00 [258364.601724] Call Trace: [258364.615234] [258364.626239] [] __pskb_pull_tail+0x50/0x350 [258364.658220] [] _decode_session6+0x2e6/0x490 [258364.690802] [] __xfrm_decode_session+0x33/0x50 [258364.724086] [] icmpv6_route_lookup+0xf4/0x1d0 [258364.756501] [] icmp6_send+0x5f1/0x920 [258364.786304] [] ? handle_edge_irq+0xba/0x180 [258364.818506] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [258364.856875] [] icmpv6_send+0x21/0x30 [258364.884947] [] ip6_expire_frag_queue+0xe0/0x120 [258364.918555] [] nf_ct_frag6_expire+0x1f/0x30 [nf_defrag_ipv6] [258364.957884] [] call_timer_fn+0x37/0x140 [258364.988097] [] ? nf_ct_net_exit+0x50/0x50 [nf_defrag_ipv6] [258365.027226] [] run_timer_softirq+0x213/0x320 [258365.065587] [] __do_softirq+0xe5/0x2b0 [258365.100276] [] irq_exit+0x96/0xa0 [258365.132826] [] smp_apic_timer_interrupt+0x50/0x70 [258365.172450] [] apic_timer_interrupt+0xcc/0xe0 [258365.210589] [258365.221544] [] ? cpuidle_enter_state+0xc9/0x280 [258365.266485] [] ? cpuidle_enter_state+0xbb/0x280 [258365.305657] [] cpuidle_enter+0x17/0x20 [258365.339899] [] call_cpuidle+0x32/0x60 [258365.372832] [] ? cpuidle_select+0x19/0x20 [258365.407697] [] cpu_startup_entry+0x290/0x350 [258365.443997] [] rest_init+0x7c/0x80 [258365.476503] [] start_kernel+0x4a7/0x4b4 [258365.511376] [] ? set_init_arg+0x55/0x55 [258365.546509] [] ? early_idt_handler_array+0x120/0x120 [258365.585481] [] x86_64_start_reservations+0x2a/0x2c [258365.623803] [] x86_64_start_kernel+0x12d/0x13a [258365.660778] Code: ff ff ff 90 e9 54 ff ff ff 48 89 d7 48 89 55 c8 e8 0f b1 a8 ff 84 c0 48 8b 55 c8
[Bug 1707446] [NEW] snapper create-config fails due to /sbin/chsnap missing
Public bug reported: I think this says it all: root@backup:~# snapper create-config / Creating config failed (/sbin/chsnap not installed). root@backup:~# apt-file search chsnap root@backup:~# dpkg -L snapper | grep chsnap root@backup:~# dpkg -l snapper Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===-===- ii snapper 0.2.4-1ubuntu1 amd64 Linux filesystem snapshot management tool ** Affects: snapper (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1707446 Title: snapper create-config fails due to /sbin/chsnap missing To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapper/+bug/1707446/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
Hi Christian. Some comments/corrections: 1) On servers privacy extensions are *not* always enabled. As I pointed out in comment #24, if NM is not in use, privacy extensions are only enabled for userspace-created interfaces such as "vlan123". It is *not* enabled by default for physical interfaces such as "eth0". This is inconistent, but at least it's a good default for most people (i.e., those that are using "eth0"). 2) The old bugs #176125 and #841353 concern themselves with the potential leak of information of the user's MAC address. While this was a valid concern in the past, it no longer is. This is because (as I also pointed out in comment #24) NM will by default use RFC7217 interface identifiers. These do not contain the MAC address. Additionally, they will change when moving between networks, preventing tracking. 3) Finally, which has been pointed out by others earlier in the thread, even RFC4941 itself recommends that privacy extensions are disabled by default. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Still happens on a fully updated Trusty LTS. ** Changed in: mountall (Ubuntu) Status: Expired => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1573982] Re: LVM boot problem - volumes not activated after upgrade to Xenial
I ran across the same bug. It was caused by the root filesystem being specified on the kernel command line with the root=UUID= syntax. This is not handled by the case "$dev" in stanza in activate() in /usr/share/initramfs-tools/scripts/local-top/lvm2. See attached screenshot. If I change the kernel command line to say root=/dev/vg0/root instead it works. ** Attachment added: "Screenshot of initramfs lvm2 script failing on UUID root syntax" https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1573982/+attachment/4870302/+files/Screenshot.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1573982 Title: LVM boot problem - volumes not activated after upgrade to Xenial To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1573982/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Yes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
In case anyone's interested in knowing why setting net/ipv6/conf/all/use_tempaddr=2 no longer changes the value of pre- existing interfaces (thus ensuring privacy extensions are disabled by default for physical interfaces configured through /etc/network/interfaces), it's because http://kernel.ubuntu.com/git/ubuntu/ubuntu- trusty.git/commit/?id=c999e7dff4570e4c28a0953e7189c0c31343ce62 was dropped from the Ubuntu kernel packages starting with Utopic. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1497166] Re: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings
This issue seems to have been resolved in Xenial as a side-effect of changing to systemd, as systemd-sysctl.service runs before NetworkManager.service and networking.service. When those services configure a device-specific use_tempaddr sysctl, it will be left alone. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1497166/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
Correction to my previous comment: "disable_ipv6" should of course have read "use_tempaddr" throughout, except for the part about NM bouncing the disable_ipv6 sysctl. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1068756] Re: IPv6 Privacy Extensions enabled on Ubuntu Server by default
The situation appears to have improved somewhat in Xenial. The net/ipv6/conf/all/disable_ipv6 sysctl appears to have become a no-op in recent kernels, so when 10-ipv6-privacy.conf gets applied during the bootup sequence (by systemd-sysctl.service) it does *not* change the effective per-device setting for already existing devices (which defaults to 0). However, devices that show up later in the boot process, the 10-ipv6-privacy.conf-set value of net/ipv6/conf/default/disable_ipv6 is inherited, so privacy extensions remain enabled by default for userspace-created devices. Finally, NetworkManager will by default bounce the disable_ipv6 sysctl on devices it's bringing up. That seems to cause the device's use_tempaddr sysctl to be re-inherited from net/ipv6/conf/default/disable_ipv6, ensuring the setting from 10-ipv6-privacy.conf is applied. In summary, the following seems to be true in Xenial: - Physical kernel-plumbed interfaces (e.g., "eth0") managed through interfaces(5): Privacy extensions disabled by default. - Physical kernel-plumbed interfaces (e.g., "eth0") managed through NetworkManager(8): Privacy extensions enabled by default. - User-space created interfaces (e.g., "bond0" or "vlan123"), regardless of management method: Privacy extensions enabled by default. Another thing worth noting is that the version of NetworkManager shipped by Xenial uses RFC7217 Interface IDs by default. These are randomly generated and do not leak MAC addresses, yet they are stable on any given link/network. They will change when the link prefix changes, thus preventing tracking between networks. So where NetworkManager is used, there is IMHO very little rationale remaining for enabling RFC 4941 privacy extensions by default. https://blogs.gnome.org/lkundrak/2015/12/03/networkmanager-and-privacy- in-the-ipv6-internet/ -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1068756 Title: IPv6 Privacy Extensions enabled on Ubuntu Server by default To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1068756/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547206] Re: Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5
Steve, some suggestions for you to try:
1) Reinstate 95-multipath.rules to /{etc,lib}/udev/rules.d as described in
comment #1
2) Install the package «multipath-tools-boot»
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1547206
Title:
Boot stalls on mountall "disk drive not ready" question in multipath-
tools >= 0.4.9-3ubuntu7.5
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1547206/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Ok, so I found the bug. The problematic code is in
sysfs_attr_set_value() in libmultipath/sysfs.c:
devpath = udev_device_get_syspath(dev);
condlog(4, "open '%s'/'%s'", devpath, attr_name);
if (stat(devpath, ) != 0) {
condlog(4, "stat '%s' failed: %s", devpath, strerror(errno));
return 0;
}
/* skip directories */
if (S_ISDIR(statbuf.st_mode))
return 0;
The problem here is that stat() gets called on the containing directory
in devpath (as opposed to devpath+attr_name). Then the code proceeds to
check if that is a directory (which obviously it is going to be) and
before returning without having done anything. The rest of the function
also seems to assume that "devpath" contains the full path to the sysfs
attribute as opposed to the containing directory.
How the verification in comment #22 could have found this code to be
working is beyond me, as the only place where the attr_name variable is
actively being used for anything in the function is in the condlog()
call.
It appears this got fixed upstream by
http://git.opensvc.com/gitweb.cgi?p=multipath-
tools/.git;a=commit;h=050b24b33d3c60e29f7820d2fb75e84a9edde528 . This
patch applies fine to the multipath-tools 0.4.9-3ubuntu7.9 sources from
trusty (with --fuzz=3), and I can confirm that it does fix the problem
for me - the sysfs timeout attributes gets set correctly when the maps
is being created (both when using multipathd and the multipath tool).
Tore
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Ok, so I found the bug. The problematic code is in
sysfs_attr_set_value() in libmultipath/sysfs.c:
devpath = udev_device_get_syspath(dev);
condlog(4, "open '%s'/'%s'", devpath, attr_name);
if (stat(devpath, ) != 0) {
condlog(4, "stat '%s' failed: %s", devpath, strerror(errno));
return 0;
}
/* skip directories */
if (S_ISDIR(statbuf.st_mode))
return 0;
The problem here is that stat() gets called on the containing directory
in devpath (as opposed to devpath+attr_name). Then the code proceeds to
check if that is a directory (which obviously it is going to be) and
before returning without having done anything. The rest of the function
also seems to assume that "devpath" contains the full path to the sysfs
attribute as opposed to the containing directory.
How the verification in comment #22 could have found this code to be
working is beyond me, as the only place where the attr_name variable is
actively being used for anything in the function is in the condlog()
call.
It appears this got fixed upstream by
http://git.opensvc.com/gitweb.cgi?p=multipath-
tools/.git;a=commit;h=050b24b33d3c60e29f7820d2fb75e84a9edde528 . This
patch applies fine to the multipath-tools 0.4.9-3ubuntu7.9 sources from
trusty (with --fuzz=3), and I can confirm that it does fix the problem
for me - the sysfs timeout attributes gets set correctly when the maps
is being created (both when using multipathd and the multipath tool).
Tore
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Okay, sorry about the irrelevant verification on Vivid then. But I'd like to point out that Trusty behaves exactly the same, i.e., the bug is *not* fixed. Using the exact same multipath.conf as I mentioned in comment #31 with multipath-tools on 0.4.9-3ubuntu7.9, I get the exact same behaviour. That is, it is apparent that multipathd does read the settings from the config file (as they're visible in output from "multipathd -k'show config'"), but they're not being applied/written to sysfs. If I run use the command line utility in verbose mode to create the map, it does claim that it opens the sysfs files in question, but strace shows no sign of that actually happening: root@ucstest:~# /etc/init.d/multipath-tools stop * Stopping multipath daemon multipathd [ OK ] root@ucstest:~# multipath -F root@ucstest:~# strace -ff -eopen multipath -v4 |& egrep 'create:|_tmo' Mar 08 07:48:38 | 3600c0ff0001204a9d12b75510100: fast_io_fail_tmo = 16 (controller default) Mar 08 07:48:38 | 3600c0ff0001204a9d12b75510100: dev_loss_tmo = 2048 (controller default) Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-1/fc_remote_ports/rport-1:0-1'/'dev_loss_tmo' ort-1:0-1'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-2/fc_remote_ports/rport-1:0-2'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-2/fc_remote_ports/rport-1:0-2'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-1/fc_remote_ports/rport-2:0-1'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-1/fc_remote_ports/rport-2:0-1'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-2/fc_remote_ports/rport-2:0-2'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-2/fc_remote_ports/rport-2:0-2'/'fast_io_fail_tmo' create: 3600c0ff0001204a9d12b75510100 undef HP ,P2000G3 FC/iSCSI Note that this is a lab system, so if you'd like, you can have a look yourself, Mathieu. Just send me a SSH pubkey on IRC and I'll set up a user account for you. Tore -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1435706 Title: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Okay, sorry about the irrelevant verification on Vivid then. But I'd like to point out that Trusty behaves exactly the same, i.e., the bug is *not* fixed. Using the exact same multipath.conf as I mentioned in comment #31 with multipath-tools on 0.4.9-3ubuntu7.9, I get the exact same behaviour. That is, it is apparent that multipathd does read the settings from the config file (as they're visible in output from "multipathd -k'show config'"), but they're not being applied/written to sysfs. If I run use the command line utility in verbose mode to create the map, it does claim that it opens the sysfs files in question, but strace shows no sign of that actually happening: root@ucstest:~# /etc/init.d/multipath-tools stop * Stopping multipath daemon multipathd [ OK ] root@ucstest:~# multipath -F root@ucstest:~# strace -ff -eopen multipath -v4 |& egrep 'create:|_tmo' Mar 08 07:48:38 | 3600c0ff0001204a9d12b75510100: fast_io_fail_tmo = 16 (controller default) Mar 08 07:48:38 | 3600c0ff0001204a9d12b75510100: dev_loss_tmo = 2048 (controller default) Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-1/fc_remote_ports/rport-1:0-1'/'dev_loss_tmo' ort-1:0-1'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-2/fc_remote_ports/rport-1:0-2'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:01.0/:07:00.0/host1/rport-1:0-2/fc_remote_ports/rport-1:0-2'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-1/fc_remote_ports/rport-2:0-1'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-1/fc_remote_ports/rport-2:0-1'/'fast_io_fail_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-2/fc_remote_ports/rport-2:0-2'/'dev_loss_tmo' Mar 08 07:48:38 | open '/sys/devices/pci:00/:00:02.0/:02:00.0/:03:00.0/:04:00.0/:05:02.0/:08:00.0/host2/rport-2:0-2/fc_remote_ports/rport-2:0-2'/'fast_io_fail_tmo' create: 3600c0ff0001204a9d12b75510100 undef HP ,P2000G3 FC/iSCSI Note that this is a lab system, so if you'd like, you can have a look yourself, Mathieu. Just send me a SSH pubkey on IRC and I'll set up a user account for you. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1435706 Title: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
I tested it on Vivid, and it does not work. The dev_loss_tmo and
fast_io_fail_tmo sysfs settings do *not* get set. More information on my
test environment below:
root@ucstest:~# cat /etc/multipath.conf
defaults {
fast_io_fail_tmo 8
dev_loss_tmo 1024
}
devices
device {
vendor "HP.*"
product "P2000G3.*"
path_grouping_policy "multibus"
fast_io_fail_tmo 16
dev_loss_tmo 2048
}
}
root@ucstest:~# multipath -ll
3600c0ff0001204a9d12b75510100 dm-0 HP ,P2000G3 FC/iSCSI
size=30G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 1:0:0:1 sdb 8:16 active ready running
|- 1:0:1:1 sdc 8:32 active ready running
|- 2:0:0:1 sdd 8:48 active ready running
`- 2:0:1:1 sde 8:64 active ready running
I know for a fact that the device{} section is being applied, because if
I remove the path_grouping_policy keyword and restart multipathd, the
topology changes to one path per group:
root@ucstest:~# sed -i 's/path_grouping/#path_grouping/' /etc/multipath.conf
root@ucstest:~# systemctl restart multipath-tools.service
root@ucstest:~# multipath -ll
3600c0ff0001204a9d12b75510100 dm-0 HP ,P2000G3 FC/iSCSI
size=30G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| `- 1:0:0:1 sdb 8:16 active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 1:0:1:1 sdc 8:32 active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 2:0:0:1 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
`- 2:0:1:1 sde 8:64 active ready running
After reverting that change and restarting again, I can confirm that my
config file timeout settings are being read by multipathd:
root@ucstest:~# multipathd -k'show config' | grep -B5 -A1 dev_loss_tmo
defaults {
verbosity 2
wwids_file /etc/multipath/wwids
fast_io_fail_tmo 8
dev_loss_tmo 1024
}
--
device {
vendor "HP.*"
product "P2000G3.*"
path_grouping_policy multibus
fast_io_fail_tmo 16
dev_loss_tmo 2048
}
However, they are *not* being applied to sysfs:
root@ucstest:~# grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-2/fast_io_fail_tmo:off
Versions:
root@ucstest:~# dpkg -l kpartx multipath-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
ArchitectureDescription
+++-=-===-===-
ii kpartx
0.4.9-3ubuntu12.15.04.2 amd64 create device
mappings for partitions
ii multipath-tools
0.4.9-3ubuntu12.15.04.2 amd64 maintain
multipath block device access
Tore
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
I tested it on Vivid, and it does not work. The dev_loss_tmo and
fast_io_fail_tmo sysfs settings do *not* get set. More information on my
test environment below:
root@ucstest:~# cat /etc/multipath.conf
defaults {
fast_io_fail_tmo 8
dev_loss_tmo 1024
}
devices
device {
vendor "HP.*"
product "P2000G3.*"
path_grouping_policy "multibus"
fast_io_fail_tmo 16
dev_loss_tmo 2048
}
}
root@ucstest:~# multipath -ll
3600c0ff0001204a9d12b75510100 dm-0 HP ,P2000G3 FC/iSCSI
size=30G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
|- 1:0:0:1 sdb 8:16 active ready running
|- 1:0:1:1 sdc 8:32 active ready running
|- 2:0:0:1 sdd 8:48 active ready running
`- 2:0:1:1 sde 8:64 active ready running
I know for a fact that the device{} section is being applied, because if
I remove the path_grouping_policy keyword and restart multipathd, the
topology changes to one path per group:
root@ucstest:~# sed -i 's/path_grouping/#path_grouping/' /etc/multipath.conf
root@ucstest:~# systemctl restart multipath-tools.service
root@ucstest:~# multipath -ll
3600c0ff0001204a9d12b75510100 dm-0 HP ,P2000G3 FC/iSCSI
size=30G features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| `- 1:0:0:1 sdb 8:16 active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 1:0:1:1 sdc 8:32 active ready running
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 2:0:0:1 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=1 status=enabled
`- 2:0:1:1 sde 8:64 active ready running
After reverting that change and restarting again, I can confirm that my
config file timeout settings are being read by multipathd:
root@ucstest:~# multipathd -k'show config' | grep -B5 -A1 dev_loss_tmo
defaults {
verbosity 2
wwids_file /etc/multipath/wwids
fast_io_fail_tmo 8
dev_loss_tmo 1024
}
--
device {
vendor "HP.*"
product "P2000G3.*"
path_grouping_policy multibus
fast_io_fail_tmo 16
dev_loss_tmo 2048
}
However, they are *not* being applied to sysfs:
root@ucstest:~# grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-2/fast_io_fail_tmo:off
Versions:
root@ucstest:~# dpkg -l kpartx multipath-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
ArchitectureDescription
+++-=-===-===-
ii kpartx
0.4.9-3ubuntu12.15.04.2 amd64 create device
mappings for partitions
ii multipath-tools
0.4.9-3ubuntu12.15.04.2 amd64 maintain
multipath block device access
Tore
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1548306] [NEW] Attempts to load non-existent module dm-emc
Public bug reported:
The scripts in the multipath-tools-boot referer to a non-existent module
"dm-emc":
/usr/share/initramfs-tools/hooks/multipath:
for x in dm-multipath dm-round-robin dm-emc; do
manual_add_modules ${x}
done
/usr/share/initramfs-tools/scripts/local-top/multipath:
MP_MODULES="dm-multipath dm-emc"
[...]
for module in ${MP_MODULES}; do
if modprobe --syslog "$module"; then
verbose && log_success_msg "loaded module ${module}."
else
log_failure_msg "failed to load module ${module}."
fi
done
The latter code block causes a harmless error message to appear on each
boot.
I believe the references to "dm-emc" can be simply removed.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1548306
Title:
Attempts to load non-existent module dm-emc
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1548306/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1548306] [NEW] Attempts to load non-existent module dm-emc
Public bug reported:
The scripts in the multipath-tools-boot referer to a non-existent module
"dm-emc":
/usr/share/initramfs-tools/hooks/multipath:
for x in dm-multipath dm-round-robin dm-emc; do
manual_add_modules ${x}
done
/usr/share/initramfs-tools/scripts/local-top/multipath:
MP_MODULES="dm-multipath dm-emc"
[...]
for module in ${MP_MODULES}; do
if modprobe --syslog "$module"; then
verbose && log_success_msg "loaded module ${module}."
else
log_failure_msg "failed to load module ${module}."
fi
done
The latter code block causes a harmless error message to appear on each
boot.
I believe the references to "dm-emc" can be simply removed.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1548306
Title:
Attempts to load non-existent module dm-emc
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1548306/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1548303] [NEW] Stale references to /lib/udev/rules.d/95-multipath.rules linger
Public bug reported:
/lib/udev/rules.d/95-multipath.rules was removed in multipath-tools
0.4.9-3ubuntu7.5.
While researching an unrelated issue, I noticed that /usr/share
/initramfs-tools/hooks/multipath still refer to this file:
add_udev_rules()
{
for rules in 95-multipath.rules; do
if [ -e /lib/udev/rules.d/$rules ]; then
cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
fi
done
}
This is dead code that it would probably be best to remove.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1548303
Title:
Stale references to /lib/udev/rules.d/95-multipath.rules linger
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1548303/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1548303] [NEW] Stale references to /lib/udev/rules.d/95-multipath.rules linger
Public bug reported:
/lib/udev/rules.d/95-multipath.rules was removed in multipath-tools
0.4.9-3ubuntu7.5.
While researching an unrelated issue, I noticed that /usr/share
/initramfs-tools/hooks/multipath still refer to this file:
add_udev_rules()
{
for rules in 95-multipath.rules; do
if [ -e /lib/udev/rules.d/$rules ]; then
cp -p /lib/udev/rules.d/$rules $DESTDIR/lib/udev/rules.d/
fi
done
}
This is dead code that it would probably be best to remove.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1548303
Title:
Stale references to /lib/udev/rules.d/95-multipath.rules linger
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1548303/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547206] Re: Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5
After reviewing the changes between -3ubuntu7.4 and -3ubuntu7.5, I have found that the problem is caused by the removal of the file /lib/udev/rules.d/95-multipath.rules. In -3ubuntu7.4, it contained the following: # # udev rules for multipathing. # The persistent symlinks are created with the kpartx rules # # socket for uevents RUN+="socket:/org/kernel/dm/multipath_event" # Coalesce multipath devices before multipathd is running (initramfs, early # boot) ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/$name" If this file is manually reinstated (either to /lib/udev/rules.d or /etc/udev/rules.d), boot is again successful (even with the latest -3ubuntu7.9 multipath-tools package). I see from the changelog that the removal was intentional: * debian/rules: don't ship 95-multipath.rules udev rules anymore; they are not necessary with multipath-tools listening for udev events directly. * debian/multipath.udev: removed. However, in order for this to actually work with multipath-backed "auto" filesystems in /etc/fstab, it seems necessary to ensure that multipathd is started before mountall runs. I am not entirely certain how to accomplish this, though, as mountall is started from Upstart while multipath-tools is stuck using a legacy SysV-init, and I do not know if it is possible to enforce service ordering between the two init systems. For what it's worth, renaming /etc/rcS.d/S21-multipath-tools-boot as etc/rcS.d/S00-multipath-tools-boot does not work around the issue. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1547206 Title: Boot stalls on mountall "disk drive not ready" question in multipath- tools >= 0.4.9-3ubuntu7.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1547206/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1547206] Re: Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5
After reviewing the changes between -3ubuntu7.4 and -3ubuntu7.5, I have found that the problem is caused by the removal of the file /lib/udev/rules.d/95-multipath.rules. In -3ubuntu7.4, it contained the following: # # udev rules for multipathing. # The persistent symlinks are created with the kpartx rules # # socket for uevents RUN+="socket:/org/kernel/dm/multipath_event" # Coalesce multipath devices before multipathd is running (initramfs, early # boot) ACTION=="add|change", SUBSYSTEM=="block", RUN+="/sbin/multipath -v0 /dev/$name" If this file is manually reinstated (either to /lib/udev/rules.d or /etc/udev/rules.d), boot is again successful (even with the latest -3ubuntu7.9 multipath-tools package). I see from the changelog that the removal was intentional: * debian/rules: don't ship 95-multipath.rules udev rules anymore; they are not necessary with multipath-tools listening for udev events directly. * debian/multipath.udev: removed. However, in order for this to actually work with multipath-backed "auto" filesystems in /etc/fstab, it seems necessary to ensure that multipathd is started before mountall runs. I am not entirely certain how to accomplish this, though, as mountall is started from Upstart while multipath-tools is stuck using a legacy SysV-init, and I do not know if it is possible to enforce service ordering between the two init systems. For what it's worth, renaming /etc/rcS.d/S21-multipath-tools-boot as etc/rcS.d/S00-multipath-tools-boot does not work around the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547206 Title: Boot stalls on mountall "disk drive not ready" question in multipath- tools >= 0.4.9-3ubuntu7.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1547206/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547193] Re: Impossible to answer "disk drive not ready" question on serial console
Small correction to what I wrote above, what actually appears on the serial console is the following (note "keys:"): The disk drive for /opt/vnx is not ready yet or not present. keys:Continue to wait, or Press S to skip mounting or M for manual recovery -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547206] [NEW] Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5
Public bug reported: System information: Cisco UCS B200M2 blade, fnic.ko HBA. The system boots from local storage, but mounts the following file system on an EMC VNX during bootup: opt_vnx (3600601603a71320022967e0a1f38e411) dm-0 DGC,VRAID size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | |- 1:0:1:0 sdd 8:48 active ready running | `- 0:0:0:0 sda 8:0 active ready running `-+- policy='round-robin 0' prio=0 status=enabled |- 0:0:1:0 sdb 8:16 active ready running `- 1:0:0:0 sdc 8:32 active ready running /etc/fstab contains: /dev/mapper/opt_vnx /opt/vnx ext4 noatime 0 2 After upgrading the "multipath-tools" package to version 0.4.9-3ubuntu7.5 or higher, the system can no longer boot without manual intervention. Instead, the following question is asked (by mountall(8)) on the console: The disk drive for /opt/vnx is not ready yet or not present. keys:Continue to wait, or Press S to skip mounting or M for manual recovery Waiting does nothing useful. Pressing "S" allows the boot to run to completion, and the "opt_vnx" *is* present when logging in to a completely booted system. However, it seems that this is discovered *after* the mountall(8) question appears and is skipped, as this log line appears later on in the boot process: * Discovering and coalescing multipaths... [ OK ] Downgrading multipath-tools to version 0.4.9-3ubuntu7.4 does resolve the problem, and allows the system to boot normally without manual intervention. Note that the dependent "kpartx" package does *not* need to be downgraded also, if this is left on version 0.4.9-3ubuntu7.9 it will still boot fine. We experience this problem on serveral other systems apart from the one described in this bug report. ** Affects: multipath-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1547206 Title: Boot stalls on mountall "disk drive not ready" question in multipath- tools >= 0.4.9-3ubuntu7.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1547206/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1547206] [NEW] Boot stalls on mountall "disk drive not ready" question in multipath-tools >= 0.4.9-3ubuntu7.5
Public bug reported: System information: Cisco UCS B200M2 blade, fnic.ko HBA. The system boots from local storage, but mounts the following file system on an EMC VNX during bootup: opt_vnx (3600601603a71320022967e0a1f38e411) dm-0 DGC,VRAID size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw |-+- policy='round-robin 0' prio=1 status=active | |- 1:0:1:0 sdd 8:48 active ready running | `- 0:0:0:0 sda 8:0 active ready running `-+- policy='round-robin 0' prio=0 status=enabled |- 0:0:1:0 sdb 8:16 active ready running `- 1:0:0:0 sdc 8:32 active ready running /etc/fstab contains: /dev/mapper/opt_vnx /opt/vnx ext4 noatime 0 2 After upgrading the "multipath-tools" package to version 0.4.9-3ubuntu7.5 or higher, the system can no longer boot without manual intervention. Instead, the following question is asked (by mountall(8)) on the console: The disk drive for /opt/vnx is not ready yet or not present. keys:Continue to wait, or Press S to skip mounting or M for manual recovery Waiting does nothing useful. Pressing "S" allows the boot to run to completion, and the "opt_vnx" *is* present when logging in to a completely booted system. However, it seems that this is discovered *after* the mountall(8) question appears and is skipped, as this log line appears later on in the boot process: * Discovering and coalescing multipaths... [ OK ] Downgrading multipath-tools to version 0.4.9-3ubuntu7.4 does resolve the problem, and allows the system to boot normally without manual intervention. Note that the dependent "kpartx" package does *not* need to be downgraded also, if this is left on version 0.4.9-3ubuntu7.9 it will still boot fine. We experience this problem on serveral other systems apart from the one described in this bug report. ** Affects: multipath-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547206 Title: Boot stalls on mountall "disk drive not ready" question in multipath- tools >= 0.4.9-3ubuntu7.5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1547206/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1547193] [NEW] Impossible to answer "disk drive not ready" question on serial console
Public bug reported: When booting a server that is suffering from a (probably unrelated) bug in multipath-tools, I get the following questions posed on the serial console during bootup: The disk drive for /opt/vnx is not ready yet or not present. Continue to wait, or Press S to skip mounting or M for manual recovery Problem is, pressing "S" or "M" (even if followed by a newline) does absolutely nothing on the serial console. It does work on the KVM console, but that might not be available. You might very well need to send someone to a physical data centre somewhere in the middle of nowhere. (I ended up with powercycling the server, temporarily network booting it into a ramdisk, mounting the rootfs and commenting out the problematic entry from /etc/fstab, and rebooting again - which went fine, allowing me to later mount the missing filesystem manually via ssh.) I found no way to make the boot finish or break out to a debug shell, and it happens before sshd starts, so you're basically stuck with no apparent way to recover. For this reason I feel the bug is quite severe. For what it's worth I'm running 14.04.4 LTS, mountall package version is 2.53. The kernel command line is «BOOT_IMAGE=/@/boot/vmlinuz-3.13.0-77-generic root=UUID=2a141a43-97b0-4084-8816-ed1c41ac43e0 ro rootflags=subvol=@ console=tty1 console=ttyS0,115200n8». Tore ** Affects: mountall (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1547193 Title: Impossible to answer "disk drive not ready" question on serial console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1547193/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1512971] [NEW] /var/log/dibbler/*log not rotated
Public bug reported:
The dibbler-{client,relay,server} packages do not include any
/etc/logrotate.d configuration snippets. They should, otherwise the file
system on which /var/log/dibbler is located is bound to run out of free
space eventually.
** Affects: dibbler (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1512971
Title:
/var/log/dibbler/*log not rotated
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dibbler/+bug/1512971/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1497166] Re: 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings
I just realised that this bug also impacts NetworkManager, at least on Vivid: I set the property "ipv6.ip6-privacy" on the default wired Ethernet interface to 0 (in order to prevent a remote CIFS mount from freezing every few hours), however after a reboot, privacy extensions remained active. My assumption is that NetworkManager configured the interface correctly (without privacy extensions) early on during the boot process, only to have the procps' 10-ipv6-privacy.conf overwrite it moments later. Disabling 10-ipv6-privacy.conf solved this issue too. ** Summary changed: - 10-ipv6-privacy.conf stomps on user-configured "privext" option + 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings ** Also affects: ifupdown (Ubuntu) Importance: Undecided Status: New ** Also affects: network-manager (Ubuntu) Importance: Undecided Status: New ** Summary changed: - 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings + procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: procps' 10-ipv6-privacy.conf stomps on the ifup/NetworkManager "privext"/"ipv6.ip6-privacy" settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1497166/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1497166] [NEW] 10-ipv6-privacy.conf stomps on user-configured "privext" option
Public bug reported: I have configured the following in /etc/network/interfaces: auto eth0 iface eth0 inet6 auto privext 0 According to interfaces(5), this should disable IPv6 Privacy Extensions. However, after booting the machine, /proc/sys/net/ipv6/conf/eth0/use_tempaddr contains the value "2" - which means that Privacy Extensions are enabled. However running "ifdown eth0; ifup eth0" does fix the problem, so it is clear that ifup(8) does correctly set the use_tempaddr sysctl when bringing up the interface. What's going on is that sometime later in the bootup process, the procps package overrides the user-configured value and sets it unconditionally to "2" for every interface on the system. This happens because the file /etc/sysctl.d/10-ipv6-privacy.conf contains "net.ipv6.conf.all.use_tempaddr = 2". It should not, or this bug should be reassigned to the ifupdown package requesting for the removal of the defunct "privext" setting. On a related node, enabling IPv6 Privacy Extensions by default is counter to RFC 4941's recommendations. Quoting from section 3.6 Deployment Considerations: The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into a DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration of connections, MAY override this as appropriate. As such, the most appropriate course of action is probably to stop shipping the 10-ipv6-privacy.conf file by default. The described behaviour is observed on Trusty LTS. Tore ** Affects: procps (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1497166 Title: 10-ipv6-privacy.conf stomps on user-configured "privext" option To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1497166/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Ok, so I did some more testing. It appears that the problem isn't
specific to the dev_loss_tmo and fast_io_fail_tmo setting. This is
evidenced by the terminal log below. In multipath.conf (which we know
for certain is being read, as the created multipath map gets the correct
alias), I instruct it to use the ALUA hardware handler for all devices.
However, for some reason, this is ignored, and the EMC hardware handler
is used instead:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor .*
product .*
hardware_handler 1 alua
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
root@ucstest-osl2:~# multipath -v 2
create: bootvolume (3600601603a71320022967e0a1f38e411) undef DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=undef
|-+- policy='round-robin 0' prio=1 status=undef
| |- 0:0:0:0 sda 8:0 undef ready running
| `- 1:0:1:0 sdd 8:48 undef ready running
`-+- policy='round-robin 0' prio=0 status=undef
|- 0:0:1:0 sdb 8:16 undef ready running
`- 1:0:0:0 sdc 8:32 undef ready running
=
This does *NOT* happen on RHEL-based distros - on those, changing the
hardware_handler in multipath.conf in this way works as expected.
So why does it use the EMC hardware_handler? Well, there's a built-in
default device section that matches the array in question. So this
appears to override my user-specified config from multipath.conf:
=
root@ucstest-osl2:~# multipathd -k'show config' | grep -B10 -A4 '1 emc'
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1 queue_if_no_path
hardware_handler 1 emc
prio emc
failback immediate
no_path_retry 60
}
=
If I copy the entire default device config into /etc/multipath.conf and
only change the hardware_handler setting, then it starts working:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1 queue_if_no_path
hardware_handler 1 alua
prio emc
failback immediate
no_path_retry 60
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
root@ucstest-osl2:~# multipath -v 2
create: bootvolume (3600601603a71320022967e0a1f38e411) undef DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=undef
|-+- policy='round-robin 0' prio=1 status=undef
| |- 0:0:0:0 sda 8:0 undef ready running
| `- 1:0:1:0 sdd 8:48 undef ready running
`-+- policy='round-robin 0' prio=0 status=undef
|- 0:0:1:0 sdb 8:16 undef ready running
`- 1:0:0:0 sdc 8:32 undef ready running
=
It would appear that for some reason, in order to override default
device settings in Ubuntu there must be an *exact* string match between
the user-supplied «vendor» and «product» settings. If I change e.g.
«product» in multipath.conf to .*.*, then it starts using the built-in
defaults again, ignoring multipath.conf. I consider this behaviour very
dangerous - consider that if the admin has a working config (due to
exact matching vendor/product settings), and then the package gets
updated and extends the built-in defaults to incorporate some new model
matching the same profile/settings). At this point the admin's working
config will stop being used, possibly causing disruptive problems. I
therefore strongly suggest you figure out why it behaves differently in
Ubuntu and RHEL, and adopt the RHEL behaviour which really is the only
sensible one.
In any case, now that I know how to ensure my multipath.conf settings
are being used, I re-tried adding dev_loss_tmo and fast_io_fail_tmo, but
it still doesn't work:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
Ok, so I did some more testing. It appears that the problem isn't
specific to the dev_loss_tmo and fast_io_fail_tmo setting. This is
evidenced by the terminal log below. In multipath.conf (which we know
for certain is being read, as the created multipath map gets the correct
alias), I instruct it to use the ALUA hardware handler for all devices.
However, for some reason, this is ignored, and the EMC hardware handler
is used instead:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor .*
product .*
hardware_handler 1 alua
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
root@ucstest-osl2:~# multipath -v 2
create: bootvolume (3600601603a71320022967e0a1f38e411) undef DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=undef
|-+- policy='round-robin 0' prio=1 status=undef
| |- 0:0:0:0 sda 8:0 undef ready running
| `- 1:0:1:0 sdd 8:48 undef ready running
`-+- policy='round-robin 0' prio=0 status=undef
|- 0:0:1:0 sdb 8:16 undef ready running
`- 1:0:0:0 sdc 8:32 undef ready running
=
This does *NOT* happen on RHEL-based distros - on those, changing the
hardware_handler in multipath.conf in this way works as expected.
So why does it use the EMC hardware_handler? Well, there's a built-in
default device section that matches the array in question. So this
appears to override my user-specified config from multipath.conf:
=
root@ucstest-osl2:~# multipathd -k'show config' | grep -B10 -A4 '1 emc'
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1 queue_if_no_path
hardware_handler 1 emc
prio emc
failback immediate
no_path_retry 60
}
=
If I copy the entire default device config into /etc/multipath.conf and
only change the hardware_handler setting, then it starts working:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1 queue_if_no_path
hardware_handler 1 alua
prio emc
failback immediate
no_path_retry 60
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
root@ucstest-osl2:~# multipath -v 2
create: bootvolume (3600601603a71320022967e0a1f38e411) undef DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=undef
|-+- policy='round-robin 0' prio=1 status=undef
| |- 0:0:0:0 sda 8:0 undef ready running
| `- 1:0:1:0 sdd 8:48 undef ready running
`-+- policy='round-robin 0' prio=0 status=undef
|- 0:0:1:0 sdb 8:16 undef ready running
`- 1:0:0:0 sdc 8:32 undef ready running
=
It would appear that for some reason, in order to override default
device settings in Ubuntu there must be an *exact* string match between
the user-supplied «vendor» and «product» settings. If I change e.g.
«product» in multipath.conf to .*.*, then it starts using the built-in
defaults again, ignoring multipath.conf. I consider this behaviour very
dangerous - consider that if the admin has a working config (due to
exact matching vendor/product settings), and then the package gets
updated and extends the built-in defaults to incorporate some new model
matching the same profile/settings). At this point the admin's working
config will stop being used, possibly causing disruptive problems. I
therefore strongly suggest you figure out why it behaves differently in
Ubuntu and RHEL, and adopt the RHEL behaviour which really is the only
sensible one.
In any case, now that I know how to ensure my multipath.conf settings
are being used, I re-tried adding dev_loss_tmo and fast_io_fail_tmo, but
it still doesn't work:
=
root@ucstest-osl2:~# cat /etc/multipath.conf
devices {
device {
vendor DGC
product .*
product_blacklist LUNZ
path_grouping_policy group_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checker emc_clariion
checker emc_clariion
features 1
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
I verified that this bug is *NOT* fixed by trying the exact identical
configuration (which is as minimal as possible) both with Ubuntu Trusty
and with Scientific Linux 6 (RHEL6 clone). The test machine is a Cisco
B200M2 blade server, using the Cisco VIC FCoE HBA (fnic.ko driver). The
storage array is an EMC VNX5300, which is reached via FCoE (inside the
Cisco UCS infrastructure) and then traditional FC fabric.
The following console output is taken with Trusty installed. Note that
it was fully upgraded. After creating /etc/multipath.conf with the
indicated contents, update-initramfs was run and the system rebooted,
just to make sure the settings had taken effect. As you can see from the
output, the dev_loss_tmo and fast_io_fail_tmo settings are *NOT*
applied:
=-=-=-=-=-=-=-=
tore@ucstest-osl2:~$ cat /etc/multipath.conf
devices {
device {
vendor .*
product .*
fast_io_fail_tmo3
dev_loss_tmo2147483647
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
tore@ucstest-osl2:~$ sudo multipath -ll
bootvolume (3600601603a71320022967e0a1f38e411) dm-0 DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| |- 0:0:1:0 sdb 8:16 active ready running
| `- 1:0:1:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 1:0:0:0 sdc 8:32 active ready running
`- 0:0:0:0 sda 8:0 active ready running
tore@ucstest-osl2:~$ grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-0:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-0:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-0:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
tore@ucstest-osl2:~$ uname -r
3.13.0-62-generic
tore@ucstest-osl2:~$ md5sum /etc/multipath.conf
27a62898e80a0bcd7e62b5f2e8d675ff /etc/multipath.conf
tore@ucstest-osl2:~$ echo 3 | sudo tee
/sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo
3
tore@ucstest-osl2:~$ echo 2147483647 | sudo tee
/sys/class/fc_remote_ports/rport-*/dev_loss_tmo
2147483647
tore@ucstest-osl2:~$ grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-0:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-0:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-0:0-2/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-2/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:3
tore@ucstest-osl2:~$ dpkg -l multipath-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==---=
ii multipath-tools0.4.9-3ubuntu7.4 amd64
maintain multipath block
=-=-=-=-=-=-=-=
This shows the exact same multipath.conf file being used on SL6, and in
this case the sysfs settings *ARE* applied when the multipath map is
registered (no reboot required):
=-=-=-=-=-=-=-=
[root@ucstest-osl2 ~]# uname -r
2.6.32-358.23.2.el6.x86_64
[root@ucstest-osl2 ~]# rpm -qa device-mapper-multipath
device-mapper-multipath-0.4.9-80.el6.x86_64
[root@ucstest-osl2 ~]# grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
I verified that this bug is *NOT* fixed by trying the exact identical
configuration (which is as minimal as possible) both with Ubuntu Trusty
and with Scientific Linux 6 (RHEL6 clone). The test machine is a Cisco
B200M2 blade server, using the Cisco VIC FCoE HBA (fnic.ko driver). The
storage array is an EMC VNX5300, which is reached via FCoE (inside the
Cisco UCS infrastructure) and then traditional FC fabric.
The following console output is taken with Trusty installed. Note that
it was fully upgraded. After creating /etc/multipath.conf with the
indicated contents, update-initramfs was run and the system rebooted,
just to make sure the settings had taken effect. As you can see from the
output, the dev_loss_tmo and fast_io_fail_tmo settings are *NOT*
applied:
=-=-=-=-=-=-=-=
tore@ucstest-osl2:~$ cat /etc/multipath.conf
devices {
device {
vendor .*
product .*
fast_io_fail_tmo3
dev_loss_tmo2147483647
}
}
multipaths {
multipath {
wwid 3600601603a71320022967e0a1f38e411
alias bootvolume
}
}
tore@ucstest-osl2:~$ sudo multipath -ll
bootvolume (3600601603a71320022967e0a1f38e411) dm-0 DGC,VRAID
size=50G features='1 queue_if_no_path' hwhandler='1 emc' wp=rw
|-+- policy='round-robin 0' prio=1 status=active
| |- 0:0:1:0 sdb 8:16 active ready running
| `- 1:0:1:0 sdd 8:48 active ready running
`-+- policy='round-robin 0' prio=0 status=enabled
|- 1:0:0:0 sdc 8:32 active ready running
`- 0:0:0:0 sda 8:0 active ready running
tore@ucstest-osl2:~$ grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-0:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-0:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-0:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-0:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
tore@ucstest-osl2:~$ uname -r
3.13.0-62-generic
tore@ucstest-osl2:~$ md5sum /etc/multipath.conf
27a62898e80a0bcd7e62b5f2e8d675ff /etc/multipath.conf
tore@ucstest-osl2:~$ echo 3 | sudo tee
/sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo
3
tore@ucstest-osl2:~$ echo 2147483647 | sudo tee
/sys/class/fc_remote_ports/rport-*/dev_loss_tmo
2147483647
tore@ucstest-osl2:~$ grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-0:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-0:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-0:0-2/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-0:0-2/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:3
tore@ucstest-osl2:~$ dpkg -l multipath-tools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
Architecture Description
+++-==---=
ii multipath-tools0.4.9-3ubuntu7.4 amd64
maintain multipath block
=-=-=-=-=-=-=-=
This shows the exact same multipath.conf file being used on SL6, and in
this case the sysfs settings *ARE* applied when the multipath map is
registered (no reboot required):
=-=-=-=-=-=-=-=
[root@ucstest-osl2 ~]# uname -r
2.6.32-358.23.2.el6.x86_64
[root@ucstest-osl2 ~]# rpm -qa device-mapper-multipath
device-mapper-multipath-0.4.9-80.el6.x86_64
[root@ucstest-osl2 ~]# grep . /sys/class/fc_remote_ports/rport-*/*tmo
/sys/class/fc_remote_ports/rport-1:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-1:0-2/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-1:0-2/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
To me fix doesn't actually appear to work. After upgrading to multipath-
tools 0.4.9-3ubuntu7.4on an amd64 trusty and rebooting, the
fast_io_fail_tmo and dev_loss_tmo values do not get written to sysfs:
$ grep . /sys/class/fc_remote_ports/*/*_tmo
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-3:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-3:0-1/fast_io_fail_tmo:off
The device stanza from multipath.conf contains the following:
device {
vendor DGC|EMC
product RAID [0-9]*|VRAID|SYMMETRIX.*
path_grouping_policygroup_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checkeremc_clariion
features0
hardware_handler1 emc
prioemc
failbackimmediate
rr_weight uniform
no_path_retry queue
rr_min_io 100
fast_io_fail_tmo3
dev_loss_tmo2147483647
}
FWIW, I can manually set the sysfs settings to the desired values:
$ echo 3 | sudo tee /sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo
3
$ echo 2147483647 | sudo tee /sys/class/fc_remote_ports/rport-*/dev_loss_tmo
2147483647
$ grep . /sys/class/fc_remote_ports/*/*_tmo
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-3:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-3:0-1/fast_io_fail_tmo:3
Tore
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1435706] Re: DevLossTO, FastIoFailTO settings do not match multipath.conf expected values
To me fix doesn't actually appear to work. After upgrading to multipath-
tools 0.4.9-3ubuntu7.4on an amd64 trusty and rebooting, the
fast_io_fail_tmo and dev_loss_tmo values do not get written to sysfs:
$ grep . /sys/class/fc_remote_ports/*/*_tmo
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:off
/sys/class/fc_remote_ports/rport-3:0-1/dev_loss_tmo:30
/sys/class/fc_remote_ports/rport-3:0-1/fast_io_fail_tmo:off
The device stanza from multipath.conf contains the following:
device {
vendor DGC|EMC
product RAID [0-9]*|VRAID|SYMMETRIX.*
path_grouping_policygroup_by_prio
getuid_callout /lib/udev/scsi_id --whitelisted
--device=/dev/%n
path_selector round-robin 0
path_checkeremc_clariion
features0
hardware_handler1 emc
prioemc
failbackimmediate
rr_weight uniform
no_path_retry queue
rr_min_io 100
fast_io_fail_tmo3
dev_loss_tmo2147483647
}
FWIW, I can manually set the sysfs settings to the desired values:
$ echo 3 | sudo tee /sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo
3
$ echo 2147483647 | sudo tee /sys/class/fc_remote_ports/rport-*/dev_loss_tmo
2147483647
$ grep . /sys/class/fc_remote_ports/*/*_tmo
/sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-2:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-2:0-1/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:3
/sys/class/fc_remote_ports/rport-3:0-1/dev_loss_tmo:2147483647
/sys/class/fc_remote_ports/rport-3:0-1/fast_io_fail_tmo:3
Tore
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1435706
Title:
DevLossTO, FastIoFailTO settings do not match multipath.conf expected
values
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1435706/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1472129] [NEW] irqbalance triggers Upstart bug when started with --policyscript
Public bug reported: If irqbalance is started with the --policyscript option, Upstart is unable to manage it properly (bug #406397 is being triggered), and stopping/restarting it fails. Noticed this when the 1.0.6-2ubuntu0.14.04.2 update hit Trusty yesterday. See below: $ /sbin/stop irqbalance irqbalance stop/waiting $ echo 'OPTIONS=--policyscript=/bin/true' /etc/default/irqbalance $ /sbin/start irqbalance irqbalance start/running, process 23862 $ /sbin/status irqbalance irqbalance start/running, process 23862 $ pgrep -a irqbalance 23859 /usr/sbin/irqbalance --policyscript=/bin/true 23871 /usr/sbin/irqbalance --policyscript=/bin/true [note how the PIDs don't match what Upstart believes them to be] $ /sbin/stop irqbalance [hangs] ^C $ /sbin/status irqbalance irqbalance stop/killed, process 23862 $ pgrep -a irqbalance 23859 /usr/sbin/irqbalance --policyscript=/bin/true 23871 /usr/sbin/irqbalance --policyscript=/bin/true $ /sbin/start irqbalance [hangs] I successfully recovered from this situation by running the hack at https://raw.githubusercontent.com/ion1/workaround-upstart-snafu/master /workaround-upstart-snafu on all the servers that had attempted to upgraded the irqbalance package. One easy way to fix this issue is to remove expect fork and instead start irqbalance with the --foreground option. Patch attached. On a related note, I see that the irqbalance package ships both a SysV init script in /etc/init.d/irqbalance as well as an Upstart job definition. That's rather confusing to a sysadmin, and could possibly lead to collisions? As I understand it, the SysV init script for an Upstart-managed service is supposed be replaced by a symlink to /lib/init/upstart-job. Maybe you'll want to look into that as well. Tore ** Affects: irqbalance (Ubuntu) Importance: Undecided Status: New ** Patch added: Patch (apply to /etc/init/irqbalance.conf) https://bugs.launchpad.net/bugs/1472129/+attachment/4425604/+files/irqbalance.conf.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu. https://bugs.launchpad.net/bugs/1472129 Title: irqbalance triggers Upstart bug when started with --policyscript To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/1472129/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1472129] [NEW] irqbalance triggers Upstart bug when started with --policyscript
Public bug reported: If irqbalance is started with the --policyscript option, Upstart is unable to manage it properly (bug #406397 is being triggered), and stopping/restarting it fails. Noticed this when the 1.0.6-2ubuntu0.14.04.2 update hit Trusty yesterday. See below: $ /sbin/stop irqbalance irqbalance stop/waiting $ echo 'OPTIONS=--policyscript=/bin/true' /etc/default/irqbalance $ /sbin/start irqbalance irqbalance start/running, process 23862 $ /sbin/status irqbalance irqbalance start/running, process 23862 $ pgrep -a irqbalance 23859 /usr/sbin/irqbalance --policyscript=/bin/true 23871 /usr/sbin/irqbalance --policyscript=/bin/true [note how the PIDs don't match what Upstart believes them to be] $ /sbin/stop irqbalance [hangs] ^C $ /sbin/status irqbalance irqbalance stop/killed, process 23862 $ pgrep -a irqbalance 23859 /usr/sbin/irqbalance --policyscript=/bin/true 23871 /usr/sbin/irqbalance --policyscript=/bin/true $ /sbin/start irqbalance [hangs] I successfully recovered from this situation by running the hack at https://raw.githubusercontent.com/ion1/workaround-upstart-snafu/master /workaround-upstart-snafu on all the servers that had attempted to upgraded the irqbalance package. One easy way to fix this issue is to remove expect fork and instead start irqbalance with the --foreground option. Patch attached. On a related note, I see that the irqbalance package ships both a SysV init script in /etc/init.d/irqbalance as well as an Upstart job definition. That's rather confusing to a sysadmin, and could possibly lead to collisions? As I understand it, the SysV init script for an Upstart-managed service is supposed be replaced by a symlink to /lib/init/upstart-job. Maybe you'll want to look into that as well. Tore ** Affects: irqbalance (Ubuntu) Importance: Undecided Status: New ** Patch added: Patch (apply to /etc/init/irqbalance.conf) https://bugs.launchpad.net/bugs/1472129/+attachment/4425604/+files/irqbalance.conf.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1472129 Title: irqbalance triggers Upstart bug when started with --policyscript To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/irqbalance/+bug/1472129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 406397] Re: init: job stuck with expect fork/daemon when parent reaps child
** Also affects: irqbalance (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to irqbalance in Ubuntu. https://bugs.launchpad.net/bugs/406397 Title: init: job stuck with expect fork/daemon when parent reaps child To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/406397/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 406397] Re: init: job stuck with expect fork/daemon when parent reaps child
** Also affects: irqbalance (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/406397 Title: init: job stuck with expect fork/daemon when parent reaps child To manage notifications about this bug go to: https://bugs.launchpad.net/upstart/+bug/406397/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1381910] [NEW] Workaround for CVE-2014-3566 (POODLE) required
*** This bug is a security vulnerability *** Public security bug reported: In order to close the recently disclosed security vulnerability in SSLv3 (CVE-2014-3566 a.k.a. POODLE), one needs to disable SSLv3 support. According to http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs_SSL, lighttpd gained support for doing so (config option ssl.use-sslv3) in version 1.4.29. Because Ubuntu 12.04.5 LTS ships lighttpd 1.4.28, disabling SSLv3 seems impossible. Attempting to use the ssl.use-sslv3 setting results in the following error message being logged: (server.c.961) WARNING: unknown config-key: ssl.use-sslv3 (ignored) I suppose that the logical way to deal with this is to either backport the ssl.use-sslv3 functionality to the 1.4.28 version shipped by Ubuntu 12.04.5 LTS, or to upgrade the shipped package to 1.4.29 or newer. Tore ** Affects: lighttpd (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public Security -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1381910 Title: Workaround for CVE-2014-3566 (POODLE) required To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/1381910/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1322211] Re: linux-image-3.13.0-24-generic kernel doesn't boot on Xen 3.0 from CentOS5
FYI, this bug is now fixed by http://kernel.ubuntu.com/git?p=ubuntu /ubuntu-trusty.git;a=commit;h=6ac0d80c79b062b44135cec6436d6eeeaeed1ec2. I've tested linux-image-3.13.0-35-generic version 3.13.0-35.62~precise1 and can confirm it's working OK. So this bug report can probably be closed. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1322211 Title: linux-image-3.13.0-24-generic kernel doesn't boot on Xen 3.0 from CentOS5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322211/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1322211] Re: linux-image-3.13.0-24-generic kernel doesn't boot on Xen 3.0 from CentOS5
Hi, I'm also affected by this issue. I have a number of virtual machines running Precise which are now left in limbo - I cannot use the original Precise kernel (3.2.0) because of some missing features, and I cannot upgrade to the Trusty kernel (or upgrade the entire distribution to Trusty for that matter) due to this issue. I can run the Raring or Saucy kernels, but those are now End of Life, which means I won't get any security fixes. I have no influence over my VPS provider's choice of hypervisor software. It's been three months since this bug saw any activity, has it been forgotten about? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1322211 Title: linux-image-3.13.0-24-generic kernel doesn't boot on Xen 3.0 from CentOS5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322211/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1318317] Re: openipmi startup script removes kernel modules
This affects me, too. After boot, the necessary ipmi_{si,devintf}
modules aren't loaded, so ipmitool and related monitoring doesn't work.
However this bug cannot possibly be in the ejabberd package, so I'm
reassigning it to openipmi.
** Package changed: ejabberd (Ubuntu) = openipmi (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openipmi in Ubuntu.
https://bugs.launchpad.net/bugs/1318317
Title:
openipmi startup script removes kernel modules
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openipmi/+bug/1318317/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1318317] Re: openipmi startup script removes kernel modules
This affects me, too. After boot, the necessary ipmi_{si,devintf}
modules aren't loaded, so ipmitool and related monitoring doesn't work.
However this bug cannot possibly be in the ejabberd package, so I'm
reassigning it to openipmi.
** Package changed: ejabberd (Ubuntu) = openipmi (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1318317
Title:
openipmi startup script removes kernel modules
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openipmi/+bug/1318317/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 715141] Re: Default NTP servers do not have AAAA records
We notice this here as well, as we're increasingly turning up new services and VMs without IPv4. It fails with a rather cryptic error message: Jul 8 07:10:03 rpki-validator ntpdate[689]: Can't find host ntp.ubuntu.com: Name or service not known (-2) Jul 8 07:10:03 rpki-validator ntpdate[689]: no servers can be used, exiting Jul 8 07:10:03 rpki-validator ntpdate[726]: Can't find host ntp.ubuntu.com: Name or service not known (-2) Jul 8 07:10:03 rpki-validator ntpdate[726]: no servers can be used, exiting If the Ubuntu sysadmin team does not manage to dual-stack their public NTP service in three years, perhaps it is time for the ntpdate package to switch to 2.pool.ntp.org? Tore -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to ntp in Ubuntu. https://bugs.launchpad.net/bugs/715141 Title: Default NTP servers do not have records To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/715141/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 715141] Re: Default NTP servers do not have AAAA records
We notice this here as well, as we're increasingly turning up new services and VMs without IPv4. It fails with a rather cryptic error message: Jul 8 07:10:03 rpki-validator ntpdate[689]: Can't find host ntp.ubuntu.com: Name or service not known (-2) Jul 8 07:10:03 rpki-validator ntpdate[689]: no servers can be used, exiting Jul 8 07:10:03 rpki-validator ntpdate[726]: Can't find host ntp.ubuntu.com: Name or service not known (-2) Jul 8 07:10:03 rpki-validator ntpdate[726]: no servers can be used, exiting If the Ubuntu sysadmin team does not manage to dual-stack their public NTP service in three years, perhaps it is time for the ntpdate package to switch to 2.pool.ntp.org? Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/715141 Title: Default NTP servers do not have records To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/715141/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 702802] Re: event net-device-up is triggered too early
Indeed. This happens also with IPv6 interfaces, independently of any specific delay caused by the hardware, as the ifup scripts doesn't ensure that IPv6 Duplicate Address Detection has completed, nor that Stateless Address Auto-Configuration has. In the following case, /etc/network/interfaces contains the following: auto eth0 iface eth0 inet6 auto ..and I've also created /etc/init/network-test.conf containing the following: start on net-device-up IFACE=eth0 ADDRFAM=inet6 exec /sbin/ip a l dev eth0 | logger -t network-test Mar 24 13:53:48 ucstest kernel: [ 21.922952] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Mar 24 13:53:48 ucstest network-test: 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 Mar 24 13:53:48 ucstest network-test: link/ether 00:25:b5:00:00:ce brd ff:ff:ff:ff:ff:ff Mar 24 13:53:48 ucstest network-test: inet6 fe80::225:b5ff:fe00:ce/64 scope link tentative Mar 24 13:53:48 ucstest network-test:valid_lft forever preferred_lft forever Mar 24 13:53:48 ucstest ntpdate[1045]: name server cannot be used: Temporary failure in name resolution (-3) As you can see, this also broke /etc/network/if-up.d/ntpdate, which could not resolve the NTP server host-name (even if it could, it would have no chance of actually contacting any NTP server in any case). This makes it pretty hard (impossible?) to write an upstart script that will reliably not run until the network is ready, DNS lookups are possible, and so forth. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/702802 Title: event net-device-up is triggered too early To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/702802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 702802] Re: event net-device-up is triggered too early
Hi, I forgot to mention that the problems I reported in comment #5 was reproduced on Ubuntu 12.04.4. I'm glad to hear that it has been since fixed, but since 12.04.4 is supposed to be «Long Term Support», perhaps it would be an idea to backport the fix for IPv6 DAD? Thanks for considering. :-) Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/702802 Title: event net-device-up is triggered too early To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/702802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 702802] Re: event net-device-up is triggered too early
I don't think this is really fixed in recent versions either. At least I dist-upgraded my test server to Trusty now, but the script from comment #5 still shows that the interface only has a tentative LL address assigned by the time it is started by upstart: Mar 24 20:42:59 ucstest kernel: [ 23.150580] enic :08:00.0 eth0: Link UP Mar 24 20:43:00 ucstest network-test: 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc mq state UP group default qlen 1000 Mar 24 20:43:00 ucstest network-test: link/ether 00:25:b5:00:00:ce brd ff:ff:ff:ff:ff:ff Mar 24 20:43:00 ucstest network-test: inet6 fe80::225:b5ff:fe00:ce/64 scope link tentative Mar 24 20:43:00 ucstest network-test:valid_lft forever preferred_lft forever Mar 24 20:43:00 ucstest ntpdate[779]: Can't find host ntp.ubuntu.com: Name or service not known (-2) Mar 24 20:43:00 ucstest ntpdate[779]: no servers can be used, exiting Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/702802 Title: event net-device-up is triggered too early To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/702802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288196] [NEW] MAC address of bonding interface is randomly picked
Public bug reported: The new style of bonding configuration (using iface bond0 [...] \ bond_slaves none for the master interface plus iface ethX inet manual \ bond_master bond0 for each slave interface) results in the MAC address of the bond0 interface being randomly picked from one of the slaves. This causes problems for auto-configuration methods such as IPv4 DHCP and IPv6 SLAAC, as DHCPv4 leases and IPv6 Interface Identifiers are directly based on the interface's MAC address. This means that if the MAC address changes unexpectedly, so may the IP address(es) as well, which might be big problem if the machine in question is some sort of server or similar that have just rebooted. Unexpected MAC address changes may also cause problems for statically configured addresses, as the upstream router will likely have cached the IPv4 ARP and/or the IPv6 Neighbour entry pointing to the old MAC address. This results in the server not having any network connectivity until the upstream router have timed out its cache entry and probes anew. These timeouts may well be up to 20 minutes. The old configuration style (iface bond0 [...] \ bond_slaves eth0 eth1 [...]) did not have this problem, as the MAC address used for bond0 would always be the first listed interface (eth0). While I have no particular objection to the syntax change in itself, the choice of MAC address should be deterministic. It is probably possible to manually set the MAC address with the hwaddr option, but this is not ideal because it by necessity means every node must have a unique configuration file, which is problematic for large automated server deployments for example. Tore ** Affects: ifenslave-2.6 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288196 Title: MAC address of bonding interface is randomly picked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1288196/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288196] Re: MAC address of bonding interface is randomly picked
For what it's worth, we never had any problem with the old style bond_master eth0 eth1 syntax. On a server, typically all the slaves will become available pretty much at the same time during the boot process - devices hot-plugged at a later time is generally not the use case you'd need to optimise for. So waiting until the primary slave appears before setting up the bonding interface seems to me to be a perfectly adequate way to handle this . Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288196 Title: MAC address of bonding interface is randomly picked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1288196/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288196] Re: MAC address of bonding interface is randomly picked
Sorry, that should be bond_slaves eth0 eth1 of course. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288196 Title: MAC address of bonding interface is randomly picked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1288196/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1288196] Re: MAC address of bonding interface is randomly picked
Don't get me wrong, I meant to indicate that this seems completely fine by me; my point was simply that I was happy with waiting until the primary slave is available before with the old style of configuration, therefore I will be happy with waiting in a similar manner in the future too (even though the semantics change according to what you described). Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1288196 Title: MAC address of bonding interface is randomly picked To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1288196/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284535] [NEW] Make IPV6_[RECV]PKTINFO work for IPv4-mapped addresses
Public bug reported: Currently, the Linux kernel doesn't provide IPV6_RECVPKTINFO ancillary data on datagrams coming in from IPv4-mapped clients (e.g., :::192.0.2.1) on INET6 sockets in the default dual personality mode, nor does it honour IPV6_PKTINFO when sending datagrams on such a socket to an IPv4-mapped destination. This means that an UDP application that requires a server to respond with the same address as it was contacted on cannot reliably work for IPv4 clients, because 1) the server has no way of knowing which address it was contacted on, and even if it did, 2) the kernel would ignore requests to use a specific source address. For a real-life manifestation of this problem, see this OpenVPN bug report: https://community.openvpn.net/openvpn/ticket/306 This has recently been fixed in the net-next upstream tree with the following commits (the first one of which made the 3.14 merge window, the second one will be in 3.15): https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=4b261c75a99f29c93a0b6babfc180cdf566bd654 https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=c8e6ad0829a723a74cd2fea9996a3392d2579a18 Enabling IPv6 is getting increasingly important in these days, but at the same time maintaining backwards compatibility with IPv4-only clients is also essential. I'm therefore requesting a backport of the above two commits to the Ubuntu LTS kernel images so that it becomes possible to use OpenVPN (and any other software packages) in dual-stack mode. Tore ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284535 Title: Make IPV6_[RECV]PKTINFO work for IPv4-mapped addresses To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1284535] Re: Make IPV6_[RECV]PKTINFO work for IPv4-mapped addresses
This is really more a RFE/missing functionality than a bug per se, so confirming. ** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1284535 Title: Make IPV6_[RECV]PKTINFO work for IPv4-mapped addresses To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1284535/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099875] Re: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
** Attachment added: Output from: multipathd -kshow config https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+attachment/3487090/+files/multipathd_-kshow_config.txt -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1099875] Re: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
** Attachment added: Output from: multipath -v4 https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+attachment/3487091/+files/multipath_-v4.txt ** Changed in: multipath-tools (Ubuntu) Status: Incomplete = New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1099875] Re: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
** Attachment added: Output from: multipathd -kshow config https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+attachment/3487090/+files/multipathd_-kshow_config.txt -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099875] Re: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
** Attachment added: Output from: multipath -v4 https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+attachment/3487091/+files/multipath_-v4.txt ** Changed in: multipath-tools (Ubuntu) Status: Incomplete = New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099875] [NEW] multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
Public bug reported: My device section of /etc/multipath.conf contains the following (I'll attach the complete file in a bit): fast_io_fail_tmo 3 dev_loss_tmo 2147483647 This is also visible in the output from multipathd -kshow config, so it's being correctly parsed. However, the settings appears to be completely ignored by multipathd, as the corresponding sysfs settings doesn't get updated: $ grep . /sys/class/fc_remote_ports/rport-*/*tmo /sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30 /sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off /sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:30 /sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:off These are the kernel's defaults. I can easily set them manually: $ echo 3 | tee /sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo 3 $ echo 2147483647 | tee /sys/class/fc_remote_ports/rport-*/dev_loss_tmo 2147483647 $ grep . /sys/class/fc_remote_ports/rport-*/*tmo /sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:2147483647 /sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:3 /sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:2147483647 /sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:3 However, this won't survive a reboot, and since SAN paths may appear at any time, adding the above to /etc/rc.local is also not a good way to fix it. I've also attempted to move the settings to the defaults section and the individual path sections. No change in behaviour. This bug prevents dm-multipath from quickly moving I/O away from a recently failed SAN path, instead stalling all I/O for 30 seconds. This defeats the purpose of using multipathing in the first place, which is to have highly available I/O access so that production can continue uninterrupted even if parts of the SAN fabric fails. The setting works on RHEL6, btw. ** Affects: multipath-tools (Ubuntu) Importance: Undecided Status: New ** Attachment added: multipath.conf from impacted Precise server https://bugs.launchpad.net/bugs/1099875/+attachment/3484064/+files/multipath.conf -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1099875] [NEW] multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings
Public bug reported: My device section of /etc/multipath.conf contains the following (I'll attach the complete file in a bit): fast_io_fail_tmo 3 dev_loss_tmo 2147483647 This is also visible in the output from multipathd -kshow config, so it's being correctly parsed. However, the settings appears to be completely ignored by multipathd, as the corresponding sysfs settings doesn't get updated: $ grep . /sys/class/fc_remote_ports/rport-*/*tmo /sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:30 /sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:off /sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:30 /sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:off These are the kernel's defaults. I can easily set them manually: $ echo 3 | tee /sys/class/fc_remote_ports/rport-*/fast_io_fail_tmo 3 $ echo 2147483647 | tee /sys/class/fc_remote_ports/rport-*/dev_loss_tmo 2147483647 $ grep . /sys/class/fc_remote_ports/rport-*/*tmo /sys/class/fc_remote_ports/rport-2:0-0/dev_loss_tmo:2147483647 /sys/class/fc_remote_ports/rport-2:0-0/fast_io_fail_tmo:3 /sys/class/fc_remote_ports/rport-3:0-0/dev_loss_tmo:2147483647 /sys/class/fc_remote_ports/rport-3:0-0/fast_io_fail_tmo:3 However, this won't survive a reboot, and since SAN paths may appear at any time, adding the above to /etc/rc.local is also not a good way to fix it. I've also attempted to move the settings to the defaults section and the individual path sections. No change in behaviour. This bug prevents dm-multipath from quickly moving I/O away from a recently failed SAN path, instead stalling all I/O for 30 seconds. This defeats the purpose of using multipathing in the first place, which is to have highly available I/O access so that production can continue uninterrupted even if parts of the SAN fabric fails. The setting works on RHEL6, btw. ** Affects: multipath-tools (Ubuntu) Importance: Undecided Status: New ** Attachment added: multipath.conf from impacted Precise server https://bugs.launchpad.net/bugs/1099875/+attachment/3484064/+files/multipath.conf -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099875 Title: multipathd ignores dev_loss_tmo and fast_io_fail_tmo settings To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1099875/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210]
(In reply to comment #2) I'm suspending the bug. Change the state when any of the proposals are accepted. Hi Ulrich, RFC 6724 has just been published, obsoleting RFC 3484. It assigns global scope to RFC 1918 addresess. As requested, I'm therefore changing the state of the bug. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/555210 Title: Please assign global scope to RFC 1918 addresses in getaddrinfo() To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/555210/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 555210]
That's interesting. The reason why Fedora started carrying this patch in the first place, is because I submitted https://bugzilla.redhat.com/show_bug.cgi?id=577626. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/555210 Title: Please assign global scope to RFC 1918 addresses in getaddrinfo() To manage notifications about this bug go to: https://bugs.launchpad.net/glibc/+bug/555210/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1031772] [NEW] Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured
Public bug reported: The init script contains the following code: if [ x$CONFIGURE_IFACE = xyes ] ; then $DAEMON --mktun ip link set $TUN_DEVICE up ip route add $DYNAMIC_POOL dev nat64 ip route add $IPV6_PREFIX dev nat64 fi If the dynamic-pool setting isn't configured in /etc/tayga.conf, $DYNAMIC_POOL is empty. Similarly, if the prefix setting isn't, $IPV6_PREFIX is empty. (Both of these settings are optional.) This in turn means that one or both of the ip route add commands will evalue to ip route add dev nat64, which will add a link-local IPv4 default route pointing to the nat64 interface: root@tayga1-osl1:~# ip -4 r default dev nat64 scope link default via 87.238.62.26 dev eth0 metric 100 87.238.62.26/31 dev eth0 proto kernel scope link src 87.238.62.27 Since this new default route has a lower metric than the proper one added by ifupdown, IPv4 connectivity to the server is broken. The fix is obviously to check whether or not the variables are defined prior to adding the routes. Patch attached. Tore ** Affects: tayga (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1031772 Title: Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tayga/+bug/1031772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1031772] Re: Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured
** Patch added: tayga-init.patch https://bugs.launchpad.net/bugs/1031772/+attachment/3244761/+files/tayga-init.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1031772 Title: Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tayga/+bug/1031772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1031772] Re: Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured
Also, you might want to replace the static nat64 for $TUN_DEVICE. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1031772 Title: Init script adds spurious IPv4 default route if dynamic-pool or prefix isn't configured To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tayga/+bug/1031772/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
The second part is now committed, here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6b9511f6e98429c01b741754bc58795bf59f693e Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
FYI, The Fedora project has decided to consider IPv6-only network attachment failing out-of-the-box a release blocker for Fedora 17. And the required patches to fix that is hitting the NetworkManager upstream code as we speak. One significant commit is here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4abb300c967705b536cb11303f1c8296a6ca32f0 Dan Williams also just informed me that the patch in https://bugzilla.redhat.com/attachment.cgi?id=569078 will also be applied after having been adapted not to apply to WiMAX, mobile broadband, and Bluetooth DUN (because those connection types currently don't support IPv6 anyway). I'll post the commit ID as soon as I see it. That's is all the pieces missing for Ubuntu, as far as I can tell. I see from the 0.9.3.995+git201203081848.bba834f-0ubuntu1 upload that the network-manager package in Precise is far from frozen, so I'm still hoping that the upstream support for IPv6-only networks, as well as the Fedora project's decision, will persuade you to include the two patches (or simply update to a more recent git snapshot) before Precise goes out the door. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
Stéphane, the same patch was posted in this bug as well, see comment #316. (The one in #317 is no longer necessary, as it's been included in the NSPR upstream code for a long time now.) Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/417757 Title: [regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/417757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
Hi Mathieu, On dual-stack networks, which remains the norm rather than ipv6-only so far, The norm so far is without question IPv4-only, which outnumbers anything including IPv6 by an enormous amount. According to Google, IPv4-only is the case for about 99.5% of users world-wide (see http://www.google.com/intl/en/ipv6/statistics/), and my own data for Norway puts the number at about 99.75% (see http://fud.no/ipv6). having IPv4 optional will mean the connection may still be brought up with just IPv6. Of course. However, with IPv4 required in the exact same situation, the connection will not be brought up *at all*. That is certainly worse than having to make do with only IPv6. Using IPv6, you'll at least be able to go to Google and try to figure out how to troubleshoot the problem. That said, having just IPv6 on a network is also a completely valid configuration, and when combined with technologies such as NAT64, it does not mean that you lose access to all the IPv4-only content and services on the internet either. I would like to look into converting our corporate WLANs to such a configuration, actually; we are running low on IPv4 addresses, and the IPv4 addresses that are currently used on the WLAN would be much better spent in one of our data centres. However, since we have the Bring Your Own Device philosophy where people manage their own laptops (and Ubuntu is very popular OS choice), decommisioning IPv4 is out of the question until this actually works out of the box with IPv6 only for most people. Then people will wonder what is going on and file bugs here. Well, considering that http://bugs.launchpad.net is only available over IPv4, that is a technical impossibility. ;-) Seriously though, I believe that worry about misdirected bug reports is entirely unfounded. For the sake of the argument, the potential confused bug reporters need to match all of these criteria: 1) Have a dual-stacked networks - 0,5% of users world-wide [Google]. 2) Have a failure on their network that manifests itself in such a way that DHCPv4 doesn't work while SLAAC/DHCPv6 does to work. Let's say that is the case for 1% of networks. 3) Must mis-diagnose the problem and assign the blame to NetworkManager. Let's say 10% of users? 4) Must actually bother to submit a bug report. 25%? Result of the above: 0.000125% of all users...of course, that's very hypothetical, but I'm convinced that the real number is indeed a tiny fraction of a percent. Again it's worth noting that Microsoft Windows, Apple Mac OS X, and Apple iOS (which I forgot to mention in my previous message), *all* consider IPv4 optional. I believe it's relatively safe to assume that the Microsoft and Apple users are, on average, less technical than Ubuntu users, and would therefore be even more likely to misdiagnose the IPv6-is-working-while-IPv4-doesn't problem and wrongly assign the blame to the operating system. Yet, neither Microsoft nor Apple appear to have any second thoughts about their IPv4-is-optional default behaviour. The bottom line is: if Microsoft and Apple can make IPv4 optional, then Ubuntu should not be worried about doing so either. However, if I've failed to convince you yet that this simply isn't going to be a problem, and you are still worried about being flooded with misdirected bug reports as a result of making IPv4 optional, I am quite willing to join the Ubuntu Bug Squad in order to triage all such bugs filed on NetworkManager. That way you can be absolutely certain that you won't have to deal with any of those false bug reports you're worried about. BTW: I'm willing to bet that you've received way more messages from me in this very bug report than you'll ever get from these confused users... ;-) We'll revisit setting IPv4 to optional after the Precise release. I've seen you say pretty much exactly that before... :-( «We're already planning on changing these defaults for Oneiric. However, they won't be changed for Natty because it's already quite late in the cycle to do so» From https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/comments/2 Best regards, -- Tore Anderson -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
* Mathieu Trudel-Lapierre That's an option that can be changed by the user, so irrelevant to supporting IPv6 networks out of the box. «Plug and Play» is important for most users. I don't think there are enough IPv6-only networks to warrant shipping IPv4 as optional by default just yet, to me that's likely to cause far more pain for the time being. If there's no IPv6 on the network, as is the case for 99%+ of networks today, IPv4 *won't* be made optional by such a change. Either IPv4 or IPv6 must succeed even if neither is marked as required, and if there's no IPv6 on the network, the succeeding protocol pretty much has to be IPv4. Also, for what it's worth, Microsoft Windows (since Vista, 2006) and Apple Mac OS X (since Lion, 2011) supports IPv6-only networks in their default configuration. With that in mind, it is hard for me to understand what that «far more pain» concern you have is all about. Could you be more specific? Best regards, -- Tore Anderson -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 275111] Re: knetworkmanager fails to start OpenVPN tunnel
I am no longer using KDE, so I can't re-confirm, sorry. However, do feel free to close the ticket as out of date if you prefer. Tore -- You received this bug notification because you are a member of Kubuntu Bugs, which is subscribed to knetworkmanager in Ubuntu. https://bugs.launchpad.net/bugs/275111 Title: knetworkmanager fails to start OpenVPN tunnel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/knetworkmanager/+bug/275111/+subscriptions -- kubuntu-bugs mailing list kubuntu-b...@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs
[Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
Great! However, is IPv4 success still required in order to bring up interfaces? If so, that still needs to change before you can say that Ubuntu truly supports IPv6 networks out of the box. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 915272] [NEW] The rotate option in resolv.conf breaks IPv6 lookups for hostnames that have CNAMEs
Public bug reported: When /etc/resolv.conf contains options rotate, and I try to look up a hostname that first points to a CNAME, which then points to another hostname with both an A and an record, the record isn't returned. Instead I get an IPv4-mapped IPv6 address containing the A record. Note that my server does not have any IPv4 addresses assigned to it (except for 127.0.0.1/8 on the loopback interface). My resolv.conf contains the following: options rotate # Google Public DNS nameserver 2001:4860:4860:: nameserver 2001:4860:4860::8844 An example of the bug being reproduced: $ host no.archive.ubuntu.com no.archive.ubuntu.com is an alias for mirror.trivini.no. mirror.trivini.no has address 129.241.93.37 mirror.trivini.no has IPv6 address 2001:700:300:1800::b $ getent ahosts no.archive.ubuntu.com :::129.241.93.37 STREAM no.archive.ubuntu.com :::129.241.93.37 DGRAM :::129.241.93.37 RAW However, if there are no CNAMEs involved, it works as expected: $ getent ahosts mirror.trivini.no 2001:700:300:1800::b STREAM mirror.trivini.no 2001:700:300:1800::b DGRAM 2001:700:300:1800::b RAW Also, if the hostname pointed to by the CNAME does not have an A record, it also works as expected: $ host v6only-cname.fud.no v6only-cname.fud.no is an alias for v6only.fud.no. v6only.fud.no has IPv6 address 2001:db8::1 $ getent ahosts v6only-cname.fud.no 2001:db8::1 STREAM v6only-cname.fud.no 2001:db8::1 DGRAM 2001:db8::1 RAW If I remove or comment out options rotate from resolv.conf, it works as expected: $ getent ahosts no.archive.ubuntu.com 2001:700:300:1800::b STREAM trivini.no 2001:700:300:1800::b DGRAM 2001:700:300:1800::b RAW The server in question is running Ubuntu 12.04 Precise (developement branch), libc6 package version 2.13-24ubuntu2. Architecture is x86_64. I also tried to reproduce the bug on a Fedora 16 machine using glibc package version 2.14.90-14, but could not. I therefore assume that the bug is either caused by a Ubuntu-specific patch, or that it has been recently fixed upstream. I am able to provide SSH access to the server in question, if that is helpful (via an IPv4-to-IPv6 translator if necessary). Tore ** Affects: glibc (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/915272 Title: The rotate option in resolv.conf breaks IPv6 lookups for hostnames that have CNAMEs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/915272/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 590709] Re: Recovery menu doesn't show up on serial console
It is better on Oneiric beta 2, the menu shows up on the serial console, but the graphics are garbled so it's pretty much impossible to see what you're doing. I'll attach a screenshot. I used a KVM-based virtual machine in order to test - by default, /dev/ttyS0 on the VM will be redirected to a device in /dev/pts you can use minicom towards (at least when using virt-manager - check the libvirt logs to see which /dev/pts device was assigned). In order to activate the serial console, apply the following patch to the /etc/default/grub and run update-grub. The grub menu will then show up on the serial console on every subsequent boot. --- /etc/default/grub.dpkg-dist 2011-09-24 14:39:13.085554604 +0200 +++ /etc/default/grub 2011-09-24 15:01:40.204648670 +0200 @@ -4,12 +4,10 @@ # info -f grub -n 'Simple configuration' GRUB_DEFAULT=0 -GRUB_HIDDEN_TIMEOUT=0 -GRUB_HIDDEN_TIMEOUT_QUIET=true GRUB_TIMEOUT=10 GRUB_DISTRIBUTOR=`lsb_release -i -s 2 /dev/null || echo Debian` GRUB_CMDLINE_LINUX_DEFAULT=quiet splash -GRUB_CMDLINE_LINUX= +GRUB_CMDLINE_LINUX=console=ttyS0,115200n8 # Uncomment to enable BadRAM filtering, modify to suit your needs # This works with Linux (no patch required) and with any kernel that obtains @@ -17,7 +15,8 @@ #GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef # Uncomment to disable graphical terminal (grub-pc only) -#GRUB_TERMINAL=console +GRUB_TERMINAL=serial +GRUB_SERIAL_COMMAND=serial --unit=0 --speed=115200 --stop=1 # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE I also install the file /etc/init/ttyS0.conf containing the lines below, so that I can actually log in on the serial console after a normal boot. This is not necessary in order to reproduce the recovery menu issue, though. start on runlevel [23] stop on runlevel [!23] respawn exec /sbin/getty -L 115200 ttyS0 -- Tore Anderson ** Attachment added: console.png https://bugs.launchpad.net/bugs/590709/+attachment/2452526/+files/console.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/590709 Title: Recovery menu doesn't show up on serial console To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/friendly-recovery/+bug/590709/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 801610] Re: Include enic fnic drivers in ubuntu-installer
On Wed, 24 Aug 2011 13:45:04 -, Steve Conklin 801...@bugs.launchpad.net wrote: New installer images are available here: http://archive.ubuntu.com/ubuntu/dists/lucid-proposed/main/installer- amd64/current/images/ Back at work, with access to the UCS system in the lab for a few days more. Thought I'd test and looked for the installation ISO in the above location, but could not find anything. Could you give me a direct download link to new installation ISO (server flavour)? Best regards, -- Tore Anderson -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801610 Title: Include enic fnic drivers in ubuntu-installer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
I finally could verify/reproduce the issues you were seeing with connections initially never start DHCPv6 even if they are showing Auto for the method -- there is another part of network-manager which uses the assumption that a missing method (e.g. for a new device connection, which typically doesn't necessarily have an associated file on the filesystem) means Ignore, which is obviously false at this point. I think patch is what you need (maybe the last chunk only): http://mail.gnome.org/archives/networkmanager- list/2011-August/msg00063.html I also noted that there is such a check in nm-applet which would write Ignore and then include the assigned IPv6 addresses if the above is fixed, so now we have two separate tasks for network-manager and network-manager-applet. I'm working on both, and they should be fixed shortly. Ok, thanks! I haven't looked into the GUI stuff at all. As for your crash, please try to reproduce it with apport enabled. You should see a file in /var/crash about this crash; we'd need this opened as a separate bug in order to be able to debug what is causing it. This is just so we can track each issue separately and know what is fixed and what isn't. I'll do my best, but I can't promise you I find the time before next week, I'm going away from Friday, and I've got a really busy schedule today and tomorrow. Best regards, -- Tore Anderson -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801610] Re: Include enic fnic drivers in ubuntu-installer
I'm out of the office for a few days, and won't have access to the UCS equipment in the lab. I hope it'll still be available for my testing when I return - I'll let you know. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801610 Title: Include enic fnic drivers in ubuntu-installer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801610] Re: Include enic fnic drivers in ubuntu-installer
Steve, See comment #7. I need an updated installation ISO in order to confirm. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801610 Title: Include enic fnic drivers in ubuntu-installer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 801610] Re: Include enic fnic drivers in ubuntu-installer
Herton, The issue is that the *installer* (or perhaps more precisely, the .udeb) does not contain these modules. The regular kernel .deb had them included all along. I'd be happy to test that the issue is fixed, but in order to do so I need an install media (e.g. an ISO) that has been built using the new .udeb. It is not sufficient to enable -proposed on an already-installed system. Tore -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/801610 Title: Include enic fnic drivers in ubuntu-installer To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/801610/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
** Attachment added: Syslog, Oneiric alpha-3, singlestac IPv4, wired https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/+attachment/2258180/+files/test2.oneiric-a3.wired.singlestack.syslog -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
** Attachment added: Syslog, Oneiric alpha-3, dualstack, wireless https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/+attachment/2258181/+files/test3.oneiric-a3.wireless.dualstack.syslog -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 761558] Re: Default to enabling IPv6 addresses, but set to optional to bring up devices
Okay, now I've tested a bit with the Oneiric Alpha 3 live image. Highlights: - The default Wired connection profile now has set the IPv6 mode to Automatic by default. - ...however, it behaves as if it is still set to «Disable» and does no attempt of configuring IPv6. - DHCPv6 appears broken, any activation attempt fails with a dhcp-error - Also, dhclient6 appears to corrupt its own lease file. Test #1: Wired ethernet, dual-stack network --- * Connection profile «Wired connection 1» has by default IPv6 mode «Automatic». * However, DHCPv6 is not attempted. Behaves as if IPv6 mode is «Disabled». * «Require IPv4 for this connection to complete» is set. * IPv4 DHCP activation succeeds, as do the overall network connectivity. Test #2: Wired ethernet, single-stack IPv6 network -- * Like test #1 - IPv6 configuration not performed in spite of IPv6 mode being set to «Automatic». * See attachment test2.oneiric-a3.wired.singlestack.syslog * Since IPv4 is required and not present, the overall connection fails (as expected I guess). Test #3: Wireless ethernet, dual-stack network -- * Same default settings as for the Wired ethernet profiles * DHCPv6 is attempted, but fails with «DHCPv6 client didn't bind to a lease». * Connection attempts loops and fails for 13 iterations until it settles with only IPv4, no IPv6 configuration active. * See attachment test3.oneiric-a3.wireless.dualstack.syslog Test #4: Wireless ethernet, single-stack IPv6 network - * Same default settings as for the Wired ethernet profiles * DHCPv6 is attempted, but fails with «DHCPv6 client didn't bind to a lease», as in test #3. * Eventually corrupts the dhclient6-*.wlan0.lease file: Aug 6 13:01:01 ubuntu dhclient: /var/lib/dhcp/dhclient6-186b9d3d-e0d2-4fdc-a8a4-54798bef6345-wlan0.lease line 4: expecting hexadecimal number. Aug 6 13:01:01 ubuntu dhclient: ia-na jPb` * Connection attempts loops and fails for 4 iterations until it gives up completely, leaving the network disconnected. * See attachment test4.oneiric-a3.wireless.singlestack.syslog -- Tore Anderson -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/761558 Title: Default to enabling IPv6 addresses, but set to optional to bring up devices To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/761558/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
