Ed Greshko wrote:
> I have tested this in a VM and verified the failure. There is one
> exception. If the /boot directory does not contain a directory with
> the name of the "machine-id" then the upgrade will be successful.
>
> Will you be writing up the BZ?
Bug 1559118.
--
Dave Close
On 03/21/18 14:48, Tim wrote:
> Allegedly, on or about 21 March 2018, Ed Greshko sent:
>> Anyway, I've since determined that the directory name
>> 7725dfc225d14958a625ddaaaea5962b is derived from the contents of
>> /etc/machine-id
> For what it's worth, I have a collection of those empty directorie
Allegedly, on or about 21 March 2018, Ed Greshko sent:
> Anyway, I've since determined that the directory name
> 7725dfc225d14958a625ddaaaea5962b is derived from the contents of
> /etc/machine-id
For what it's worth, I have a collection of those empty directories on
my older installation (FC26), a
On 03/21/18 04:54, Stephen Morris wrote:
> I also have a couple of questions (which may be off topic here)
Yes, for sure off-topic.
You need to start your own thread if you encounter questions not related to
resolving
the issue of an OP.
--
Conjecture is just a conclusion based on incomplete
On 03/21/18 07:46, CLOSE Dave wrote:
> Greshko wrote:
>
>>> I think I found the problem. Comparing packages installed on this
>>> problem machine with others, I noticed that grubby was not
>>> installed. After installing it and then re-installing the kernel,
>>> I find the kernel in /boot where i
Greshko wrote:
>> I think I found the problem. Comparing packages installed on this
>> problem machine with others, I noticed that grubby was not
>> installed. After installing it and then re-installing the kernel,
>> I find the kernel in /boot where it belongs.
>>
>> Evidently, something isn't
On 03/21/18 07:02, CLOSE Dave wrote:
> I think I found the problem. Comparing packages installed on this
> problem machine with others, I noticed that grubby was not installed.
> After installing it and then re-installing the kernel, I find the kernel
> in /boot where it belongs.
>
> Evidently, som
I think I found the problem. Comparing packages installed on this
problem machine with others, I noticed that grubby was not installed.
After installing it and then re-installing the kernel, I find the kernel
in /boot where it belongs.
Evidently, something isn't checking dependencies sufficiently.
Ed Greshko wrote:
>> It seems clear that some script or scriptlet in the package is not doing
>> its job. But they seem pretty simple and I don't see any dependencies
>> which would make them fail on this machine and not others.
> That would seem to be a fair conclusion.
>
> I think I would loo
On 03/21/18 03:05, CLOSE Dave wrote:
> It seems clear that some script or scriptlet in the package is not doing
> its job. But they seem pretty simple and I don't see any dependencies
> which would make them fail on this machine and not others.
>
>> # rpm -qp --scripts kernel-core-4.15.9-300.fc27.x
On 03/21/18 01:09, CLOSE Dave wrote:
> Ed Greshko wrote:
>
All of those directories are empty, yes?
>>> Most, but not all:
>>>
/boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
initrd linux
/boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
initrd
The only way I know to produce these results would be to override the
build_root location someplace.
echo ${RPM_BUILD_ROOT}
There are probably other ways to override it.
On Tue, Mar 20, 2018 at 3:24 PM, CLOSE Dave
wrote:
> Roger Heflin wrote:
>
>> I would run this and see where rpm thinks they
On 21/3/18 7:24 am, CLOSE Dave wrote:
Roger Heflin wrote:
I would run this and see where rpm thinks they should be since they
are not in /boot
rpm -qa --filesbypkg | grep -i vmlinuz
Evidently, RPM thinks they should be in /boot (as I would expect):
$ rpm -qa --filesbypkg | grep -i vmlinuz
Roger Heflin wrote:
> I would run this and see where rpm thinks they should be since they
> are not in /boot
> rpm -qa --filesbypkg | grep -i vmlinuz
Evidently, RPM thinks they should be in /boot (as I would expect):
> $ rpm -qa --filesbypkg | grep -i vmlinuz
> kernel-core /boot/.vmlinuz-4
I would run this and see where rpm thinks they should be since they
are not in /boot
rpm -qa --filesbypkg | grep -i vmlinuz
On Tue, Mar 20, 2018 at 2:05 PM, CLOSE Dave
wrote:
> The following procedure did NOT fix my problem. Using RPM instead of DNF
> still did not install the new kernel in /boo
The following procedure did NOT fix my problem. Using RPM instead of DNF
still did not install the new kernel in /boot.
Note, the new kernel is not in /boot when I start.
> # ls /boot
> 7725dfc225d14958a625ddaaaea5962b
> config-4.14.11-300.fc27.x86_64
> efi
> extlinux
> grub2
> initramfs-0-rescue
Ed Greshko wrote:
>>> All of those directories are empty, yes?
>> Most, but not all:
>>
>>> /boot/7725dfc225d14958a625ddaaaea5962b/4.15.8-300.fc27.x86_64:
>>> initrd linux
>>> /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64:
>>> initrd linux
>
>
> I get the feeling, based on the
On 03/20/18 07:23, CLOSE Dave wrote:
> Ed Greshko wrote:
>
>>> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
>>> 0-rescue 4.13.10-200.fc26.x86_64 4.13.9-200.fc26.x86_64
>>> 4.11.11-300.fc26.x86_64 4.13.11-200.fc26.x86_64 4.14.11-300.fc27.x86_64
>>> 4.12.11-300.fc26.
Ed Greshko wrote:
>> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
>> 0-rescue 4.13.10-200.fc26.x86_64 4.13.9-200.fc26.x86_64
>> 4.11.11-300.fc26.x86_64 4.13.11-200.fc26.x86_64 4.14.11-300.fc27.x86_64
>> 4.12.11-300.fc26.x86_64 4.13.12-200.fc26.x86_64 4.14.4-200.
On 03/20/18 02:54, CLOSE Dave wrote:
> [root@machine ~]# ls /boot/7725dfc225d14958a625ddaaaea5962b
> 0-rescue 4.13.10-200.fc26.x86_64 4.13.9-200.fc26.x86_64
> 4.11.11-300.fc26.x86_64 4.13.11-200.fc26.x86_64 4.14.11-300.fc27.x86_64
> 4.12.11-300.fc26.x86_64 4.13.12-200.fc26.x86_6
On 20/3/18 8:05 am, CLOSE Dave wrote:
Further information from another attempt a few minutes ago. Could the
broken pipe be the problem? What could cause that? /boot is at 52%.
I don't think the broken pipe is causing the issue, I'll need to check
next time there's a new kernel, as when I run t
Further information from another attempt a few minutes ago. Could the
broken pipe be the problem? What could cause that? /boot is at 52%.
> # /usr/bin/dnf -y reinstall kernel*-4.15.9-300.fc27.x86_64
> Last metadata expiration check: 23:59:22 ago on Sun Mar 18 14:00:12 2018.
> Dependencies resolved
Further, here is an extract of /var/log/messages for the attempted
reinstall, surpressing the timestamp and dracut indicator.
> dracut-046-8.git20180105.fc27
> Executing: /usr/bin/dracut
> /boot/7725dfc225d14958a625ddaaaea5962b/4.15.9-300.fc27.x86_64/initrd
> 4.15.9-300.fc27.x86_64
> dracut modu
Rick Stevens wrote:
>> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
>> the right place (/boot) and is not detected by GRUB. Why not?
> Sure looks like the scriptlet didn't run. I think you should get a
> report about the initramfs image and the system map having different
On Mon, Mar 19, 2018 at 12:54 PM, CLOSE Dave
wrote:
> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> the right place (/boot)
Just a wild-ass guess here, but how much free space do you have in the
partition that contains /boot?
--greg
___
On 20/3/18 5:54 am, CLOSE Dave wrote:
Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
the right place (/boot) and is not detected by GRUB. Why not?
For example, after installing the most recent new kernel, I see this.
[root@machine ~]# ls /boot
7725dfc225d14958a625ddaaaea5
On 03/19/2018 11:54 AM, CLOSE Dave wrote:
> Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
> the right place (/boot) and is not detected by GRUB. Why not?
>
> For example, after installing the most recent new kernel, I see this.
>
> [root@machine ~]# ls /boot
> 7725dfc225d1
Fedora 27 x86_64. When DNF installs a new kernel, it isn't going into
the right place (/boot) and is not detected by GRUB. Why not?
For example, after installing the most recent new kernel, I see this.
[root@machine ~]# ls /boot
7725dfc225d14958a625ddaaaea5962b
config-4.14.11-300.fc27.x86_64
efi
28 matches
Mail list logo
