I cant boot my linux machine due to /etc/fstab having bad lines of code. Currently my machine will attempt to boot and will infinitely loop the message "Welcome to Emergency Mode!..." . I can't get to the console or login.
Hitting escape at the start up screen and entering the rescue mode does not work either. Using grub2 i can see my fstab file via : cat (lvm/centos-root)/etc/fstab.
How can i edit this file and remove the bad lines of code?
Boot from a live DVD, or boot in rescue mode from the installation disk. If necessary (it probably won't be), manually mount the main system's root partition somewhere (e.g. /mnt/rescue). Edit /mnt/rescue/etc/fstab appropriately. Perform a clean reboot.
Related
I wanted to have my Raspberry Pi update the system clock from a GPS on start up but now something has gone wrong and I can't login.
I created a bash script that calls 'sudo -i' and a few other gpsd related instructions. I pointed the /etc/profile towards the script. If I Ctrl+C to get to a prompt I get root access but the directories are listing nothing when I use the 'ls' command. If I exit from root I get stuck again. I figure that if I could delete the bash script the problem would go away but I don't know how to view that partition of the SD card on a PC. Any suggestions?
Ok, I solved the problem. There is a ext4 partition editor called ExtFS for Windows. You can view and edit an ext4 partition easily in this program. You can download it here.
I have placed a faulty kernel object in the rc.local. Because of this faulty kernel object,the system crashes on bootup. Now, my aim is to remove that faulty ko insmod from rc.user. However, I cannot access rc.user as my system crashes on bootup. How can I fix this issue?
If you are getting the grub screen then you can
go to runlevel 1 and change the file.
On grub screen you will have to
press a after selecting the Fedora kernel with which you want to boot.
APPEND single after space in that line and press enter
press b to boot in single user mode
You can edit any file in this mode.
The safest & easiest approach when I get into such troubles is to mount the HD (contaning the faulty kernel) as an external hard drive to another linux machine and manually edit the files causing trouble.
Do a fdisk -l with your HD plugged in (thorugh USB). Take notice of the </dev/sd*#>.
mount /media /dev/<sd*#>
Now, you can access your boot or root partition to access the files.
I was trying to figure out how to run a program at boot, but after realizing this program is an infinite loop, I have no way of getting out, or back to the terminal. Right when I give the Pi power it just goes right to the program on a black background. I don't remember exactly what I did to make it run at boot, I believe I just added some code in a place right above something that said "exit 0" and below something that says "esac". I don't remember the command that even got me there. (I am new to the Pi and Python and have just been playing around..unsucessfully.)
If anyone could help me either delete this program or get me to be able to edit it so I can fix the infinite loop that would be great. I'd rather not have to completely over-write the sd card with a fresh raspbian. But like I said I can't do anything at boot, and Ctrl + C doesn't do anything nor Ctrl + Alt + Delete.
EDIT: When I put the SD card in my computer, I see a list of 11 files:
bootcode
cmdline
config
fixup
fixup_cd
issue
kernel
kernel_cutdown
kernel_emergency
start.elf
start_cd.elf
None of these mean anything to me...
Update: Looks like I failed to get that you want to interrupt the running bootprocess and stop the script.
The simplest idea would be to turn of the pi, unplug the sd card and plug it into your desktop, (re)move the script and boot again.
Processes spawned during boot are stored in scripts in /etc/init.d/.... These scripts are called by the init process, the first process on a Linux machine (PID:1)
But init starts not all scripts in /etc/init.d. This depends on the run level. On a debian system there are 7 run levels.
For every run level there is a folder called like:
/etc/rc0.d
...
/rc6.d
in which are softlinks to scripts from /etc/init.d are stored.
To remove a script from being executed on every boot you'll delete all links from that folders. Usually on debian systems this is done using the update-rc.d tool:
update-rc.d NAME_OF_INIT_SCRIPT remove
You should also have a look at the file /etc/rc.local
Alt + PrintScn + k to kill the process stuck running from rc.local
You can use the cmdline.txt.
First, add or modify the cmdline.txt file on your sd card. Add "init=/bin/sh", then restart your Pi, and you can see a command line prompt.
Type 'sudo nano /etc/rc.local' to edit the file, and comment or delete the line containing the error. After that restart.
I had exactly the same issue, couldn't quit the process using CTRL+C. I edited the cmdline.txt like stated above, but then the pi didn't load the necessary usb drivers for my keyboard.
So eventually I logged in over SSH to the pi, and modified my rc.local file that way.
In my case worked combination "Alt" + "F4", it stops the current session and opens the login screen
I had the same problem as explained at the beginning of this Post. My Python app was caught in an endless loop.
I tried the Ctrl+Alt+F2 Command as recommended in many posts found in Internet without any terminal window being open. Apparently, after many other trials and reboots I saw a glimpse of a Terminal window each time the loop of my application restarted. It was impossible to catch anything until I started recording the screen using the slow motion video of my mobile phone and, yes, a terminal window with the Linux prompt was active, and able to accept keyboard entries.
All I did was (almost blindly) editing the culprit file with the
sudo nano filename command
and entering some characters in order to actually corrupt such file, saving and closing it, a rebooting the Pi.
At the end of the boot, the file produced an error but the system kept ready to operate.
I was then able to fix the bug in a normal way.
It hope this may be useful to others. In my case it spared me of burning a new Raspbian and losing all my previous work.
I got myself stuck in exactly the same problem. Luckily I had the ssh enabled, apparently this is disabled by default on Raspbian Jessie, so this may not work for all.
The exit 0 is the line in /etc/rc.local where you would have added in the script that is now running in a continuous mode. If you can ssh into the Pi using Putty and the Pi's IP address then
sudo nano /etc/rc.local
Scroll down to the bottom of the file and remove the offending program, then sudo reboot
They way to prevent this issue from happening is to add an & (ampersand) to the end of the line to fork the process and run it as a separate process like so
python /home/pi/myscript.py &
as specified in https://www.raspberrypi.org/documentation/linux/usage/rc-local.md
The ampersand allows the command to run in a separate process and continue booting with the process running.
I have a Linux System based LFS (Linux from Scrach). Linux kernel version 2.6.29.6 #1 SMP PREEMPT. This system uses Extlinux bootloader and boots from SSD (Micron USB Solid State Device). There is also a seconday harddrive in this system but not meant for booting. We changed the booting from HDD to SSD as we found SSD is fast and reliable over HDD.
Whenever there is a power outage, the unit reboots, the power Outage causes the SSD corruption. After reboot, the Fsck command is run by the script checkfs. The system halts with the Error message ""UNEXPECTED INCONSISTANCY; Run fsck manually error and unit halts and fails to reboot until we manually reboot.
I checked the checkfs script and found that, in this condition, the fsck -a -A -C -T is run and returns error value > 3 and < 16 for which the action is to halt the system and reboot using CD and run fsck manually and fix the issue.
I tried changing the checkfs script and used fsck -y which fixed all the errors and the unit booted normally but while fixing the issues, many files were deleted. Secondly if i ignore the fsck error and instead of system halt, if i go ahead with normal boot, it works but since it doesnt fix the filesystem issues, the unit may not work properly.
At this point i would like to know if there are any work arounds to resolve this issue and still boot the system normally and fix the filesystem issues? can i do something like if fsck fails then umount root file system from SSD and mount it from HDD and boot normally, then after boot recover SSD filesystem? if yes any pointers to do this? Please suggest.
You can append 'fastboot' as a kernel argument (in grub) to skip fsck.
I have started reading the book Essential Linux Device Drivers. I am following the process for compiling and booting into a new kernel. However I am unable to boot into the newly compiled kernel - I select the new kernel in grub and then ..nothing...the screen just stays the same.
Here are the steps I am taking, as described in the book (I am using kernel 2.6.24 as that is what the book is based on) -
cd /usr/src/linux-2.6.24 (the base dir of the kernel I downloaded)
make clean
cp arch/x86/configs/i386_defconfig .config
make bzImage cp arch/x86/boot/bzImage /boot/vmlinuz
The book says that 'you might need to alert your bootloader about the arrival of the new boot image. If you are using the GRUB bootloader, it figures this out automatically'.
Well it didn't figure it out automatically in my case as there was no option to select this kernel in GRUB. So I did it manually by typing update-grub in the terminal. And this didn't work either. However once I changed the filename from vmlinuz to vmlinuz-2.6.24 and type update-grub it picked it up. So on page 11 of the book there seems to already be multiple things left out...
The book says to then reboot the machine.
Anyway, I am now able to select this kernel in GRUB but as I said above it doeesn't boot properly, the screen just goes blank and never changes. So am I missing something? I have followed the instructions in the book exactly.
Most automatic grub setups include kernel options to hide the messages generated as the kernel attempts to boot. For example:
/boot/vmlinuz-x.x.x.x-generic root=UUID=something ro quiet splash
While on the grub menu line of the kernel you wish to boot, press 'e' to temporarily edit it, and delete options such as quiet and splash (but leave the ro).
Then boot the temporarily modified line, and see the progress messages in order to get an idea where the boot is failing.
The default configuration probably requires an initrd (e.g. because the file system and root device needs their driver, from modules, which is what initrd provides).
You could either configure your kernel appropriately (carefully enabling as in-kernel, not in-modules, the essential drivers) for your particular hardware, or use a procedure to build a kernel package with its initrd.
You should find a procedure appropriate for your linux distribution and habits, e.g. something like this or that. I am using on Debian:
time fakeroot make-kpkg -j2 --initrd --revision=3.4.2 --append-to-version=-amd64 binary