You are not logged in.
I think there is a bug report for this issue: https://bugs.archlinux.org/task/33745
Offline
Offline
Took me a while and building the kernel from source to realize it but apparently my mirror (http://ftp.iinet.net.au/pub/archlinux/$repo/os/$arch) was stale and had only the 3.12-1 (3.12.0-1) package, not the current 3.12.1-1 package. I switched mirrors and latest is now booting fine as well.
Offline
The latest 3.12.1-3 package seems to have resolved this problem for me. Everything seems to be booting fine.
Offline
That is very odd that 3.12.1-3 would fix it. The only difference between 3.12.1-1 and 3.12.1-2 is a patch that fixes btrfs balance with preallocated files. The only difference between 3.12.1-2 and 3.12.1-3 is that the kernel component to Checkpoint/Restore In Userspace (CRIU) was turned on. Hmmmm...
Offline
I will test tomorrow when I get home after uni.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Woofy: Hmm... that's super weird. I definitely tried 3.12.1-1, which did not boot, and I'm definitely running 3.12.1-3 now. Super weird...
Offline
I guess this kind of falls in line with how some users (jasonwryan included) found certain Arch kernels to be unbootable, yet building his own with the same config worked just fine.
Offline
I guess this kind of falls in line with how some users (jasonwryan included) found certain Arch kernels to be unbootable, yet building his own with the same config worked just fine.
Not with the same config, but a subset thereof.
Offline
Not with the same config, but a subset thereof.
Ah, my bad. It still is a bit befuddling why it would work perfectly via self compilation but sometimes not at all with the Arch package.
Offline
Woofy: Hmm... that's super weird. I definitely tried 3.12.1-1, which did not boot, and I'm definitely running 3.12.1-3 now. Super weird...
i update tu 3.12.2-1 and doesn't boot, so i downgrade to 3.12.1-3 and it works again
Offline
i update tu 3.12.2-1 and doesn't boot, so i downgrade to 3.12.1-3 and it works again
3.12.2-1 is working fine for me....
Last edited by tom5760 (2013-12-03 17:14:23)
Offline
By the way, it is fairly easy to compile and install a specific kernel version as separate package, so that after upgrades a running kernel version is still present.
1.) Choose a running kernel version from https://projects.archlinux.org/svntogit … ages/linux and simply click on the commit message.
2.) "tree" now shows file versions of the kernel version you chose.
3.) Download those files, edit PKGBUILD:
#pkgbase=linux # Build stock -ARCH kernel
pkgbase=linux-custom # Build kernel with a different name
4.) Run makepkg, install the package, run
mkinitcpio -p linux-custom
5.) Add this kernel to your bootloader.
Offline
I just finally updated to the newest kernel and to my surprise, everything is working again. I am noticing some delay between the screen with all the loading services (i.e. the one displaying [ OK ] <message>) and the login prompt, but I'll reboot again later to see if this persists.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
Last mentioned issue has not returned, so we're all good.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
This appears to have resurfaced in 3.12.7-1 for me. Downgrading to 3.12.6-1 fixes the problem.
Offline
Oh god, I think I have this issue. I updated yesterday and I couldn't boot. I wish I looked here earlier. I have resintalled arch many times and still can't boot, probably because every time it will still install 3.12.7-1.
Ok, what is an easy way to fix this? Does 3.12.7-2 in testing fix this??
Offline
Nope I have this issue in 3.12.7-2. Downgrading to 3.12.6-1 fixed the issue for me.
Offline
Same. I tried 3.12.7-2 with no luck. got things working with 3.12.6-1. I really wish I had found this issue before wiping my / partition and reinstalling.
Anyone know what is causing the problem in the bad kernels?
Offline
Same. I tried 3.12.7-2 with no luck. got things working with 3.12.6-1. I really wish I had found this issue before wiping my / partition and reinstalling.
Anyone know what is causing the problem in the bad kernels?
I am not sure if this will help but I think this is EFI and gcc related. I have been having no problems with EFI booting stock or my custom kernel (based on ABS kernel) until the latest gcc update (4.8.2-6 => 4.8.2-7). 3.12.6-1 stock booted fine as it was built and uploaded to the repos before the latest gcc update but I tried building my custom kernel based on 3.12.6-1 with gcc 4.8.2-7, it compiled fine but it would not boot (blank screen). Downgraded gcc and gcc-libs to 4.8.2-6 and it worked. My machines booting from standard bios are working properly with 3.12.7-1. I have not had time to try to track this down to anything that would resemble a bug report. Will report back when I get a moment to update my custom kernel.
Offline
I wish the failure mode wasn't just a totally blank screen. With a blank screen it is impossible to try to figure out what the cause is.
Offline
I wish the failure mode wasn't just a totally blank screen. With a blank screen it is impossible to try to figure out what the cause is.
Boot the machine to the failure, then use a live USB to either read the journal from the running live environment or from a chroot. See if you can find anything relevant.
You could also use another machine or even an android phone to see if you can ssh into the machine. If it really is just failing to display any using but continues the normal boot sequence (and you have sshd.service enabled) then you should be able to at least gain access that way.
Offline
You could also use another machine or even an android phone to see if you can ssh into the machine. If it really is just failing to display any using but continues the normal boot sequence (and you have sshd.service enabled) then you should be able to at least gain access that way.
I'm pretty certain that it isn't just the display failing. I have a LUKS encrypted root partition, with the password prompt being the first thing shown when booting. After typing my password to a blank screen, there is no disk activity (laptop HDD light does not come on) or anything like that.
Offline
I'm pretty certain that it isn't just the display failing. I have a LUKS encrypted root partition, with the password prompt being the first thing shown when booting. After typing my password to a blank screen, there is no disk activity (laptop HDD light does not come on) or anything like that.
I agree - and I suspect it is just the combination of a UEFI bootloader and the new kernels. I have no encryption or any other special modules, but I got a dumb blank screen out of both the 7-1 and 7-2 kernels. Reverting to 6-1 fixes the problem, and frustratingly enough, it appears that whatever kills the boot process kills it too early for it to leave anything in the systemd logs.
Offline
f4hy wrote:I wish the failure mode wasn't just a totally blank screen. With a blank screen it is impossible to try to figure out what the cause is.
Boot the machine to the failure, then use a live USB to either read the journal from the running live environment or from a chroot. See if you can find anything relevant.
From the live usb and chroot'ing into the environment, the journal shows nothing after the end of the last shutdown sequence, there are no messages leading me to believe that this is related to EFI and compilation of the ramfs image (with the current version of gcc)
You could also use another machine or even an android phone to see if you can ssh into the machine. If it really is just failing to display any using but continues the normal boot sequence (and you have sshd.service enabled) then you should be able to at least gain access that way.
Can't ping the machine in this state, if others have the same problem as me, nothing is loading. Only way to stop the machine is to hold the power button, even Ctrl + Alt + Del does not restart the machine as expected.
I get the black screen error when booting 3.12.7-1 and 2. Upgrading my custom kernel to a 3.12.7-1 base also has the same issue. Had to live cd and downgrade to my 3.12.6-1 based kernel that compiled with the previous version of gcc for now.
Offline