kernel image path

kernel image path

[Sumit Kumar]

Hi,
When I do sb make in a Kernel sand box where is the resultant image stored
?

--
Thanks and Regards,
Sumit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180508/c7dd644c/attachment.html>

kernel image path

[Sumit Kumar]

Sorry, there is a typo : I meant make -jX in a kernel sandbox.

On 8 May 2018 at 00:39, Sumit Kumar <sumit686215@gmail.com> wrote:

> Hi,
> When I do sb make in a Kernel sand box where is the resultant image stored
> ?
>
> --
> Thanks and Regards,
> Sumit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180508/b5a416b6/attachment.html>

kernel image path

[valdis.kletnieks at vt.edu]

On Tue, 08 May 2018 00:45:25 +0530, Sumit Kumar said:

> Sorry, there is a typo : I meant make -jX in a kernel sandbox.

The same place it puts it if you don't use -jX.  The exact answer will depend on
what sort of sandbox you're using, and how exactly you're setting things up,
and what system(s) you're building for.

For example: on x86_64, by default the kernel ends up in arch/x86/boot/bzImage.

If you have your build tree at /usr/src/linux, that means it ends up in /usr/src/linux/arch/x86/boot/bzImage.

If you're building in a directory called '/source/kernel' inside a chroot based at '/containers/build-kernel',
it will end up in /containers/build-kernel/source/kernel/arch/x86/boot/bzImage (as viewed from
outside the chroot).

Being more specific will require knowing what exactly you're trying to do....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180507/c789b544/attachment.sig>

kernel image path

[Sumit Kumar]

Hi Valdis,

Thanks for the quick reply.

I wanted to find out where the kernel images are stored to check their 
size.

My local kernel repository size has inflated to around 14 GB after 
building kernel a few times. I was wondering if it keeps previous images 
as well which could be taking a lot of disk space. By looking into arch 
folder it seems kernel image takes around 8 MB. Max. space is used by 
drivers folder - I guess its the object files from all the drivers. I am 
again left wondering if building kernel drivers multiple times keeps the 
older driver object or replaces it with newer one.

I am little bit short on disk space right and hence needed to clear few 
things out.

--

Thanks and Regards,

Sumit


On Tuesday 08 May 2018 01:13 AM, valdis.kletnieks at vt.edu wrote:
> On Tue, 08 May 2018 00:45:25 +0530, Sumit Kumar said:
>
>> Sorry, there is a typo : I meant make -jX in a kernel sandbox.
> The same place it puts it if you don't use -jX.  The exact answer will depend on
> what sort of sandbox you're using, and how exactly you're setting things up,
> and what system(s) you're building for.
>
> For example: on x86_64, by default the kernel ends up in arch/x86/boot/bzImage.
>
> If you have your build tree at /usr/src/linux, that means it ends up in /usr/src/linux/arch/x86/boot/bzImage.
>
> If you're building in a directory called '/source/kernel' inside a chroot based at '/containers/build-kernel',
> it will end up in /containers/build-kernel/source/kernel/arch/x86/boot/bzImage (as viewed from
> outside the chroot).
>
> Being more specific will require knowing what exactly you're trying to do....

kernel image path

[valdis.kletnieks at vt.edu]

On Tue, 08 May 2018 03:12:31 +0530, Sumit Kumar said:
> My local kernel repository size has inflated to around 14 GB after
> building kernel a few times. I was wondering if it keeps previous images
> as well which could be taking a lot of disk space.

Not sure what you mean by "local kernel repository".  The kernel build directory
should use pretty much the same amount of disk each time you build it (unless
you're using O= pointing at a different place each time, in which case it's doing
exactly what you told it to do...)

Note that if you install a lot of kernels, you'll end up with lots of
subdirectories in /lib/modules if you don't clear them out.  Particularly a
problem if you build a kernel a week (like I do) and use a "distro" config that
builds almost everything (I don't do that).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180508/59d762c6/attachment.sig>

kernel image path

[Sumit Kumar]

Thanks Valdis. I checked /lib/modules directory. It had a lot of 
subdirectories - one for each kernel build I guess, each one around 4GB. 
I have removed some of the older one's with "rm" cmd. I hope it doesn't 
break grub.

--

Thanks and Regards,

Sumit


On Tuesday 08 May 2018 10:03 AM, valdis.kletnieks at vt.edu wrote:
> On Tue, 08 May 2018 03:12:31 +0530, Sumit Kumar said:
>> My local kernel repository size has inflated to around 14 GB after
>> building kernel a few times. I was wondering if it keeps previous images
>> as well which could be taking a lot of disk space.
> Not sure what you mean by "local kernel repository".  The kernel build directory
> should use pretty much the same amount of disk each time you build it (unless
> you're using O= pointing at a different place each time, in which case it's doing
> exactly what you told it to do...)
>
> Note that if you install a lot of kernels, you'll end up with lots of
> subdirectories in /lib/modules if you don't clear them out.  Particularly a
> problem if you build a kernel a week (like I do) and use a "distro" config that
> builds almost everything (I don't do that).
>

kernel image path

[valdis.kletnieks at vt.edu]

On Wed, 09 May 2018 00:37:42 +0530, Sumit Kumar said:
> Thanks Valdis. I checked /lib/modules directory. It had a lot of
> subdirectories - one for each kernel build I guess, each one around 4GB.
> I have removed some of the older one's with "rm" cmd. I hope it doesn't
> break grub.

Grub doesn't care, it only cares that the bzImage/vmlinuz and (if needed)
initramfs that you listed in the grub config file are there. (Actually, it
doesn't actually *check* until you try to boot a kernel and it can't find
them there, at which point it will tell you...)

The kernel you boot will care if one of the directories you nuked from
/lib/modules was for the version of the kernel you booted.  In other words,
if you did an rm -r /lib/modules/4.19.9-rc12  you may as well toss any
4.19.9-rc12 files in /boot and the Grub menu.

However, the initramfs *should* have included any modules needed to get
your root filesystem mounted, so even if you removed the directory for a
given 'uname -r', you should still be able to boot single-user.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20180508/6a1a15fd/attachment.sig>

kernel image path

[Sumit Kumar]

Thanks a lot Valdis.

--

Thanks and Regards,

Sumit


On Wednesday 09 May 2018 12:54 AM, valdis.kletnieks at vt.edu wrote:
> On Wed, 09 May 2018 00:37:42 +0530, Sumit Kumar said:
>> Thanks Valdis. I checked /lib/modules directory. It had a lot of
>> subdirectories - one for each kernel build I guess, each one around 4GB.
>> I have removed some of the older one's with "rm" cmd. I hope it doesn't
>> break grub.
> Grub doesn't care, it only cares that the bzImage/vmlinuz and (if needed)
> initramfs that you listed in the grub config file are there. (Actually, it
> doesn't actually *check* until you try to boot a kernel and it can't find
> them there, at which point it will tell you...)
>
> The kernel you boot will care if one of the directories you nuked from
> /lib/modules was for the version of the kernel you booted.  In other words,
> if you did an rm -r /lib/modules/4.19.9-rc12  you may as well toss any
> 4.19.9-rc12 files in /boot and the Grub menu.
>
> However, the initramfs *should* have included any modules needed to get
> your root filesystem mounted, so even if you removed the directory for a
> given 'uname -r', you should still be able to boot single-user.