Bug#1001714: update 1
Hi Detlev, On Thu, Dec 16, 2021 at 09:05:07AM +0100, detlev schmidtke wrote: > I read in the Debian Wiki > (https://wiki.debian.org/UEFI#RAID_for_the_EFI_System_Partition): > > "But for software RAID systems there is currently no support for > putting the ESP on two separate disks in RAID." > > I interpret that as "it cannot work", so, the Debian Installer should > refuse to install EFI on a Software RAID with an appropriate message, > instead of running into this error. It's a bit more complicated than that. By default, md uses version 1.2 superblock which lives near the start of the device. Software with no concept of md RAID will read a member device and see an MD superblock at the start instead of the filesystem format they expect. So, this will not work and I would tend to agree that the installer should not allow a device with such a superblock to be used as an ESP. Metadata versions 0.9 and 1.0 can instead be used; these have the data near the end of the device. As a consequence, the beginning of RAID-1 member devices are indistinguishable from the below filesystem being directly on the device. This trick was used to get grub to boot RAID-1 before it had support for md RAID: grub couldn't tell that it wasn't just reading a normal filesystem. An MD RAID-1 array with superblock version 0.9 or 1.0 will very likely work as an ESP and many people do this. The installer should probably not prohibit it. This strategy can still fail. It relies upon nothing except the OS itself writing to that member device. I have not seen it but some people say that there are firmwares and bootloaders that will write to the ESP. Since they would not be aware of md, they would change one member device and not another. When you booted with such a setup MD would complain and not assemble the array. You'd have to choose which member device "won" and have the other overwrite it. Due to that, some people instead have multiple ESPs and come up with elaborate schemes to sync them in user space. That was the state of things when I last asked on debian-user in November 2020: https://lists.debian.org/debian-user/2020/11/msg00455.html Here's a script I use to sync ESPs: https://gist.github.com/grifferz/f262591f59e4f8c199a8b0619bc6a667 But again, I don't think it's a good idea to ban ESP on MD array as this is a working configuration for many. Cheers, Andy
Bug#784070: Newly-created arrays don't auto-assemble - related to hostname change?
Hi, On Wed, Nov 23, 2016 at 12:03:49PM +0300, Michael Tokarev wrote: > It was long ago when we disabled incremental assembly when > you turned it on by default, and kept old static way to > assemble arrays, because neither our initrd nor regular > userpsace weren't ready for that. Okay, so, on Debian jessie then, it is expected that md arrays on devices that are only present after the initramfs is done working will not be automatically (incrementally) started? I saw Yann mentioned that in stretch the GOTO="md_inc_end" has been removed again. Does that mean that incremental assembly on device change is expected to work again in stretch (I have not tested it, and most likely will not have time to do so with this hardware). Thanks, Andy
Bug#666565: /usr/lib/libreoffice/program/soffice: Menu items are not displayed with cairo 1.12
Package: libcairo2 Version: 1.12.0-2 Followup-For: Bug #666565 Same problem here (similar to Luca Tettamanti's screenshot) with several applications. I've noticed it in Epiphany, Nautilus and gnome-terminal. It's most severe using Gmail in Epiphany, I guess because that involves a lot of text redrawing. The problem occurs with libcairo2 1.12.0-2, but not after downgrading libcairo2, libcairo2-dev, libcairo-gobject2 and libcairo-script-interpreter2 to 1.10.2-7. Using xserver-xorg-video-radeon 1:6.14.3-2. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcairo2 depends on: ii libc6 2.13-27 ii libfontconfig1 2.8.0-3.1 ii libfreetype6 2.4.9-1 ii libpixman-1-0 0.24.4-1 ii libpng12-0 1.2.47-2 ii libx11-6 2:1.4.4-4 ii libxcb-render0 1.8.1-1 ii libxcb-shm01.8.1-1 ii libxcb11.8.1-1 ii libxrender11:0.9.6-2 ii multiarch-support 2.13-27 ii zlib1g 1:1.2.6.dfsg-2 libcairo2 recommends no packages. libcairo2 suggests no packages. -- no debconf information -- debsums errors found: debsums: package libcairo2 is not installed -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451297: linux-image-2.6.18-5-xen-686: kernel page allocation failure causes networking freeze
Package: linux-image-2.6.18-5-xen-686 Version: 2.6.18.dfsg.1-13etch4 Severity: grave Justification: renders package unusable Hi, In the past couple of months two of my Xen dom0 servers have, after about a week of uptime, been reporting kernel errors like so: Nov 14 18:57:58 corona kernel: swapper: page allocation failure. order:0, mode:0x20 Nov 14 18:57:58 corona kernel: [c0140735] __alloc_pages+0x261/0x275 Nov 14 18:57:58 corona kernel: [c01561c2] cache_alloc_refill+0x297/0x493 Nov 14 18:57:58 corona kernel: [c0104a51] hypervisor_callback+0x3d/0x48 Nov 14 18:57:58 corona kernel: [c020007b] handle_diacr+0x58/0xad Nov 14 18:57:58 corona kernel: [c0155f12] kmem_cache_alloc+0x3b/0x54 Nov 14 18:57:58 corona kernel: [c022e995] alloc_skb_from_cache+0x48/0x110 Nov 14 18:57:58 corona kernel: [c020d708] __alloc_skb+0x6c/0x70 Nov 14 18:57:58 corona kernel: [c0215d5b] netif_be_start_xmit+0x118/0x3d5 Nov 14 18:57:58 corona kernel: [c023269e] dev_hard_start_xmit+0x19a/0x1f0 Nov 14 18:57:58 corona kernel: [c0234020] dev_queue_xmit+0x247/0x2e3 Nov 14 18:57:58 corona kernel: [ee406dfe] br_dev_queue_push_xmit+0x155/0x178 [bridge] Nov 14 18:57:58 corona kernel: [ee406e64] br_forward_finish+0x43/0x45 [bridge] Nov 14 18:57:58 corona kernel: [ee40aae4] br_nf_forward_finish+0xc6/0xcc [bridge] Nov 14 18:57:58 corona kernel: [ee40b34a] br_nf_forward_arp+0x116/0x128 [bridge] Nov 14 18:57:58 corona kernel: [c0246e28] nf_iterate+0x30/0x61 Nov 14 18:57:58 corona kernel: [ee406e21] br_forward_finish+0x0/0x45 [bridge] Nov 14 18:57:58 corona kernel: [c0246f4e] nf_hook_slow+0x3a/0x90 Nov 14 18:57:58 corona kernel: [ee406e21] br_forward_finish+0x0/0x45 [bridge] Nov 14 18:57:58 corona kernel: [ee406eac] __br_forward+0x46/0x57 [bridge] Nov 14 18:57:58 corona kernel: [ee406e21] br_forward_finish+0x0/0x45 [bridge] Nov 14 18:57:58 corona kernel: [ee406c59] br_flood+0x65/0x9d [bridge] Nov 14 18:57:58 corona kernel: [ee406e66] __br_forward+0x0/0x57 [bridge] Nov 14 18:57:58 corona kernel: [ee406c9b] br_flood_forward+0xa/0xc [bridge] Nov 14 18:57:58 corona kernel: [ee406e66] __br_forward+0x0/0x57 [bridge] Nov 14 18:57:58 corona kernel: [ee407868] br_handle_frame_finish+0x80/0xcf [bridge] Nov 14 18:57:58 corona kernel: [ee407a16] br_handle_frame+0x15f/0x179 [bridge] Nov 14 18:57:58 corona kernel: [c0232231] netif_receive_skb+0x25e/0x357 Nov 14 18:57:58 corona kernel: [ee084130] e1000_clean_rx_irq_ps+0x4a6/0x569 [e1000] Nov 14 18:57:58 corona kernel: [ee082c4c] e1000_clean+0x69/0x136 [e1000] Nov 14 18:57:58 corona kernel: [c0233ce0] net_rx_action+0x96/0x18f Nov 14 18:57:58 corona kernel: [c011f41e] __do_softirq+0x5e/0xc3 Nov 14 18:57:58 corona kernel: [c011f4bd] do_softirq+0x3a/0x4a Nov 14 18:57:58 corona kernel: [c0106131] do_IRQ+0x48/0x53 Nov 14 18:57:58 corona kernel: [c020c1cc] evtchn_do_upcall+0x64/0x9b Nov 14 18:57:58 corona kernel: [c0104a51] hypervisor_callback+0x3d/0x48 Nov 14 18:57:58 corona kernel: [c0107342] raw_safe_halt+0x8c/0xaf Nov 14 18:57:58 corona kernel: [c0102c5f] xen_idle+0x22/0x2e Nov 14 18:57:58 corona kernel: [c0102d7e] cpu_idle+0x91/0xab Nov 14 18:57:58 corona kernel: [c03236fc] start_kernel+0x378/0x37f Nov 14 18:57:58 corona kernel: Mem-info: Nov 14 18:57:58 corona kernel: DMA per-cpu: Nov 14 18:57:58 corona kernel: cpu 0 hot: high 186, batch 31 used:30 Nov 14 18:57:58 corona kernel: cpu 0 cold: high 62, batch 15 used:55 Nov 14 18:57:58 corona kernel: DMA32 per-cpu: empty Nov 14 18:57:58 corona kernel: Normal per-cpu: empty Nov 14 18:57:58 corona kernel: HighMem per-cpu: Nov 14 18:57:58 corona kernel: cpu 0 hot: high 90, batch 15 used:75 Nov 14 18:57:58 corona kernel: cpu 0 cold: high 30, batch 7 used:6 Nov 14 18:57:58 corona kernel: Free pages: 34404kB (33228kB HighMem) Nov 14 18:57:58 corona kernel: Active:146620 inactive:39375 dirty:10 writeback:0 unstable:0 free:8601 slab:19722 mapped:2949 pagetables:254 Nov 14 18:57:58 corona kernel: DMA free:1176kB min:3452kB low:4312kB high:5176kB active:454452kB inactive:122052kB present:745464kB pages_scanned:0 all_unreclaimable? no Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 204 Nov 14 18:57:58 corona kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 204 Nov 14 18:57:58 corona kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 1632 Nov 14 18:57:58 corona kernel: HighMem free:33228kB min:204kB low:444kB high:684kB active:132028kB inactive:35448kB present:208904kB pages_scanned:0 all_unreclaimable? no Nov 14 18:57:58 corona kernel: lowmem_reserve[]: 0 0 0 0 Nov 14 18:57:58 corona kernel: DMA: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1176kB Nov 14 18:57:58 corona kernel: DMA32: empty Nov 14 18:57:58 corona kernel:
