Hi.
I have a dual boot notebook, with Debian9 and Windows10.
After an update on my Debian 9, there were some problem about "unexpected inconsistency" and the system asked me to run fcsk manually. The system gave me a lot of message like "linux error reading block inode force rewrite" and after a brief search online, I decided to answered yes to all of this message, and probably this was a fault of mine.

Now Windows seems boot correctly but Debian give me message "end Kernel panic - not syncing: Attempted to kill init! exit code=0x00007f00

If I boot the system from an usb stick with Debian 10 I am able to view and access the folders and the files.

Has anyone a suggestion for me ?
What can I do ?
I have to reinstall Debian ?

Thanks in advance

It would be very useful if you could capture and post the lines preceding the final panic, for example by photographing them or, better still, transcribing them onto another machine.

When you ran your fsck, did you run it from inside the system? If so, that was a mistake. You should never run this program on a mounted root partition because of the possibility of corruption. Next time, boot from a CD or pen drive and then run fsck on the hard drive root partition. Or, if you can't do that, remount the root partition as read only before fscking it (which is what your system does when it has to fsck the root partition during the boot process).

In the mean time, I think you should use your installation disk to copy to a place of safety any personal files in your home directory so that if you do need to reinstall, you won't have lost anything important.

1 members found this post helpful.

^ Yes.

But after that...
...you can chroot into your system and see if you can fix it.

1 members found this post helpful.

I suppose running a fsck on the unmounted partition wouldn't do any harm.

Thank you Hazel for the answer.

I ran fsck when the system asked me to do that, probably I ran fsck after the first boot failure. I'm quite sure that my problem was here.

[ 4.373514] Call Trace:
[ 4.373587] [<ffffffff97b35514>] ? dump_stack+0x5c/0x78
[ 4.373659] [<ffffffff979814ad>] ? panic+0xe4/0x242
[ 4.373729] [<ffffffff9787f6b3>] ? do_exit+0xb53/0xb60
[ 4.373799] [<ffffffff9787f73a>] ? do_group_exit+0x3a/0xa0
[ 4.373870] [<ffffffff9787f7b0>] ? Sys_exit_group+0x10/0x10
[ 4.373942] [ ? do_syscall_64+0x8d/0x100
[ 4. [******************] ? entry_SYSCALL_64_after_swapgs+0x58/0xc6
[ ********] Kernel Offset: 0x27800000 from 0xffffffff81000000 (relocation range: 0xfffffffff80000000-0xffffffffbfffffff)
[ *********] ---[ end Kernel panic - not syncing: Attempted to kill init! exit code=0x00007f00
[ ********]

Thank you ondoho for the answer.

Tomorrow I will study the use of the chroot command and I try to fix the system.

Do you have any other suggestion about it ?

Thanks for the trace. It looks from that as if your root partition is at least partly readable. Otherwise, you would have got a different final message. It would have said something about not finding init.

"Attempted to kill init!" means that the system's init program (systemd in your case) was actually loaded and running at the time of the crash. It was systemd which crashed and the kernel doesn't allow that. My guess is that there was a disk corruption that prevented systemd from doing its stuff.

Now if the partition was mounted read-write at the time of the crash, there might be something about it in systemd's journal. You can read the tail end of this if you boot from your installation image and use the journalctl command. If it was still mounted read-only (as it is in the early stages of system startup) then you won't find anything. But I think it is worth looking. And it is certainly worth doing another fsck on the partition when it's not mounted.

But if I were you, I'd give priority to backing up my home partition. What is on the root partition can always be replaced; what is on the home partition can't be.

1 members found this post helpful.

Thanks a lot.
Ok, I'm doing the backup of my home partition

Please could you explain me step by step what can I do ? Am I able to read the tail after the boot from my usb-stick ?

Is it also possible to do the fsck after the boot from my usb-stick ?

Yes, that's the whole point. Your usb stick contains a live Debian image, so you can carry out any valid command. As far as I can see from the journalctl man page, you can specify a particular journal to check. But you would need to have the partition mounted for that, so my advice is to do the fsck first, with the partition unmounted.

Boot from your stick and run where <n> is the number of your root partition. Because it isn't mounted, there is little risk of any further corruption. fsck might find something and fix it. Or it might find nothing.

Then mount it using .
Now you can look at the journal:
That will ensure that you get the journal on your hard drive and not the one from your usb boot. I don't guarantee that you'll find anything, but it's worth looking.

1 members found this post helpful.

Another question, I have the home partition separated, the root is where are the folder bin, boot, data, dev, etc ... right ?

******
Update

I have done the "fsck.ext4" on the partition from the live image,
the answer is: clean, 337826/1831424 files, 6083890/7323904 blocks

after that I have done the "journalctl -D /mnt/var/log | tail" the result is: -- No entries --

Now do you have any other suggestion ?

Yes, the root partition is the one that would contain those folders if it was mounted. Is that the one you fsck'd? If so, then we'll have to write off disk corruption as the cause.

"No entries" in the journal simply means that the system crashed before the journal could be written out to disk. That's a pity! Journal entries would have been useful.

If you had a traditional init system on that machine, I would recommend booting into a shell and running the init scripts by hand until you found one that played up. Then it could be fixed. But then if you had a traditional init system, I suspect your boot wouldn't have crashed in the first place. What you have instead is something called systemd, which usually works very smoothly but is difficult to fix if it does go wrong. And since I dislike it and don't use distros that rely on it, I'm not the person to help you here.

Maybe Ondoho has some additional ideas. If not, you may end up having to do the "Windows thing", i.e. reinstall, then update. Which would be a pity because fixing a misbehaving system is much more fun and in Linux you can usually do that.

1 members found this post helpful.

Here's a suggestion from another thread.

Perhaps it's worth looking at it's SMART status with smartctl. Use a "live system" running from a USB stick or similar, then run the following command and post the results using CODE tags;

Replace "sdX" with the actual device node for the drive in question. And let's see if that tells us anything. You can also use a live system to run fsck, and try and fix the filesystem problems that way (assuming it's just the filesystem that's the problem).

Already tried that (see above). We've been working on this for a couple of days now. If Zhao Lin is right, fsck cleaned the disk up at the cost of corrupting some individual files, probably pieces of systemd. It could equally have happened with a sysvinit system but in that case, it would have been simple (though perhaps laborious) to find the corrupt file and replace it. With systemd you just can't do that.

At least he's got his home directory backed up.

Sorry Hazel, missed that.

If their drive is faulty, then it would have happened anyway - systemd or not. Another idea is that they might be able to look in their /var/log/ folder on the drive in question (if it's still there), and see if there is any logs that could help, like /var/log/messages Then they could look for any messages from libata in that log.