Re: shared /boot support. bz 197065
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Yep!
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, [...]
For the sake of consistency we IMHO should use the same delimiter
between $(uname -r) and arch in all places. E.g. either . (like
quoted above) everywhere or a -, like we already use in the devel
packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
CU
knurd
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
[...]
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer -touch
$RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config
$RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} +install -m 644
System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} +
touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, [...]
For the sake of consistency we IMHO should use the same delimiter
between $(uname -r) and arch in all places. E.g. either . (like
quoted above) everywhere or a -, like we already use in the devel
packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
One thing I like about using . over - is that you'd get
2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what
rpm -q outputs, now that we're defaulting to outputting n-v-r.arch.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On 25.03.2008 13:47, Jarod Wilson wrote:
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
[...]
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer -touch
$RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config
$RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch} +install -m 644
System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch} +
touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, [...]
For the sake of consistency we IMHO should use the same delimiter
between $(uname -r) and arch in all places. E.g. either . (like
quoted above) everywhere or a -, like we already use in the devel
packages (e.g. /usr/src/kernels/2.6.25-0.141.rc6.git5.fc9-x86_64).
One thing I like about using . over - is that you'd get
2.6.25-xzy.fc9.x86_64 for uname -r output, which matches up nicely with what
rpm -q outputs, now that we're defaulting to outputting n-v-r.arch.
Sounds good. Or, IOW: I'm fine with using . as delimiter, if we use it
for the directories found in the devel packages as well.
This whole idea of course means that there are some adjustments needed
for kmods in livna (or other kernel module packaging schemes). That
shouldn't be to hard; doing it for F9 might be a bit late, but if you
guys really want to go that route I'm sure we'll find a way to deal with
it before F9 ships.
CU
knurd
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Tuesday 25 March 2008 12:54:07 pm Jarod Wilson wrote:
On Tuesday 25 March 2008 12:49:28 pm Jarod Wilson wrote:
On Tuesday 25 March 2008 08:58:00 am Thorsten Leemhuis wrote:
On 25.03.2008 13:47, Jarod Wilson wrote:
On Tuesday 25 March 2008 02:02:04 am Thorsten Leemhuis wrote:
On 24.03.2008 20:53, Jarod Wilson wrote:
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
[...]
Test build up and running:
[EMAIL PROTECTED] x86_64]# ls /boot/*.x86_64*
/boot/config-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/initrd-2.6.25-0.152.rc6.git7.fc9.x86_64.img
/boot/System.map-2.6.25-0.152.rc6.git7.fc9.x86_64
/boot/vmlinuz-2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# uname -r
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /lib/modules/
2.6.25-0.152.rc6.git7.fc9.x86_64
[EMAIL PROTECTED] x86_64]# ls /usr/src/kernels/
2.6.25-0.152.rc6.git7.fc9.x86_64
And here's the patch I came up with for the above:
Crap, disregard that version. Things blow up on flavo{,u}red builds, because
the flavo{,u}r gets inserted between the f9 and .arch instead of after arch
(the ppc64 build blew up on kdump bits). So a teeny bit more spec hackage
required, but its still doable.
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
shared /boot support. bz 197065
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Index: kernel.spec
===
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.521
diff -u -p -r1.521 kernel.spec
--- kernel.spec 21 Mar 2008 15:27:16 - 1.521
+++ kernel.spec 24 Mar 2008 19:20:58 -
@@ -1268,15 +1268,15 @@ BuildKernel() {
mkdir -p $RPM_BUILD_ROOT%{debuginfodir}/%{image_install_path}
%endif
mkdir -p $RPM_BUILD_ROOT/%{image_install_path}
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
if [ -f arch/$Arch/boot/zImage.stub ]; then
cp arch/$Arch/boot/zImage.stub
$RPM_BUILD_ROOT/%{image_install_path}/zImage.stub-$KernelVer || :
fi
$CopyKernel $KernelImage \
- $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
-chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
+chmod 755
$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer.%{_arch}
mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
@@ -1570,7 +1570,7 @@ fi\
#
%define kernel_variant_posttrans(s:r:v:) \
%{expand:%%posttrans %{?-v*}}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.%{_arch} || exit $?\
%{nil}
#
@@ -1587,7 +1587,7 @@ if [ `uname -i` == x86_64 -o `uname -i
[ -f /etc/sysconfig/kernel ]; then\
/bin/sed -i -e 's/^DEFAULTKERNEL=%{-s*}$/DEFAULTKERNEL=%{-r*}/'
/etc/sysconfig/kernel || exit $?\
fi}\
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*} || exit $?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --mkinitrd --depmod
--install %{?1} %{KVERREL}%{?-v*}.%{_arch} || exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --add-kernel %{KVERREL}%{?-v*} || exit $?\
@@ -1600,7 +1600,7 @@ fi}\
#
%define kernel_variant_preun() \
%{expand:%%preun %{?1}}\
-/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1} || exit $?\
+/sbin/new-kernel-pkg --rminitrd --rmmoddep --remove %{KVERREL}%{?1}.%{_arch}
|| exit $?\
#if [ -x /sbin/weak-modules ]\
#then\
#/sbin/weak-modules --remove-kernel %{KVERREL}%{?1} || exit $?\
@@ -1668,10 +1668,9 @@ fi
%if %{1}\
%{expand:%%files %{?2}}\
%defattr(-,root,root)\
-/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}\
-/boot/System.map-%{KVERREL}%{?2}\
-#/boot/symvers-%{KVERREL}%{?2}.gz\
-/boot/config-%{KVERREL}%{?2}\
+/%{image_install_path}/%{?-k:%{-k*}}%{!?-k:vmlinuz}-%{KVERREL}%{?2}.%{_arch}\
+/boot/System.map-%{KVERREL}%{?2}.%{_arch}\
+/boot/config-%{KVERREL}%{?2}.%{_arch}\
%{?-a:%{-a*}}\
%dir /lib/modules/%{KVERREL}%{?2}\
/lib/modules/%{KVERREL}%{?2}/kernel\
--
http://www.codemonkey.org.uk
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, Mar 24, 2008 at 03:32:37PM -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) This looks sane, from my quick once over and fairly novice understanding of rpm... ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) Aparently pm-utils will need a change to cope with the changed filename, but I think that should be the limit of the damage. (oprofile will need to append the archname on the end of System.map-$ver filenames, but they're user-passed anyway, and not coded anywhere afaik Hmm. Not sure about Systemtap). I have this sinking suspicion that more things depend on the filenames, although I'm not coming up with what at the moment... We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? cheers, Kyle ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, Mar 24, 2008 at 03:46:44PM -0400, Kyle McMartin wrote: On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) Aparently pm-utils will need a change to cope with the changed filename, but I think that should be the limit of the damage. (oprofile will need to append the archname on the end of System.map-$ver filenames, but they're user-passed anyway, and not coded anywhere afaik Hmm. Not sure about Systemtap). I have this sinking suspicion that more things depend on the filenames, although I'm not coming up with what at the moment... We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? I'm running a tree-wide grep right now, and it's already picked up anaconda, bootchart, booty apt. I expect kexec-tools, and yum will probably be in the list too. I'm starting to wonder if this is worth it for such a small use-case. Dave -- http://www.codemonkey.org.uk ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Mon, 2008-03-24 at 15:46 -0400, Kyle McMartin wrote: On Mon, Mar 24, 2008 at 03:38:38PM -0400, Jeremy Katz wrote: On Mon, 2008-03-24 at 15:32 -0400, Dave Jones wrote: I took a stab at bz 197065 and arrived at the patch below. Would appreciate some eyeballs before I commit from people familiar with the macro goo in the specfile. (Hi Roland!) Aparently pm-utils will need a change to cope with the changed filename, but I think that should be the limit of the damage. (oprofile will need to append the archname on the end of System.map-$ver filenames, but they're user-passed anyway, and not coded anywhere afaik Hmm. Not sure about Systemtap). I have this sinking suspicion that more things depend on the filenames, although I'm not coming up with what at the moment... We could use systemtap to run for a while with this set and watch to see if anything boinks the wrong file? It's not running system things -- it's things like anaconda, the anaconda image build scripts, livecd-creator, mkinitrd, ... So systemtap doesn't help much (well, unless there are more things depending on it!) And those are just what I've found in a quick look :-/ Jeremy ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 03:32:37 pm Dave Jones wrote:
I took a stab at bz 197065 and arrived at the patch below.
Would appreciate some eyeballs before I commit from people
familiar with the macro goo in the specfile. (Hi Roland!)
Aparently pm-utils will need a change to cope with the changed
filename, but I think that should be the limit of the damage.
(oprofile will need to append the archname on the end of System.map-$ver
filenames, but they're user-passed anyway, and not coded anywhere afaik
Hmm. Not sure about Systemtap).
Comments?
Yep!
-install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer
-install -m 644 System.map $RPM_BUILD_ROOT/boot/System.map-$KernelVer
-touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img
+install -m 644 .config $RPM_BUILD_ROOT/boot/config-$KernelVer.%{_arch}
+install -m 644 System.map
$RPM_BUILD_ROOT/boot/System.map-$KernelVer.%{_arch}
+touch $RPM_BUILD_ROOT/boot/initrd-$KernelVer.img.%{_arch}
For the sake of consistency, I'd try to keep $KernelVer and %{_arch} together.
The above would give
us for example config-2.6.25-1.fc9.x86_64, System.map-2.6.25-1.fc9.x86_64 and
initrd-2.6.25-1.fc9.img.x86_64. I'd make the initrd either
initrd-2.6.25-1.fc9.x86_64.img or
initrd.img-2.6.25-1.fc9.x86_64.
-/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*} || exit
$?\
+/sbin/new-kernel-pkg --package kernel%{?-v:-%{-v*}} --rpmposttrans %{?1}
%{KVERREL}%{?-v*}.
%{_arch} || exit $?\ %{nil}
I suspect this will make new-kernel-package very unhappy, since I think its
expecting to be fed what
essentially amounts to $(uname -r).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
I will probably continue to find it desireable to make a dozen different
100-200M partitions to use as /boot for installs, so I don't really care
about the name noncollision. But it sure would make it a little simpler
to use (hd0,N)/ TAB in GRUB to remind me which partition is which, as
I'm always doing.
I didn't really review the spec bits thoroughly. But as far as spec
magic and building goes, I think it should be fine if you just get every
%{KVERREL}%{suffix} and make it %{KVERREL}%{suffix}.%{_arch}.
Except I think you mean %{_target_cpu}, not %{_arch}.
I agree with Jarod that keeping .%{_arch} always immediately after
%{KVERREL}%{suffix} is best. For most things, it just becomes part
of the whole kernel release string wad.
As has been noted, a lot of things will get unhappy if they cannot
use foo-`uname -r` and /lib/modules/`uname -r` as file names for
the installed bits. I can speak for systemtap/elfutils, which has
no plan other than /lib/modules/`uname -r` for where to locate the
kernel and module binaries (or user manual intervention with a switch).
Even if it were not for the trouble with finding all the hidden
dependencies on that, tools needing to be compatible across
kernel/distro versions, etc., where would those tools get the
%{_arch} value to look for? uname -m? uname -i? I don't think
either of those gets i586 when that's the kernel rpm %{_arch} and
the CPU is an i686, for example.
All this suggests to me that the only thing we really can make fly is to
include the differentiator in EXTRAVERSION. It will be noticeable to
users and probably draw a lot of questions and look redundant in many
places that display the arch too. But it would not be any new can of
worms on technical grounds.
For just 32/64 sharing and not e.g. i586/i686 sharing (both kernels of
same version selectable for the same install), it could be made less
repetitious by not using .%{_target_cpu} but instead just %(L=%{_lib#lib};
test -z $L || echo .$L), i.e. .64 or nothing. (And that would be no
suffix on ia64 et al where lib64 is not used, as well as the 32-bit cases.)
Thanks,
Roland
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: shared /boot support. bz 197065
On Monday 24 March 2008 06:36:49 pm Roland McGrath wrote:
[...]
All this suggests to me that the only thing we really can make fly is to
include the differentiator in EXTRAVERSION. It will be noticeable to
users and probably draw a lot of questions and look redundant in many
places that display the arch too. But it would not be any new can of
worms on technical grounds.
That's basically the conclusion I came to too, and I've got a 2-line spec
patch (actually also using %{_target_cpu} instead of %{_arch}) that I'm
prodding at. Definitely way too many things that'll go boom if its not there
after some discussion on irc (and on this list).
--
Jarod Wilson
[EMAIL PROTECTED]
___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
