Tag Info

Hot answers tagged

4

But init.d screws me over by changing into a screen resolution that my monitor/graphics card does not support. I have the feeling it is some VESA mode that is being changed. I don't think that's an init process. That's the kernel. It occurs during the boot messages, right? If you compile the kernel without framebuffer support, it should not happen. ...


2

You need to make an uImage with your new kernel: make uimage and copy it to e.g. /boot/uImage-3.0.7. Then you can: either make uImage point to it: cd /boot; ln -sf uImage-3.0.7 uImage, or copy: cd /boot; cp uImage-3.0.7 uImage. Could you post the output of ls -l /boot? Alternatively, you can adjust the U-boot script to load the new uImage-3.0.7. I ...


2

What kind of errors do you get? Ex: user@marconi ~ $ sudo qemu-system-x86_64 -usb -usbdevice disk:/mnt/usbdrive qemu-system-x86_64: -usbdevice disk:/mnt/usbdrive: could not open disk image /mnt/usbdrive: Is a directory qemu: could not add USB device 'disk:/mnt/usbdrive' If you see something similar, the problem is that you are providing a filesystem ...


2

During these 0.6 seconds, stuff happens. All the messages up to “Starting kernel” are printed by U-Boot All the messages from “Booting Linux” onwards are printed by the Linux kernel. The kernel needs to initialize its own data structures and a number of peripherals (enough to be able to print a trace). This takes time. You can see what the kernel is doing ...


2

You can make a more sophisticated script, which allows you to run under a specific user's permissions, as follows: #!/bin/sh NAME=myservice DESC="My Service" USERGROUP="myservice:myservice" #Helper functions start() { start-stop-daemon --start --quiet --background --make-pidfile \ --pidfile /var/run/$NAME.pid --chuid $USERGROUP \ ...


1

This is a bug somewhere in the kernel. It is not directly related to rootfs/initramfs changes. It may be due to some other change you made (did you use the same sources, the same configuration, the same compiler?), or it may be related to some timing issue that revealed a latent bug. This warning comes from handle_irq_event_percpu and the interrupt handler ...


1

The proper way to do so is (as described on the Arch Linux Wiki) # dd bs=4M if=/path_to_arch_.iso of=/dev/sdX && sync using GNU dd.


1

Chainload the ISO's bootloader using syslinux, then you can add all the extra parameters you need. Use the actual contents of the syslinux directory in the ISO as a base. There are many examples online. Check this one.


1

You are missing one of the drivers that is necessary to access your root filesystem. The code in the initramfs is looking for a block device to mount and failing, so the problem is in accessing that device. You won't get a more explicit message because the code in the initramfs can only see what it has access to and the problem is that it doesn't have access ...


1

The console=ttyO2 allows you to see the kernel and system messages on the corresponding serial port. It does not affect the boot process otherwise - the system will boot even without a console. Remember to edit /etc/inittab - change ttyS2 to ttyO2 there to get a login prompt on the serial console once the system boots. Your new kernel is probably missing ...


1

You have to disable Secure Boot: Making UEFI Secure Boot work with open platforms "Secure boot" is a technology described by recent revisions of the UEFI specification; it offers the prospect of a hardware-verified, malware-free operating system bootstrap process that can improve the security of many system deployments. Linux and other open operating ...



Only top voted, non community-wiki answers of a minimum length are eligible