Bug#801961: debian stretch amd64 netinst: no xfsprogs. xfs on
On Sat, Oct 31, 2015 at 02:30:28AM +0000, Steve McIntyre wrote:
>root fails to boot.
>Reply-To:
>In-Reply-To: <20151017170320.GJ22011@einval.com>
>X-attached: unknown
>Fcc: =debian/boot
>
>Following up on this particular thread...
>
>On Sat, Oct 17, 2015 at 06:03:20PM +0100, Steve McIntyre wrote:
>>retitle 801961 base-installer: needs to install queued packages before linux-image
>>severity 801961 important
>>thanks
>>
>>ACK, and thanks for the logs. They *do* show a problem as well. In the
>>first installation, I can see
>>
>>Oct 16 21:37:38 apt-install: Queueing package xfsprogs for later installation
>>...
>>Oct 16 21:41:25 in-target: Setting up linux-base (4.0) ...
>>Oct 16 21:41:25 in-target: Setting up linux-image-4.2.0-1-amd64 (4.2.1-2) ...
>>Oct 16 21:41:27 in-target: update-initramfs: Generating /boot/initrd.img-4.2.0-1-amd64
>>Oct 16 21:41:32 in-target: Warning: /sbin/fsck.xfs doesn't exist, can't install to initramfs, ignoring.
>>Oct 16 21:41:46 in-target: Setting up linux-image-amd64 (4.2+68) ...
>>...
>>Oct 16 21:41:58 in-target: Preparing to unpack .../xfsprogs_4.2.0_amd64.deb ...
>>Oct 16 21:41:58 in-target: Unpacking xfsprogs (4.2.0) ...
>>Oct 16 21:41:58 in-target: Setting up libreadline5:amd64 (5.2+dfsg-3)...
>>Oct 16 21:41:59 in-target: Setting up xfsprogs (4.2.0) ...
>>
>>which means there's an ordering problem here - update-initramfs is
>>being run before we've had a chance to install xfsprogs and so it's
>>failing there. It looks like we need to explicitly add some sequencing
>>for the package installations here to fix that. If we just made sure
>>xfsprogs was installed first, that would help!
>>
>>For now, there should a simple workaround here - re-run the package
>>installation step for linux-image-* and it'll get xfsprogs on the
>>second pass.
>
>Following through on this, I can see that the ordering is determined
>right at the end of base-installer/debian/bootstrap-base.postinst :
>
>waypoint 1 check_target
>waypoint 1 get_mirror_info
>waypoint 100 install_base_system
>waypoint 1 pre_install_hooks
>waypoint 1 setup_dev
>waypoint 1 configure_apt_preferences
>waypoint 1 configure_apt
>waypoint 3 apt_update
>waypoint 5 post_install_hooks
>waypoint 1 pick_kernel
>waypoint 20 install_kernel
>waypoint 10 install_extra
>waypoint 0 final_apt_preferences
>waypoint 0 cleanup
>
>install_kernel and install_extra are the two functions in question. It
>*seems* like simply changing the order of those two calls may fix this
>bug, and I've just done a successful (simple!) test installation with
>that change made. However, this is also a key part of the installer
>and I'm worried that changing this may break installation of other
>packages, e.g. if there are any that queue things via apt-install but
>need the kernel to be installed first. Checking through current d-i, I
>can see lots of callers to apt-install:
<snip>
>Some things like bootloaders here are probably going to care about
>being installed after the kernel (maybe), but well-behaved such
>packages should also be triggered by further kernel package
>installations anyway I'd hope. Filesystem tools shouldn't care. Not
>sure about others here - anybody?
>
>So we have a few ways to go, I think:
>
> 1. Make the change and test / wait for people to scream?!?
>
> 2. Split up the apt-install delayed queue, add a separate queue for
> things like fs tools to be installed before kernel
>
> 3. Excplicitly add an extra call to update the initramfs late in
> installation, to make sure that all necessary tools are installed
>
> 4. Any others?
So, talking to Colin at the miniconf, he's worried that this may break
lots of things. A better answer would be to make sure that all the fs
tools packages force an update of the initramfs after
installation. That's probably what we want *anyway* in the longer
term, to make sure that when updates happen to tools we get those
updates in the initramfs too. This means that we need to file bugs
agsinst all the existing fs tools packages that don't call
update-initramfs right now.
Unless any of you see a problem with that, I'll start filing bugs
shortly with patches.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...
Reply to: