HI Dann
Thanks for your rapid reply!
> I'm happy to regression test a candidate patch on the xgene/u-boot
> and non-xgene/uefi platforms we have once Ryan or some other curtin
> maintainer is OK with the approach.
Sure thanks.
> I think the kernel recommending flash-kernel if GRUB is already
>
> In my POC patch, it is because we need to divert flash-kernel before
> it is installed, *just in case* it gets installed as a dependency of
> some other package (in our case it happened due to a kernel Recommends
> relationship). We therefore can't use `which` to look up the path...
> unless we c
attach patch (WIP)
** Patch removed:
"0001-curthook-disable-arch-sepcific-package-in-disable_up.patch"
https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1918427/+attachment/5477385/+files/0001-curthook-disable-arch-sepcific-package-in-disable_up.patch
** Patch added:
"0001-curthook-disa
maybe we can try this patch with alternative path to disable arch-
specific binaries before that package is installed.
when `which` didn't get any path for system, we assume that binary isn't
installed for now.
and still disable it via alternative path
** Patch added:
"0001-curthook-disable-arc
Hi Ryan
> (though I don't know if dpkg-divert cares about the presence
of the binary-to-be-diverted).
I tried dpkg-divert with my mustang and flash-kernel (see in attachment)
It's ok for dpkg-divert even that package isn't installed.
** Attachment added: "dpkg-divert.log"
https://bugs.launch
agree with dannf
we should refactor disable_update_initramfs and enable_update_initramfs.
we should not use `which` to determine the executable path.
and always disable update_initramfs or arch-specific package, even those pkgs
are not installed.
Is it a good solution that we specific absolute pa
Maybe this WIP patch will work fine and we don't need to refactor
disable_update_initramfs.
this patch also consider if there is already initramfs or flash-kernel
installed.
Try to guarantee order
But this might override and deactivate bugfix for LP:1640519
** Patch added: "install_bootloader_
There is no need to install flash-kernel here.
It will install flash-kernel in "ephemeral image" which didn't have kernel
installed.
https://git.launchpad.net/curtin/tree/curtin/deps/__init__.py?h=21.2#n57
So that means, curtin will never install flash-kernel into real system because
flash-kerne
After reading log in #14, and some code from cloud-init and maas
I still cannot find any code that will let cloud-init try to install
flash-kernel wtih zfsutils-linux.
and it seems the error because squashfs didn't have any kernel installed.
So `linux-version` cannot find any kernel version to pas
Hi Dann
I'm not sure how to test custom kernel with Curtin during installation.
I will try to install it into non-flash-kernel system and see APT will install
it or not.
As your advice, I have a question about this.
If this question isn't critical, I think this should work.
Do we need to conside
here is the reason why ARM64 U-boot isn't effected by this issue, and why APM
Mustang with UEFI will be effected.
I'm not sure MAAS install this kind of machine will start from cloud-img with
existing kernel and initrd.img or not.
Here is the curtin process in installation ISO right now.
1. Dete
related to this issue
https://bugs.launchpad.net/subiquity/+bug/1856038
I will submit an issue to Debian `flash-kernel`, and get issue number
back to here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bug
12 matches
Mail list logo
