Bug#986837: aoe: kernel crash on blk_update_request: I/O error, BUG: scheduling while atomic

[Raymond Burkholder]

On 5/17/21 10:17 AM, Valentin Kleibel wrote:

The bug has been reported upstream:
linux-kernel: https://lkml.org/lkml/2021/4/13/672
linux-block: 
https://lore.kernel.org/linux-block/b6aea08d-7190-e341-8780-13ba8e015...@vrvis.at/T/#u 


kernel.org bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212665


After waiting some weeks and in addition trying to reach out to 
supp...@coraid.com to find someone who might be willing to address this 
bug i unfortunately did not receive any response.


Probably won't.  I think coraid no longer exists as of about 3 or 4 
years ago.  [if this is about aoe style systems]



Do you have suggestions what i could do next? Unfortunately i do not 
think i have the skills to fix the bug myself.


Try something else?  :-(

Bug#982995: Installation Report

[Raymond Burkholder]

On 2/17/21 3:20 PM, Jeff Forsyth wrote:

Comments/Problems:

RPI4 with 4GiB Ram.  This system is netbooted using RPI-UEFI 1.22 and
iPXE 1.2.x.

DNSMASQ send the RPI-UEFI to the RPI.  The RPI-UEFI pulls the arm64
EFI/ipxe.  The iPXE

shows a menu for booting into the Debian Installer.  The Installer
loads and starts the

interactive menu installation system.  Everything seems good until
input is required.  The

keyboard is dead.


You are probably using a serial port to monitor progress?

If so, you need the following appended on the kernel line to redirect to 
the serial console:


kernel debian-installer/amd64/linux TERM=linux ..  yadda yadda ... 
console=ttyS0,115200n -- console=ttyS0,115200n8

Bug#960181: pigz: abort: write error on (No space left on device)

[Raymond Burkholder]

On 2020-05-10 4:59 a.m., Rainer Dorsch wrote:

It is weird that mkinitramfs reports no space left on device, but df does not confirm 
this. So it might be "another" device (like initramfs?). I am aware that I 
include a virtualbox module with dkms
df does, in a fashion confirm it.  It shows 91% in use for /boot. The 
issue is that you are probably attempting to another kernel version into 
/boot.  Try removing previous versions to free up space.


I had a similar problem where my initramfs became big due to too many 
firmware files being included, and therefore couldn't fit multiple 
initramfs variants in /boot.


Some background:
https://blog.raymond.burkholder.net/index.php?/archives/1008-pigz-abort-write-error-on-stdout-No-space-left-on-device.html





Calculating upgrade... Done
The following package was automatically installed and is no longer required:
   linux-image-4.19.0-6-amd64
Use 'apt autoremove' to remove it.
Setting up initramfs-tools (0.133+deb10u1) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-4.19.0-9-amd64
pigz: abort: write error on  (No space left on device)
E: mkinitramfs failure cpio 141 pigz 28
update-initramfs: failed for /boot/initrd.img-4.19.0-9-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
  installed initramfs-tools package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
  initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@h370:~# df
Filesystem1K-blocks  Used Available Use% Mounted on
udev   16364780 0  16364780   0% /dev
tmpfs   3278936  9768   3269168   1% /run
/dev/mapper/b370--vg-root 486574264 416572764  45215172  91% /
tmpfs  16394664 78848  16315816   1% /dev/shm
tmpfs  5120 4  5116   1% /run/lock
tmpfs  16394664 0  16394664   0% /sys/fs/cgroup
/dev/sda2241965206789 22684  91% /boot
/dev/sda1523248   140523108   1% /boot/efi
tmpfs   327893228   3278904   1% /run/user/2809
root@h370:~#

Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

[Raymond Burkholder]

On 2020-02-28 1:41 p.m., Jelle de Jong wrote:
So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.


Sometimes you  can't use partman-auto.  Sometimes you have to perform 
your own partition management.  This doesn't solve your problem, but 
does show how an example customized partitioning scheme might be 
configured.  This scheme does away with a swap partition. More ideas can 
be found at 
https://blog.raymond.burkholder.net/index.php?/archives/662-Using-Debian-PreSeed-files-and-a-PXEBoot-Server-to-Auto-Build-Hosts.html


There are many example schemes you can find with a search.

## **
# Partitioning scheme:
# Choices:
#partman-auto   partman-auto/choose_recipe  select
d-i partman-auto/choose_recipe  select  custom1

## **
# for internal use; can be preseeded
d-i partman-auto/expert_recipe  string  \
  custom1 ::  \
75 1000 100 ext4\
  $primary{ } $bootable{ }  \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /boot }   \
  . \
1000 4000 5000 ext4 \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ / }   \
  . \
5000 1 10 btrfs \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ btrfs } \
  mountpoint{ /var }\
  . \
4000 8000 1 ext4\
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /home }   \
  . \
1000 1000 4000 ext4 \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /tmp }\
  .





I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong

Bug#912596: cpufrequtils: cpufreq-info only shows 31 CPUs

[Raymond Burkholder]

I might be missing something, but ...

0 - 31 means a count of 32.  Or do you have more than 32?

On 2018-11-08 11:01 a.m., Witold Baryluk wrote:

Package: linux-image-4.18
Followup-For: Bug #912596


# cpupower -c all frequency-info
analyzing CPU 0:

<- cut ->

...
analyzing CPU 30:

<- cut ->

analyzing CPU 31:

<- cut ->

#

Same issue, last CPU has missing info.

Thanks.

Missing file in sys indicate it is an issue with kernel or my
motherboard / CPU.

Bug#892105: linux-image-4.9.0-6-amd64: i40e driver still unstable

[Raymond Burkholder]

> Our usual solution is to install a i40e driver from Intel (version
> 1.6.42 works nice for us). Please note that this is the only driver
taining our
> kernel - as a workaround.

I am in a similar circumstance.  After a few days of moderate operation, it
appears packets can be transmitted, but tcpdump does not see the ingress
packet.  The IRQs may have issues?

I did some troubleshooting with a network appliance vendor in whose devices
these cards are installed.

Their comments are to use a more current kernel, and to use Intel's drivers
from their e1000 sourceforge site.  The i40e driver in a more current kernel
may operate better.  Debian Stretch has 4.14 in stretch-backports.  

I see many many commits to the i40e module between the 4.9 and 4.14 kernel
versions.  Maybe the issue has been solved in a more recent kernel/module
incarnation.  And/Or use the intel (tainted) module/driver.  I am persuing
both:  install the stretch-backports kernel (which provides additional
iproute2 functions as a bonus), plus install the separate intel i40e driver.
I am testing my auto-build scripts to suit the new requirements.

What the real problem is with the driver, I do not know.  The above is my
version of a workaround.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#891979: linux-image-4.9.0-6-amd64: Cannot use Windows 2016 Hyper-V in a KVM guest

[Raymond Burkholder]

On 03/03/2018 10:59 AM, Antonio Huete Jimenez wrote:

Package: src:linux
Version: 4.9.82-1+deb9u3
Severity: normal
On the latest linux-image, as shown in the details of this bug report, and 
after enabling KVM nested it is possible to enable Hyper-V role in Windows 2016 
standard.
However the requirements are not met due to certain cpu features not being correctly propagated. 



This was reported more than one year ago upstream in Linux (see 
https://bugzilla.kernel.org/show_bug.cgi?id=106621) and the fixes are available 
from 4.10 onwards. As it \
happens, Debian Stretch is using 4.9 and after installing linux source with 
debian patches I can't see the changes required.


Maybe try stretch-backports which currently has kernel 4.14.13?

https://packages.debian.org/stretch-backports/linux-image-4.14.0-0.bpo.3-amd64

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

On 12/11/2017 11:51 AM, Steve McIntyre wrote:

On Mon, Dec 11, 2017 at 04:41:38PM +0100, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


That's the point here, yes. We've had this discussion already several
times, and it was triggered by needs/desires of cloud providers. As a
*default*, it makes sense to have automated security updates to cover
the users who don't care, or don't know any better. Users with more
knowledge and hard requirements about downtime etc. should already be
managing this.


I think I got thrown off by the title 'unattended upgrades'.  If this is 
limited to security updates, I am more for it, but still scared of it.


Security updates tend to come in packages which have already have had 
other regular patches applied (except, I suppose in 'stable' versions), 
and sometimes one can get caught in functional changes.


I guess that is my greatest fear,  breakages due to updates.

But my experience has mostly been with regular package updates.  I 
haven't focused much on security updates.  Can security updates be 
applied with out generating dependency chains and their updates?




--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

You can tell me if I am 'beating a dead horse' but for the sake of 
argument, let us see where this goes 


On 12/11/2017 11:41 AM, Wouter Verhelst wrote:

On Sun, Dec 10, 2017 at 12:22:07PM -0400, Raymond Burkholder wrote:


I think its totally adequate to assume people want automatic security
updates, on all kinds of systems, unless they opt out.


Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.


Are you advocating for having servers with known-security-buggy services
running all over the Internet, then?


hmm, almost like being asked to answer the question 'have you stopped 
beating your  yet?'.  One can't win by answering.


But things depend:

* servers can't can't be rebooted willy nilly

* when a package is updated with files open, the active process gets the 
existing files, and new processes get the new files, and is the patched 
package functional simultaneously in both activities (file formats, 
database schemas, )?


* does the patch introduce a functional change which may break 
operations (inverting logic on something, removing a flag, ... ) which 
breaks dependencies elsewhere





For my infrastructure, updates, of what ever kind, need to be
incorporated into the test/build/roll-out cycle.


If you have a test/build/roll-out cycle, then you presumably have a
local mirror (and if you don't, well, why not?) Just make sure your
servers only pull from that local mirror, and you're done.


I do have the local mirror (more like a package proxy at the moment),

But this mechansim does require a certain finesse.  running apt update 
&& apt upgrade against that local mirror/proxy may cause it to update to 
versions not quite desired, which leads to a specialized mirror with 
pre-cleared packages, but, well, I'm not that sophisticated quite yet.




[...]

So, as an accommodation,  a flag in the preseed mechanism to
enable/disable would be helpful.  But would need to be exposed in
maybe the expert mode menus, which I think was already mentioned.


What Raphaël was proposing is exactly that, yes.

Also, there is absolutely *no* technical difference between "the preseed
mechanism", "a low-priority debconf question", and "something in the
expert mode menus". None. Zero. Zilch.



--
Raymond Burkholder
r...@oneunified.net
https://blog.raymond.burkholder.net

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> > So, as an accommodation,  a flag in the preseed mechanism to
> enable/disable would be helpful.  
> 
> You mean something like:
> 
> Template: pkgsel/update-policy
> Type: select
> Default: unattended-upgrades
> 
> pkgsel/update-policy=none thus seem the perfect preseed choice for your
> use case.
> 

Yes, thank you, that works for me.

Is there a dictionary somewhere where I can look these things up?  From
where did you get your Template extract?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Raymond Burkholder]

> 
> I think its totally adequate to assume people want automatic security
> updates, on all kinds of systems, unless they opt out.

Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.

For my infrastructure, updates, of what ever kind, need to be incorporated into 
the test/build/roll-out cycle.

Unless I misunderstand the intent of this thread.

So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
would be helpful.  But would need to be exposed in maybe the expert mode menus, 
which I think was already mentioned.


> 
> And yes, this would be a change in behaviour we should prominently
> document, but nonetheless do.
> 
> 
> --
> cheers,
>   Holger, who has systems where he wants those and others where
>   not.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#883992: install to harddrive, ignore connected usb, reboot with preseeded grub

[Raymond Burkholder]

Package: grub-installer
Version: 1.140+deb9u1

Is there a magic incantation for preseed files to install to a harddrive
when usb is present?

There are two stages:  usb appears as /dev/sda during install process, but
appears as something else, maybe /dev/sdd during normal boot

Therefore, the target drive might be /dev/sdb during install, but shows as
/dev/sda during normal boot.

My almost working preseed file has:


# install to /dev/sdb (main harddrive), when usb shows as /dev/sda
# these two lines are correct and working for the install process
d-ipartman-auto/select_diskselect  /dev/sdb
d-i partman-auto/disk   string  /deb/sdb

# grub 
# the first value is correct to install grub
d-i  grub-installer/bootdev  string /dev/sdb

# a couple of items I've seen both true and false, but do not seem to affect
the outcome:
d-i grub-installer/only_debian boolean false
d-i grub-installer/with_other_os boolean false

# I am not sure how to get these values to work properly, or maybe I am
missing something
d-i grub-installer/choose_bootdev   select  /dev/sda2
d-i grub-pc/install_devices multiselect /dev/sda2

=

The final boot should be /dev/sda2, but /boot/grub/grub.cfg seems to take on
/dev/sdb2.

The important piece here:  HOW does one get /dev/sda2 (instead of /dev/sdb2)
into /boot/grub/grub.cfg?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#878553: netcfg: "download debconf preconfiguration file"

[Raymond Burkholder]

Package: netcfg
Version: 1.145

I have been running pxeboot with preseed successfully for a while.
Recently, with a new version of netboot from (as of today 2017/10/13/):

https://d-i.debian.org/daily-images/amd64/daily/netboot/netboot.tar.gz

I am now getting a pop up box with "Download debconf preconfiguration file"
during the automated install process, which turns it into a non-automated
install process

This is what a pxelinux.cfg file looks like:

===
p# cat /srv/tftp/pxelinux.cfg/01-00-50-56-ae-8d-15
 D-I config version 2.0
default debian-installer/amd64/boot-screens/vesamenu.c32
DEFAULT auto
  SAY Booting new build 
LABEL auto
menu label ^Auto

# stretch / testing
kernel debian-installer/amd64/linux TERM=linux keymap=us
locale=en_US.UTF-8 country=BM language=en_US:en auto
url=tftp://10.10.0.10/seeds/vmware.testing.seed domain=qvs.bm
hostname=undefined interface=ens160 netcfg/get_ipaddress=10.11.0.24
netcfg/get_netmask=255.255.255.0 netcfg/get_gateway=10.11.0.1
BOOTIF=01-00-50-56-ae-8d-15

# common append for all
append initrd=debian-installer/amd64/initrd.gz
prompt 0
timeout 3
===

In the log, there are lines like (I am retyping them as they are in a
non-copyable window):

Date/time netcfg[25054]: INFO  Found interface ens160 with link-layer
address 00:50:56:ae:8d:15
Date/time netcfg[25054]: INFO: Taking down interface ens160

It is at this point, the interactive box pops up.

What settings do I need to change to make that go away?


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#856382:

[Raymond Burkholder]

Confirmed. netboot is functional again.

Bug#856382:

[Raymond Burkholder]

In installing today’s (2016/02/28) netbook.tar.gz:

https://d-i.debian.org/daily-images/amd64/daily/netboot/netboot.tar.gz

And installing manually via pxeboot, in the console I see:

scsi_mod: disagrees about version of symbol module_layout.

Is this related?



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#841420: Patch to allow build

[Raymond Burkholder]

> -Original Message-
> From: Arthur Gautier [mailto:ba...@gandi.net]

> On Sun, Oct 30, 2016 at 01:32:14AM -0300, Raymond Burkholder wrote:
> > Step 1:
> >
> > scripts/config --disable CC_STACKPROTECTOR_STRONG
> 
> This is a step forward security, we can not just disable it on production
> systems.

Another test shows that there is no need to disable
CC_STACKPROTECTOR_STRONG.  It appears to have been a red-herring on the way
to determining the real solution (if only a work around for now)

~/linux-4.8.6$ grep CC_STACKPROTECTOR_STRONG .config
CONFIG_CC_STACKPROTECTOR_STRONG=y

Using gcc-6 6.2.0-9 with kernel 4.8.6.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#841420: Patch to allow build

[Raymond Burkholder]

Step 1:

scripts/config --disable CC_STACKPROTECTOR_STRONG

Step 2:

From
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.8-rc2/0002-UBUNTU-SAUCE-no-
up-disable-pie-when-gcc-has-it-enabl.patch

The following seems to solve some problems:

diff --git a/Makefile b/Makefile
index 5c18baa..e342473 100644
--- a/Makefile
+++ b/Makefile
@@ -612,6 +612,12 @@ endif # $(dot-config)
# Defaults to vmlinux, but the arch makefile usually adds further targets
all: vmlinux

+# force no-pie for distro compilers that enable pie by default
+KBUILD_CFLAGS += $(call cc-option, -fno-pie)
+KBUILD_CFLAGS += $(call cc-option, -no-pie)
+KBUILD_AFLAGS += $(call cc-option, -fno-pie)
+KBUILD_CPPFLAGS += $(call cc-option, -fno-pie) 

# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
ARCH_CPPFLAGS :=


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#841420: Rolling Back?

[Raymond Burkholder]

I am on
$ uname -a
Linux bldkrnl 4.7.0-1-amd64 #1 SMP Debian 4.7.8-1 (2016-10-19) x86_64
GNU/Linux

I am trying to build kernel 4.8.5 or 4.8.4 from kernel.org.  I was able to
get it building a few days ago.  Seems the recent gcc version changes
something.

In following previous entries in this ticket, I have tried the following:

scripts/config --disable CC_STACKPROTECTOR_STRONG

sed -i 's/-std=gnu89$/-std=gnu89 -fno-PIE/g' Makefile

sed -i 's/(CROSS_COMPILE)ld$/(CROSS_COMPILE)ld -no-pie/g' Makefile

sed -i 's/(CROSS_COMPILE)gcc$/(CROSS_COMPILE)gcc -no-pie/g' Makefile

And even trying with gcc-6.2.0-10:
ii  gcc-66.2.0-10 amd64
GNU C compiler

I end up with:

make[2]: Entering directory '/home/vagrant/linux-4.8.5'
  HOSTCC  scripts/basic/fixdep
/usr/bin/ld: /tmp/cc2xzDT0.o: relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a shared object; recompile with
-fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output


How do I roll back to gcc-6.2.0-6?




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files

[Raymond Burkholder]

> 
> Mostly "we take (working) patches"?
> 

Fair enough.  Would you be able give me push in the right direction and provide 
a hint as to which packages/files I should be looking at?

Bug#819725: EXT4-fs (sda2): Cannot load crc32c driver.

[Raymond Burkholder]

Package: 
linux-image
Version: 4.4.0-1
Severity: critical
Tags: d-i, stretch

I have used today's version of 
http://d-i.debian.org/daily-images/amd64/daily/netboot/netboot.tar.gz to 
perform a pxeboot with seeded configuration of stretch amd64.  Same thing 
happens if I perform a simple manual ext4 install On reboot, I get 'EXT4-fs 
(sda2): Cannot load crc32c driver.' and I end up at a busybox prompt.

If I rebuild by substituting ext4 with ext3, I get a successful boot.

Here is an example of the seed file entry for the filesystem configuration.  
Which worked in linux-image-4.3.0 earlky in March:

# for internal use; can be preseeded
d-i partman-auto/expert_recipe  string  \
  custom1 ::  \
75 1000 100 ext4\
  $primary{ } $bootable{ }  \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /boot }   \
  . \
1000 4000 5000 ext4 \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ / }   \
  . \
5000 1 10 btrfs \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ btrfs } \
  mountpoint{ /var }\
  . \
4000 8000 1 ext4\
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /home }   \
  . \
1000 1000 4000 ext4 \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /tmp }\
  .


Here is the final output of the boot sequence to console:
=
Loading Linux 4.4.0-1-amd64 ...
Loading initial ramdisk ...
modprobe: module btrfs not found in modules.dep
/dev/sda2: clean, 24088/137088 files, 160700/547840 blocks
[1.486902] EXT4-fs (sda2): Cannot load crc32c driver.
mount: mounting /dev/sda2 on /root failed: No such file or directory
mount: mounting /dev on /root/dev failed: No such file or directory
mount: mounting /run on /root/run failed: No such file or directory
run-init: current directory on the same filesystem as the root: error 0
Target filesystem doesn't have requested /sbin/init.
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
run-init: current directory on the same filesystem as the root: error 0
No init found. Try passing init= bootarg.


BusyBox v1.22.1 (Debian 1:1.22.0-18) built-in shell (ash)
Enter 'help' for a list of built-in commands.

(initramfs)

Bug#771699: Provide A Preseed Option For Ignoring The Valid-Until Field of InRelease Files

[Raymond Burkholder]

On Mon, 02 Nov 2015 18:58:34 +0100 Jonas Smedegaard  wrote:
> Quoting Cyril Brulebois (2015-11-02 17:20:04)
> > I've added this to my (not really ever-growing but yet non-empty) d-i 
> > to-do list, and I'll do the BTS dance (cloning and reassigning to 
> > debootstrap etc.) if I don't receive any negative feedback about the 
> > analysis above.

With the debian archives going through changes with sha1 deprecation, my 
pxeboot/preseed solution is failing due to reading Packages.xz and InReleases, 
amongst others.

So I attempted to revert to an older snapshot of the archives.  But I am 
encountering expiry issues.

Having this flag available in my preseed would be so handy at this point in 
time.  

How is the agenda for implementation?

Bug#810731: ifupdown_0.8.6_amd64.deb breaks systemd version 228-2+b1

[Raymond Burkholder]

Package: ifupdown
Version: 0.8.6

_amd64


Looks like this package was Migrated to testing today.

I am using stretch/testing with the Alpha4 install.

The installation is failing. On screen is a message regarding libxapian22v5, 
but syslog and the ALT-f4 screen show that ifupdown is actually at fault.

In syslog, I see lines like:

debootstrap: Errors were encountered while processing:
debootstrap:   /var/cache/apt/archives/ifupdown_0.8.6_amd64.deb
debootstrap: dpkg: regarding .../ifupdown_0.8.6_amd64 containing ifupdown:
 ifupdown breaks systemd (<< 228-3~)
   systemd (version 228-2+b1) is present and installed
debootstrap: dpkg: error processing achive 
/var/cache/apt/archives/ifupdown_0.8.6_amd64.deb (--unpack):
  installing ifupdown would break systemd, and
deconfiguration is not permitted (--auto-deconfigure might help)

In addition, the menus with 'go back' and 'continue' just go around in circles. 
 I can't get back to the main installation menu