| Summary: | System starts but no IO device works, also no dmesg and no journal logs get written (kernel-4.9.56-1.mga6) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Bernard MAUDRY <ramaspaceship> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | ftg, marja11 |
| Version: | 6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kernel-4.9.56-1.mga6.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Bernard MAUDRY
2017-10-22 09:28:53 CEST
Sorry for the typing mistakes; I cannot find how to edit them. I rebooted using the kernel 4.9.50 (In reply to Bernard MAUDRY from comment #1) > Sorry for the typing mistakes; I cannot find how to edit them. > I rebooted using the kernel 4.9.50 Unfortunately, editing a comment is impossible. You did well by adding a new comment with the correction :-) Assignee:
bugsquad =>
kernel This is a wild guess, but if the kernel detects disk I/O errors on the root partition during boot, it marks it read-only, which might account for some of what you see (no logs, etc.). Can you log in from a tty and try to "touch /test.file" and see what you get ? CC:
(none) =>
ftg Unfortunately, without keyboard input, I cannot do what you ask. By the way, is this disk I/O error detection behaviour specific to kernel 4.9.56? If not, I should not be able to boot kernel 4.9.50 normally. You mentioned that autologin worked, so I assumed you were getting a GUI desktop. Also, you stated that journalctl and dmesg gave no output, so I assumed you had *some* keyboard access that worked. Are you sure that you can't get a tty session or boot in failsafe mode ? (In reply to Bernard MAUDRY from comment #4) > By the way, is this disk I/O error detection behaviour specific to kernel > 4.9.56? > If not, I should not be able to boot kernel 4.9.50 normally. I suppose the particular sectors accessed on a disk can vary from kernel to kernel. If a kernel doesn't get an error reading or writing the areas of the disk it tries to read or write, then it won't trigger the read-only behavior. > You mentioned that autologin worked, so I assumed you were getting a GUI > desktop. I do, but I had no input, either with the mouse or the keyboard > Also, you stated that journalctl and dmesg gave no output, so I assumed > you had *some* keyboard access that worked. Yes, but only after rebooting with kernel 4.9.50 > Are you sure that you can't get a tty session or boot in failsafe mode ? I am sure that I was unable to switch to a virtual tty as I tried this I didn't try the failsafe boot. I will do it now. I had to re-install kernel 4.9.56 as I removed it to avoid any mistake. I booted it in safe mode and got access to the maintenance mode. I quit the console to let the boot process continue. Everything worked correctly. I then rebooted kernel 4.9.56 in normal mode, and I am typing this with it. It seems that there were some corruption during the first installation of this kernel that the second installation fixed. I will do a check on the boot disk to see if fsck detects some errors. fsck -f didn't detect any error on the boot partition I wonder what happened. Sorry for the false alert. Status:
UNCONFIRMED =>
RESOLVED |