Environment:
Remote dedicated server
FreeBSD 9.1-release with custom kernel [quota,ipfirewall,ipfirewall_default_to_accept]
SSH access
No easy KVM access (only accessible by my provider)
Goal:
Upgrade to FreeBSD 9.2-release (for a start then... to 10.1...)
Reason:
Freebsd 9.1-release is supported only until Dec 30 2014
Question:
How to upgrade FreeBSD 9.1-RELEASE to 10.1-RELEASE for instance, using freebsd-update or rebuilding the kernel and world, knowing that the server can't be accessed after being rebooted in single user mode because of the remote situation.
I read about kern.securelevel set to 2 to allow installing the world without being in single user mode, what to think about it?
How to upgrade the kernel from 9.2 sources without the 9.1 base system (it breaks, CC header problem)?
How would you proceed?
Yes i did follow these instructions (http://freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html) but as explained, it failed to boot because of an irq16 storm ; there was a problem in the usb support then. Here is the result:
vmstat -i
interrupt total rate
irq1: atkbd0 9 0
irq16: xhci0 ehci0 49440997 716
irq23: ehci1 240726 3
cpu0:timer 10114125 146
irq264: re0 3166270 45
irq265: ahci0 2493196 36
cpu1:timer 4722048 68
cpu6:timer 4767453 69
cpu3:timer 5537583 80
cpu7:timer 5928230 85
cpu2:timer 6624744 96
cpu4:timer 4985019 72
cpu5:timer 5463323 79
Total 103483723 1499
This post from an old thread confirms my suspicion that there no such option because it would not be useful:
> so, how can I make that there is no single user mode?
You need to fix
the problem that's causing it to go into single user mode. For that
you need access to the box (..) Until
you can see where startup is failing you don't know what needs fixing.
David
This assumes that the system only goes down into single user mode if some problem exists (corrupt file system, hardware trouble etc). Asking such to not happen is not possible mostly.
You might modify the system behaviour, after all you can modify it from source, e.g. here one might replace the single-user state single_user with runcom:
init.c:383
But then it is still a matter of luck, if the resulting system is usable or not.
Situation solved (was not easy) by booting on a precompiled kernel of 9.2-RELEASE with the needed kernel options. After a boot failure, in fact it's more because of hard drive file system problem, we managed to boot on this bloody kernel thru IP-KVM access.
So it's possible to keep using a GENERIC kernel and to avoid the firewall to block you right away because you don't have an hand (physically speaking) on the machine and do all that remotely.
The solution is to add these in /boot/loader.conf
net.inet.ip.fw.default_to_accept="1"
ipfw_load="YES"
and in /etc/rc.conf
quota_enable="YES"
No need to compile a new kernel for quota support either, i always thought it was the only way, good thing i was wrong.
Related
I'm trying to achieve this on a Raspberry Pi 4:
Less then 10 seconds boot time
Custom UI ( build with python/Gtk for example )
I already tried editing the /boot/config.txt with
# Disable the rainbow splash screen
disable_splash=1
# Disable bluetooth
dtoverlay=pi3-disable-bt
#Disable Wifi
dtoverlay=pi3-disable-wifi
dtoverlay=sdtweak,overclock_50=100
# Set the bootloader delay to 0 seconds. The default is 1s if not specified.
boot_delay=0
# Overclock the raspberry pi. This voids its warranty. Make sure you have a good power supply.
force_turbo=1
Also I have an A2 class 10 SdCard and I have disabled almost every service that I don't need.
My best results are 14 seconds boot time until my app started, but I need to make it faster....
I would like to achieve something like this in terms of speed, but using GTK, not QT:
https://www.youtube.com/watch?v=TTcP3xeLrEY
I am also currently trying to reach fast boot time with my Raspberry Pi 4, but I cannot breach the wall of 10s without radical solutions such as buildroot or unikernel.
What do you need on your system ? On Raspbian you can use those two commands to verify what is slowing down the boot process :
systemd-analyze critical-chain
and
systemd-analyze blame
Critical chain will show in red the services blocking the boot.
On my setup I could desactivate all those services :
hciuart #GPIOs
nmbd
smbd
wpa_supplicant
systemd-timesyncd
rpi-eeprom-update.service
raspi-config.service
networking
Just use sudo systemctl disable SERVICE , I guess there are others that are not critical for your application.
Also, in the cmdline.txt file in /boot you can add quiet fastboot , it will decrease boot time further
GTK is a toolkit coded in C and callable from C code.
In practice, Python can be 10x slower than equivalent C code.
Did you consider starting Xorg with a minimal window manager and a single client coded in C? Without a single line of Python? Of course, read more about X windows systems protocols and architecture then about EWMH.
So, remove the Python interpreter on your RaspBerryPi (probably /usr/bin/python) and replace every old Python script by an equivalent ELF executable coded in C or in C++ and compiled with optimizations (so gcc -O3 with GCC). See also linuxfromscratch.org for inspiration and guidance.
I would like to achieve something like this in terms of speed, but using GTK
Of course, you want to use a GCC cross-compiler.
If that still does not work (after weeks of effort), replace your hardware by something more powerful.
It would be easier for you to install a Linux distribution such as Debian on your development laptop or desktop. Because most of what you would learn on your development computer (e.g. Advanced Linux Programming) can be applied to the RaspBerrry Pi. And cross-building on a Debian laptop for a Raspbian RaspBerryPi is really easy. Focus on learning low-level things starting from their C code. E.g. code your GUI directly with Xlib (no GTK, no Qt) in C. The same C code is very likely to be easily portable -if you write it carefully- from x86/Debian to your Raspberry Pi.
You could read the From powerup to to bash prompt howto; most of that document is relevant for a RaspBerryPi running RaspBian.
You could even avoid starting any Xorg or other display server (e.g. WayLand) on your RaspBerryPi. That certainly would make it boot faster.
You could replace your /sbin/init program by your own one coded in C entirely. That process starts within less than a second, and forks all other processes. Your custom GUI could be just Xorg with your single X11 client coded in C.
Observe that you could have the source code (millions of source lines) of all the code running on RaspBian. Then download it, study it, and optimize it. Of course this could take decades.
First, this is a poorly formed question. You've provided no details on what your boot process is or what OS/configuration you're running with for people to help.
Regardless, you appear primarily focused on a short boot time. So since your question is generic... here is a generic answer: there is nothing magical about the boot process. There is no config file with a fast_boot=1 option that gets you up in 0 seconds instead of 15. You want to boot faster? Do less.
Throw out slow crap like Python
Remove unnecessary application loading from your init system (sysvinit/systemd/whatever)
Remove unnecessary driver loading from the kernel startup. Start by trimming down your device tree to only the hardware you really need to initialize.
Optimize your bootloader (u-boot?) to only initialize the hardware you really need (obviously turn off any prompt and timer it may implement)
That's how you boot faster.
Im looking for a way how to get rid of (kernel?) messages that appear in my ncurses app. I wrote the app myself, so i would prefer a API that redirects these messages to /dev/null. I mean messages like, a USB stick that is inserted.
I tried to add this, but unfortunately it doesn't work
freopen("/dev/null", "w", stderr);
I'm not running X, just ncurses direct from the console.
I mean messages like, a USB stick that is inserted.
Thanks!
UPDATE 1:
Someone votes to close this question because it would not be related to programming. But it is, i wrote the ncurses app myself, i'm looking for a way how to disable the kernel message. I updated the question.
UPDATE 2:
Let me explain what i'm doing, and whats the problem in more detail:
I'm using Tiny Core linux, thats after boots starts (self written) ncurses program. Now when you for example connect a USB drive, a message (i suspect kernel) is shown over my program. I guess the message is written straight into the framebuffer. Im using TC 5.x since i need 32 bit, im running as root and have full access to the os.
You should be able to use openvt to have your program run on a new Virtual Terminal.
I'll also note that it should be possible to embed control for the VTs yourself if you prefer to break the external dependency, but note that structures used may not be stable between kernel versions, and may require recompilation.
See the KBD project's sources, specifically openvt.c to see how it works.
Try configuring the kernel through boot parameters with the option:
loglevel=3 (or a lower value)
0 (KERN_EMERG) system is unusable
1 (KERN_ALERT) action must be taken immediately
2 (KERN_CRIT) critical conditions
3 (KERN_ERR) error conditions
4 (KERN_WARNING) warning conditions
5 (KERN_NOTICE) normal but significant condition
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages
source: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
See also: Change default console loglevel during boot up
It might be impossible to block some other process with sufficient access from writing to /dev/console but you may be able to redefine console as some other device, at boot time by setting console=ttyS0 (first serial port), see:
https://unix.stackexchange.com/questions/60641/linux-difference-between-dev-console-dev-tty-and-dev-tty0
Also if we know exactly which software is sending the message it may be possible to reconfigure it (possibly dynamically) but it would help to know the version and edition of Tiny Core Linux you are using?
E.g. this website has a "Core", "TinyCore" and "CorePlus" versions 1.x up to 7
http://tinycorelinux.net/downloads.html
This would help reproducing the exact same behavior and testing potential solutions.
I am running Ubuntu server 14.04.3.
I have smcroute installed - Version 0.95, Build 130523. When I attempt to start the daemon I get the error message: ERRO: addVIF, out of VIF space;, this happens after it attempts to add the 33rd network interface of my machine.
Looking in mroute.h in /usr/include/linux/ folder, I saw a MAXVIFS defined as 32, so I upped it to 100 and saved the file.
After a reboot I can still see the 32 limit being imposed, but the file still states 100. How can I force the OS to read from this file?
First, you need to understand why that number is 32. And that comes from the line below where MAXVIFS is defined:
typedef unsigned long vifbitmap_t; /* User mode code depends on this lot */
On a 32bit machine (which is where this ancient crap started), that would a 32bit register. When you want a bitmap bigger than a register, things get messy. (see also: the FD_SET() macros) 64 is safe on a 64bit machine.
To increase the number of interfaces, you need to change both the userspace define (the file you changed) AND the define in the kernel (include/linux/mroute.h within the kernel source.) Then, rebuild your kernel and every userspace application that messes with multicast.
** Changing that define alters an ioctl data structure. **
You need to rebuild (and reinstall) the kernel with the modified config. There are Ubuntu-specific instructions here
I'm late to the party, but just because you have many interfaces you don't have to recompile your kernel. Try a newer version of SMCRoute instead. You can start it with -N and specify in smcroute.conf which interfaces you intend to route between using the phyint directive. See the man page for more help.
I recently installed Linux Mint Debian Edition - it was installed into a logical partition (formatted to ext4) under a 40 GB extended partition that was previously used as a backup/recovery disk in Windows 7.
It works quite well - the only problem is when I boot to Windows, then next time, Linux won't boot. I then need to use a recovery distro and run fsck.ext4 which detects some problems with group descriptors, fixes them and it's all good again.
My feeling is that Windows tries to mount (and fix / defrag / whatever) that partition which messes it up - I suspect that, because 1) it only happens after I boot to Windows, 2) Windows still displays the old recovery/backup disk D: (although you cannot access it and it doesn't show a free/total space etc.).
Any idea how to fix it?
Just a shot in the dark, it could possibly be the listed partition type.
Check the disk with your favorite partition table editor (fdisk, cfdisk, parted, whatever), and check to see if your linux partitions are listed as Windows ones or if they are correctly listed as Linux. If they are listed wrong, you should safely be able to change this, and it could stop Windows from harassing you.
Let's say I'd like to start a small linux distro before my ordinary operating system start.
BIOS load MBR and execute MBR.
MBR locates the active partition which is my linux partition.
Linux start and I perform what I need to do.
Linux shut down and I switch to Real Mode again.
The original partition boot sector is loaded and my ordinary OS start.
AFAIK, step 4 will be the difficult task, restore the state on all devices prior to linux, will INT13h be functional? Do I need to restore the Interrupt Vector Table? To mention a few.
Has this been done in any existing project perhaps?
Linux does not normally support this, particularly since it reinitializes hardware in a way that the BIOS and DOS programs may not expect. However, there is some infrastructure to switch back to real mode in specific cases - particularly, for a reboot (see machine_real_restart in arch/x86/kernel/reboot.c) - and has code to reinitialize hardware for kexec or suspend. I suspect you might be able to do something with a combination of these - but I don't know if the result will truly match what DOS or Windows would expect to see on reboot.
A much easier plan would be to use a chainloading bootloader that can be set to boot in a particular configuration once, like GRUB. You could invoke grub-set-default, then reboot. When GRUB comes up, it would then pass control off to Windows. By then setting the fallback OS to the Linux partition, control would return to Linux on the next boot.
Yet another option may be to use Coreboot, but I'm not sure if this is production-ready for booting windows yet.
i haven't tried this so I don't know if it would work, but here goes:
There is an option in the header of a bzImage format kernel file that specifies the address of real mode code to execute before the protected mode code starts. You could create a minimal bzImage-compliant file which has no actual kernel, but which has real mode code to load your MBR using INT 0x13 to 0x7c00 and jmp into it like the BIOS does.
If you use kexec to load the bzImage using the "-t bzImage-x86 --real-mode" options, it should reset the PE bit in CR0 to drop to realmode (as bdonlan above mentioned) and execute the code pointed to by the bzImage header option.
The bzImage header option is called realmode_swtch and is documented in /usr/src/linux/Documentation/x86/boot.txt , the header format code is in /usr/src/linux/arch/x86/boot/header.S
Have you looked into kexec?