Bug#884681: os-prober invoked during kernel upgrade disrupts KVM guest
Package: os-prober Version: 1.65+deb8u1 uname: Linux black 3.16.0-4-amd64 #1 SMP Debian 3.16.51-2 (2017-12-03) x86_64 GNU/Linux Short: os-prober invoked during kernel upgrade disrupts KVM guest It happened already twice but this is first time I was able to bind together 2 events from KVM host and KVM guests. During apt upgrade of kernel : # cat /var/log/apt/history.log ... Start-Date: 2017-12-18 08:59:24 Commandline: apt upgrade Upgrade: linux-image-3.16.0-4-amd64:amd64 (3.16.51-2, 3.16.51-3), rsync:amd64 (3.1.1-3, 3.1.1-3+deb8u1), linux-libc-dev:amd64 (3.16.51-2, 3.16.51-3) End-Date: 2017-12-18 09:01:07 my KVM guest logged (dmesg -T) [pon gru 18 09:00:57 2017] blk_update_request: I/O error, dev vda, sector 17723248 [pon gru 18 09:00:57 2017] EXT4-fs warning (device dm-0): ext4_end_bio:330: I/O error -5 writing to inode 2037 (offset 0 size 0 starting block 2089966) [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 2089966 [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 2089967 [pon gru 18 09:00:57 2017] blk_update_request: I/O error, dev vda, sector 13474112 [pon gru 18 09:00:57 2017] EXT4-fs warning (device dm-0): ext4_end_bio:330: I/O error -5 writing to inode 258195 (offset 0 size 0 starting block 1558824) [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 1558824 [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 1558825 [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 1558826 [pon gru 18 09:00:57 2017] Buffer I/O error on device dm-0, logical block 1558827 Guest file systems remounted RO so I do not have more logs - I got this from console My disk setup is (host)# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 931,5G 0 disk ├─sda1 8:10 487M 0 part ├─sda2 8:20 488M 0 part │ └─md0 9:00 487,7M 0 raid1 /boot └─sda3 8:30 930,6G 0 part └─md1 9:10 930,4G 0 raid1 ├─vgMain-root 253:00 5,6G 0 lvm / ├─vgMain-swap 253:10 3,7G 0 lvm [SWAP] ├─vgMain-usr 253:20 3,7G 0 lvm /usr ├─vgMain-var 253:30 7,5G 0 lvm /var ├─vgMain-home 253:40 7,5G 0 lvm /home ├─vgMain-tmp 253:50 3,7G 0 lvm /tmp ├─vgMain-ct01 253:6014G 0 lvm ├─vgMain-ct02--mail253:70 200G 0 lvm ├─vgMain-ct01--system 253:8014G 0 lvm └─vgMain-ct03--mailapi 253:9026G 0 lvm sdb 8:16 0 931,5G 0 disk ├─sdb1 8:17 0 487M 0 part /boot/efi ├─sdb2 8:18 0 488M 0 part │ └─md0 9:00 487,7M 0 raid1 /boot └─sdb3 8:19 0 930,6G 0 part └─md1 9:10 930,4G 0 raid1 ├─vgMain-root 253:00 5,6G 0 lvm / ├─vgMain-swap 253:10 3,7G 0 lvm [SWAP] ├─vgMain-usr 253:20 3,7G 0 lvm /usr ├─vgMain-var 253:30 7,5G 0 lvm /var ├─vgMain-home 253:40 7,5G 0 lvm /home ├─vgMain-tmp 253:50 3,7G 0 lvm /tmp ├─vgMain-ct01 253:6014G 0 lvm ├─vgMain-ct02--mail253:70 200G 0 lvm ├─vgMain-ct01--system 253:8014G 0 lvm └─vgMain-ct03--mailapi 253:9026G 0 lvm sr0 11:01 1024M 0 rom LVM logical volumes named vgMain-ct* are passed to KVM guests, ie.: (host)# dumpxml ct03-mailapi: ... /usr/bin/kvm (guest ct03-mailapi)# fdisk -l /dev/vda Disk /dev/vda: 26 GiB, 27917287424 bytes, 54525952 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x16892faa Device Boot Start End Sectors Size Id Type /dev/vda12048 54525951 54523904 26G 8e Linux LVM As I mentioned guest remounts RO, some programs from guest fail, etc.. After first such a situation one of my guest did not started properly and I had to force fsck and and reinstall grub on vda (host)# ls -l /dev/ |grep dm- brw-rw 1 root disk 253, 0 gru 14 07:12 dm-0 brw-rw 1 root disk 253, 1 gru 14 07:12 dm-1 brw-rw 1 root disk 253, 2 gru 14 07:12 dm-2 brw-rw 1 root disk 253, 3 gru 14 07:12 dm-3 brw-rw 1 root disk 253, 4 gru 14 07:12 dm-4 brw-rw 1 root disk 253, 5 gru 14 07:12 dm-5 brw-rw 1 libvirt-qemu libvirt-qemu 253, 6 gru 18 10:52 dm-6 brw-rw 1 libvirt-qemu libvirt-qemu 253, 7 gru 18 10:53 dm-7 brw-rw 1 libvirt-qemu l
Re: Changing di-netboot-assistants directory within the TFTP-root
Hello Andy, On Sun, Dec 17, 2017 at 05:22:57PM +0300, Andreas B. Mundt wrote: > Hi everybody, > > I plan to move di-netboot-assistant's directory within the TFTP-root. > > Right now, '$TFTP_ROOT/debian-installer/' is used to set up and serve > the netboot-images. If you also serve preseedings from the canonical just wondering if this is the default location or the only supported location for network installs. Please see also the email attached which seems not to have hit the list about grub not obeying an initial path send with dhcp. Thanks and sorry if I misunderstood something here, greetings Hermann > location '$TFTP_ROOT/d-i/', you have a slightly confusing setup. -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: hermann.la...@iwr.uni-heidelberg.de --- Begin Message --- Hi All, when doing network installation with the files from debian/dists/stretch/main/installer-amd64/current/images/netboot/netboot.tar.gz grub didn't find it's files if using a nonstandard tftp server layout: RRQ from 129.206.106.247 filename /debian/amd64_stretch/debian-installer/amd64/bootnetx64.efi tftp: client does not accept options RRQ from 129.206.106.247 filename /debian/amd64_stretch/debian-installer/amd64/bootnetx64.efi RRQ from 129.206.106.247 filename debian-installer/amd64/grub/x86_64-efi/command.lst RRQ from 129.206.106.247 filename debian-installer/amd64/grub/x86_64-efi/fs.lst RRQ from 129.206.106.247 filename debian-installer/amd64/grub/x86_64-efi/crypto.lst RRQ from 129.206.106.247 filename debian-installer/amd64/grub/x86_64-efi/terminal.lst RRQ from 129.206.106.247 filename debian-installer/amd64/grub/grub.cfg PXE BIOS with pxelinux has no problems with finding it's files in such a layout. Is there any functionality in grub to enable relative pathes at that point of the debian installation ? If not, is that a bug/regression to report against grub ? Thanks for any insights and sorry if I overlooked something, greetings Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: hermann.la...@iwr.uni-heidelberg.de --- End Message ---
Bug#875858: pkgsel: Offer to install/manage unattended-upgrades
Hi, On Sun, 17 Dec 2017, Moritz Mühlenhoff wrote: > unattended-upgrades are not an appropriate default. It's okay for a desktop > system which gets powered down daily, so you can add it to tasksel lists for > desktop roles, but not enable it by default for servers. I think it's not really useful for GNOME since it already has the required plumbing to install updates when you shut down. > - It does not handle restarts. If you upgrade OpenSSL (or any library) with > it, all your services will be left vulnerable until restarted. It will > give people a warm fuzzy feeling, but not any actual security benefit. Right, there are cases where a service restart is required. There are also many cases where it's not at all required because the library is only used by short-lived processes. And there are security updates of applications too. In all those cases, there are security benefits. > - We do need to make the occasional breaking change where people have to > modify configuration settings or perform additional manual steps. With > unattended-upgrades people don't have a chance to intervene. And if their > setups break, we're the ones who get blamed. If this is a real concern, we can maybe have some environment variable indicating that the upgrade is automatic without any human watching it and have the preinst fail? Or we could have a way to tag such breaking upgrades and teach unattended-upgrades to skip them? And the unattended upgrades would notify the admin about the need to manually upgrade? In any case, I'm not convinced that not installing updates and keeping a running vulnerable service is better than breaking the service and letting the admin fix it. If the admin is really concerned with the occasional breakage then he will use another process and deinstall unattended-upgrades. > Why was this change made without contacting t...@security.debian.org (as > the ones who are affected the most)? Because it was largely discussed on debian-devel already and I was not aware that the security team had any reservation about this. I would rather that we keep going and improve where needed instead of reverting the change. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Changing di-netboot-assistants directory within the TFTP-root
Hello Hermann, On Mon, Dec 18, 2017 at 12:03:02PM +0100, Hermann Lauer wrote: > On Sun, Dec 17, 2017 at 05:22:57PM +0300, Andreas B. Mundt wrote: > > Hi everybody, > > > > I plan to move di-netboot-assistant's directory within the TFTP-root. > > > > Right now, '$TFTP_ROOT/debian-installer/' is used to set up and serve > > the netboot-images. If you also serve preseedings from the canonical > > just wondering if this is the default location or the only supported > location for network installs. > Please see also the email attached which seems not to have hit the list > about grub not obeying an initial path send with dhcp. > > Thanks and sorry if I misunderstood something here, > greetings Do you use di-netboot-assistant [1] or just the debian-installer netboot packages/images [2]? […] > > when doing network installation with the files from > debian/dists/stretch/main/installer-amd64/current/images/netboot/netboot.tar.gz > grub didn't find it's files if using a nonstandard tftp server layout: > > RRQ from 129.206.106.247 filename > /debian/amd64_stretch/debian-installer/amd64/bootnetx64.efi > tftp: client does not accept options > RRQ from 129.206.106.247 filename > /debian/amd64_stretch/debian-installer/amd64/bootnetx64.efi > RRQ from 129.206.106.247 filename > debian-installer/amd64/grub/x86_64-efi/command.lst > RRQ from 129.206.106.247 filename > debian-installer/amd64/grub/x86_64-efi/fs.lst > RRQ from 129.206.106.247 filename > debian-installer/amd64/grub/x86_64-efi/crypto.lst > RRQ from 129.206.106.247 filename > debian-installer/amd64/grub/x86_64-efi/terminal.lst > RRQ from 129.206.106.247 filename debian-installer/amd64/grub/grub.cfg > > PXE BIOS with pxelinux has no problems with finding it's files in such a > layout. > Is there any functionality in grub to enable relative pathes at that point of > the debian > installation ? If not, is that a bug/regression to report against grub ? In di-netboot-assistant, a grub-EFI image is prepared which then includes the grub.conf files of the debian-installer images, with the correct paths. You get an idea in [3]. Perhaps you can follow this approach (or even better: use di-netboot-assistant) too. On the other hand, if you are already talking about a problem with di-netboot-assistant, we should open a bug against di-netboot-assistant and take a closer look at what went wrong. I only tested the grub-EFI stuff in di-netboot-assistant within a virtual machine setup, as I currently have no EFI system around. Best regards, Andi [1] https://wiki.debian.org/DebianInstaller/NetbootAssistant> [2] https://packages.debian.org/stretch/debian-installer-9-netboot-amd64> [3] https://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/di-netboot-assistant#n239>
Re: Description of timezones in translations
Hello, Holger Wansing: > msgid "Moscow+01 - Samara" > msgstr "Europe/Samara" Should we correct this to look like: > msgid "Moscow+00 - Moscow" > msgstr "Μόσχα+00 - Μόσχα" Best, Sotiri signature.asc Description: OpenPGP digital signature
Bug#883547: flash-kernel: please allow flavourless kernels
Control: tag 883547 +patch
On 2017-12-04, Adam Borowski wrote:
> If for whatever reason you want or need to build your own kernels, the
> preferred way these days is "make bindeb-pkg". It is also a good idea
> to use CONFIG_LOCALVERSION_AUTO=y, which marks the exact tree used to
> build the kernel.
>
> However, with this option, the version is _appended_ after local version,
> thus making it hard to add that "-armmp" string.
...
> Just allowing an empty string flavour doesn't work, as it'll still want a -
> after the version.
I think the following patch should work for this, by setting:
Kernel-Flavor: any
or even an empty value:
Kernel-Flavor:
(though, if that device has existing value in all.db, it will not be
overridden by the empty value).
The patch significantly refactors the use of the check_kflavor function,
and the one place it is called. Essentially, rather than trying to
derive the suffix from file, comparing that against a known list of good
suffixes, it merely checks if the targeted kernel version ends with one
of the good suffixes.
I haven't done extensive testing yet, but I could go ahead any push this
myself once I've done more tests, if nobody objects.
live well,
vagrant
diff --git a/functions b/functions
index b2ae5be..8dc542d 100644
--- a/functions
+++ b/functions
@@ -86,17 +86,17 @@ mtdsize() {
}
check_kflavors() {
- local kfile_suffix="$1"
- shift
-
- if [ -z "$kfile_suffix" ]; then
+ local kvers="$1"
+ local kflavor="$2"
+ if [ "$kflavor" = "any" ]; then
+ return 0
+ fi
+ # count flavor+ as valid
+ kvers=${kvers%%+}
+ if [ "${kvers}" != "${kvers%%$kflavor}" ]; then
+ # kernel version ended with flavor
return 0
fi
- for kflavor; do
- if [ "$kfile_suffix" = "$kflavor" ] || [ "$kfile_suffix" =
"$kflavor+" ]; then
- return 0
- fi
- done
return 1
}
@@ -764,18 +764,16 @@ if ! check_supported "$machine"; then
error "Unsupported platform."
fi
-if kflavors="$(get_machine_field "$machine" "Kernel-Flavors")"; then
- kfile_suffix=""
- while [ "$kfile_suffix" != "$kfile" ] ; do
- kfile_suffix=$(get_kfile_suffix "$kfile" "$kfile_suffix")
-
- if check_kflavors "$kfile_suffix" $kflavors; then
- break
- fi
- done
-fi
+kfile_suffix=""
+kflavors=$(get_machine_field "$machine" "Kernel-Flavors")
+for kflavor in ${kflavors:-"any"} ; do
+ if check_kflavors "$kvers" "$kflavor" ; then
+ kfile_suffix="$kflavor"
+ break
+ fi
+done
-if [ "$kfile_suffix" = "$kfile" ]; then
+if [ -z "$kfile_suffix" ]; then
echo "Kernel $kfile does not match any of the expected flavors
($kflavors), therefore not writing it to flash." >&2
exit 0
fi
diff --git a/test_functions b/test_functions
index e75b089..eeea52f 100755
--- a/test_functions
+++ b/test_functions
@@ -116,34 +116,26 @@ add_test test_mtdsize
test_check_kflavors() {
(
. "$functions"
-if check_kflavors "ksuffix" "kflavor1" "kflavor2"; then
+if check_kflavors "4.14.0-1-armmp" "armmp-lpae"; then
echo "Expected check_kflavors to fail with kernel suffix not in
expected flavors, but it succeeded" >&2
exit 1
fi
-if ! check_kflavors "foo" "kflavor1" "foo" "kflavor3"; then
+if ! check_kflavors "4.14.0-1-armmp-lpae" "armmp-lpae"; then
echo "Expected check_kflavors to succeed with kernel suffix in
expected flavors, but it failed" >&2
exit 1
fi
-if ! check_kflavors "kflavor1-suffix" "klavor1" "kflavor1-suffix"
"kflavor2"; then
-echo "Expected check_kflavours to succeed with double-barrelled
kernel suffix in expected flavours, but it failed" >&2
-exit 1
-fi
-if check_kflavors "kflavor1-suffix" "klavor1" "kflavor2"; then
-echo "Expected check_kflavours to fail with double-barrelled
kernel suffix not in expected flavours, but it succeeded" >&2
-exit 1
-fi
-if ! check_kflavors "" "kflavor1" "kflavor2" "kflavor3"; then
-echo "Expected check_kflavors to succeed with empty kernel suffix,
but it failed" >&2
-exit 1
-fi
-if check_kflavors "ksuffix+" "kflavor1" "kflavor2"; then
+if check_kflavors "4.14.0-1-armp-lpae+" "armmp"; then
echo "Expected check_kflavors to fail with kernel suffix (with
additional +) not in expected flavors, but it succeeded" >&2
exit 1
fi
-if ! check_kflavors "foo+" "kflavor1" "foo" "kflavor2"; then
+if ! check_kflavors "4.14.0-1-armmp-lpae+" "armmp-lpae"; then
echo "Expected check_kflavours to succeed with kernel suffix (with
additional +) in expected flavors, but it failed" >&2
exit 1
Processed: Re: Bug#883547: flash-kernel: please allow flavourless kernels
Processing control commands: > tag 883547 +patch Bug #883547 [flash-kernel] flash-kernel: please allow flavourless kernels Added tag(s) patch. -- 883547: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883547 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#884743: debian-installer: grub-install fail because "bios_grub" flag gets removed if i use RAID partition on GPT
Package: debian-installer Version: 20170615+deb9u2 Severity: normal Dear Maintainer, I have following configuration: Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors Disklabel type: gpt /dev/sda12048 20479 184329M BIOS boot /dev/sda2 20480 5839863807 5839843328 2.7T Linux RAID /dev/sda3 5839863808 5860532223 20668416 9.9G Linux swap Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors Disklabel type: gpt /dev/sdb1 2048 20479 184329M BIOS boot /dev/sdb2 20480 5839863807 5839843328 2.7T Linux RAID Disk /dev/md0: 2.7 TiB, 2989865566208 bytes, 5839581184 sectors In the part of installation grub-install i got error "This GPT partition label has no BIOS Boot Partition" I was fix that by switch to terminal and use this procedure: - bind /dev /proc and etc to /target - chroot /target - install parted - set 1 bios_grub on (by parted on both disks) - grub-install /dev/sda - grub-install /dev/sdb -- System Information: Debian Release: 9.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#883547: flash-kernel: please allow flavourless kernels
On Mon, Dec 18, 2017 at 03:08:08PM -0800, Vagrant Cascadian wrote: > I think the following patch should work for this, by setting: > > Kernel-Flavor: any > The patch significantly refactors the use of the check_kflavor function, > I haven't done extensive testing yet, but I could go ahead any push this > myself once I've done more tests, if nobody objects. Works for me on Odroid-U2 (armhf). I'll try on Pine64 once a kernel is built, in the morning (it takes two ages and three aeons). Meow! -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable And Non-Discriminatory prices.
Re: Description of timezones in translations
Quoting Sotirios Vrachas (sotir...@vrachas.com): > Hello, > > Holger Wansing: > > msgid "Moscow+01 - Samara" > > msgstr "Europe/Samara" > > Should we correct this to look like: > > > msgid "Moscow+00 - Moscow" > > msgstr "Μόσχα+00 - Μόσχα" Exactly, yes. signature.asc Description: PGP signature
Bug#884003: FDT overlay support
The patches need a bit more work. But before I do that, I'd like some feedback if this would be desirable/acceptable at all. Let me know what you think, Andre
[PATCH] pkgdetails: Strip the arch-qualifier (Closes: #836525)
On 2017-02-03 00:24:04 Sven Joachim applied b78e381e to
debootstrap/functions, to strip any ":arch"-qualifier from the package
name while running debootstrap.
The same must be done for the C-version in base-installer, which is
called by the Debian-Installer. Otherwise "python3" does not get pulled
in when you add "lsb-release" to --include=
---
pkgdetails.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/pkgdetails.c b/pkgdetails.c
index d588c80a..b240b36e 100644
--- a/pkgdetails.c
+++ b/pkgdetails.c
@@ -54,6 +54,7 @@ static void outputdeps(char *deps) {
if (!*pch) break;
while (*pch && *pch != '(' && *pch != '|' && *pch != ','
+ && *pch != ':'
&& !isspace(*pch))
{
fputc(*pch++, stdout);
--
2.11.0
