I ran out of space while installing MYKERNEL...

Hi guys,

I have just tried to customise my kernel for the first time ever, and it was all going smoothly until the installation stopped halfway because I ran out of space on /. Now when I look at boot I can see the original kernel is now 'kernel.old' and the new incomplete kernel is 'kernel'. Can I just rename them and reboot? Or is there a trick to rolling it back in this situation? Add to this, it is a hosted server so I can not access the boot menu! :(
 
hedgehog said:

make fails:
If the make command fails, it usually signals an error in your kernel description which is not severe enough for config(8) to catch. Again, look over your configuration, and if you still cannot resolve the problem, send mail to the FreeBSD general questions mailing list with your kernel configuration, and it should be diagnosed quickly.


I am sure a simple yes or no would have been easier than creating a link to a page that suggests I post the issue here...


Beastie: Thanks. I am going to try moving the old kernel out of the folder while I rebuild, them remove the symbols and put it back. Hopefully they will both fit then.


I would still like to know if I can just delete the new kernel and replace it with the old?
 
Yes, you can replace/rename /boot/kernel.old/ to /boot/kernel/ to restore the status before you start compiling your own kernel.

Btw. it's very inconvenient to do a remote kernel install without any means of remote console though.
 
Thanks Matoatlantis :) love the tag line too :D best episode ever!

This remote administration is a nightmare on so many levels. But it is not my choice, I just do what I can with what I am given.

I know it is a simple question, but my google-fu was unable to find an answer.


Following on from Beaties comment, does this mean I can remove the *.symbols from /boot/kernel as well as /boot/kernel.old?
 
Depends what you did or you are trying to do. If you tried to install a custom kernel and it failed the first time you did it, you can safely remove the /boot/kernel/ directory and then rename /boot/kernel.old/ to it.

Before I do a custom kernel I always rename release /boot/kernel/ to a /boot/GENERIC, so I have a working kernel if I screw up something (I do have a remote console though).

Symbols are handy when you are debugging system crash for example. They are not a necessity.

Off-topic: yop, if I have to name 3 best futurama episodes ever I have to definitely mention one the tag line comes from :)
 
Great! thanks :)

I have just added a few options to enable ipfw. Which will be yet another issue with remote administration.

Code:
options IPFIREWALL
options HZ=1000
options IPFIREWALL_DEFAULT_TO_ACCEPT ##Safety net to be disabled after testing is complete
options IPDIVER

After clearing out the symbols in kernel.old I have heaps of space, so I won't need to remove the symbols from the new kernel just yet.

I have submitted a ticket to the host to do a monitored reboot. It should be simple enough, they are surprisingly competent, certainly more so than I am anyway lol Otherwise they have periodical backups they can roll back to.


Thanks again for all your help guys.
 
If you're customising the kernel anyway and don't need the symbols files, just scrap
Code:
makeoptions     DEBUG=-g                # Build kernel with gdb(1) debug symbols
 
ghostcorps said:
I am sure a simple yes or no would have been easier than creating a link to a page that suggests I post the issue here...
Sure thing. But there is also an addition info on that page that might be helpful.
 
ghostcorps said:
This remote administration is a nightmare on so many levels. But it is not my choice, I just do what I can with what I am given.
Depending on whether this is your (owned) server in a remote data center or a system you are renting, it might be possible to add a remote management option to it. Most Dell servers can have a DRAC (Dell Remote Access Card) installed. Here is an old Dell whitepaper that explains them.

Other brands usually offer something similar, either as an add-in card or as an option on the motherboard.

If you don't own the system or it can't be upgraded to have a remote management card, you could connect a serial port on the system to a single-line terminal server (like this one from Digi). With FreeBSD set to use a serial console (see the handbook), you get most of the advantages of a built-in remote access card without needing to modify the server. The difference is that you can't control things like the BIOS setup via the serial port, whereas the remote access card does (it gives you a remote copy of the video display). Some systems allow a "BIOS serial redirect" which would let you manage the BIOS via serial port as well.

If this is something you think would be possible, feel free to post or PM what system you have, and I'll tell you what works and give you some setup hints. I don't sell this stuff, but I do have a lot of experience with the different remote management options under FreeBSD.
 
Great suggestions :)

I have worked with DRACs before, but the server is virtualised in a cloud so I doubt there would be a DRAC or a serial port but you make me realize there must be something of the sort, being in a cloud, I guess it is just a matter of whether or not they let me have access to it.

I will chase it up.

Thanks!
 
ghostcorps said:
I have worked with DRACs before, but the server is virtualised in a cloud so I doubt there would be a DRAC or a serial port but you make me realize there must be something of the sort, being in a cloud, I guess it is just a matter of whether or not they let me have access to it.
If it is a virtual server, it should have a virtual console :e

Assuming the instance is dedicated for your use (I've never heard of a shared virtual server), they should let you access the virtual console.
 
I have not been given a virtual console, but they took over the reboot after I customised the kernel. They took a snapshot, and rebooted, thankfully it all worked out :D

Thanks for all your help guys :)
 
Back
Top