I'm not sure if this is the right section for this, but I had to post somewhere and no other categories seemed likely...
the title says it all. I edit /boot/grub/grub.cfg or /etc/default/grub and the bootloader ignores the changes. For example, I change the kernel to boot into from my custom one to the stock one -- and it boots into my custom one, despite the fact that the changes are contained withing grub.cfg.
Does anyone see a fix for this issue?
Last edited by ParanoidAndroid (2013-05-27 23:42:03)
After the editing did you do a grub-mkconfig?
After the editing did you do a grub-mkconfig?
Though this is significant if you are editing /etc/default/grub, the OP has indicated that he has also tried editing /boot/grub/grub.cfg manually, so I think this issue goes beyond that often overlooked step.
Do you have any other grub configurations that it may be using? Maybe another distribution dual-booting, or maybe more than one drive? So you have determined that it is not using the grub.cfg you think it should be using. But it is certainly using a configuration somewhere. So I think it is just a matter of figuring out what configuration it is actually using.
I reinstalled grub and that seemed to fix the issue. Interestingly, now both of my kernels (stock arch, fallback) are completely b0rked. My custom one is working, but the other two won't even load an initramfs... and before that X wouldn't start under them. I need to boot into a stock kernel in order to recompile my custom one... I need the fuse module and had forgotten to load it prior to the last modprobed_db store command. I bought a new phone, and it doesn't support MSC mode. Only way to mount the damn thing is through mtpfs, and that requires fuse. Android devs are complete idiots. That aside, I'm rather fatigue-drunk right now, and if anyone has a clue how any of this bizarre affair could have happened, I'm welcome to hear it.
Hey-O! somewhere over the init framework lies a kernel panic...
too. much. coffee.
I don't understand why you need to boot into the stock kernel in order to build a custom one. Why is that?
Though I cannot tell you definitively why your various kernels are borked (your fatigue-drunk ass didn't leave much information ), I can tell you that common reason why kernel things get borked is an unmounted /boot. This leads to inconsistency between /boot/vmlinuz-linux and /usr/lib/modules/linux-*. In turn, that leads to your initramfs failing to do what it needs to do, or worse, putting together an initramfs that is no good. Have you tried to simply uninstall/reinstall the stock kernel? Of course, you then also need to check grub to make sure that it is generating what it should be generating, which it doens't always do.
I reinstalled the stock arch kernel after checking that /boot was mounted by fstab. hopefully that helps. I need to rebuild the kernel using stock because I need to be able to load the fuse driver, since my custom one does not have it any recompiles will also not have it, unless I'm much mistaken. Is there a way around that? I'll reboot and test this, and I'll let you know the results.
Last edited by ParanoidAndroid (2013-05-27 23:43:44)
nope, didn't help. still broken.
is there any way I can load a module into my kernel without actually having the module on the running kernel?
I am pretty sure that you need to build the module with the rest of the kernel. That is unless you have a module that is meant to be build against the kernel headers, but the fule module is lated within the kernel tree, so I think a rebuild would be required. I could be wrong though, as I have never tried to pull a module from another kernel of the same version and load it.
I just don't understand why you need to be booted from the stock kernel in order to build your custom kernel. Building a kernel should have nothing to do with what you are booted from, so long as you have all the necessary components to compile things. So I guess I am asking, why can't you build a new custom kernel from your curently working environment?
Well, I suppose there isn't any reason... I was simply under the impression that the module had to be loaded in the running kernel for localmodconfig not to strip it.
In other news, my build script won't work. it fails to fetch the bfs patch... looks like Con Kolivas' website is buggy. That or tor simply doesn't play nice with it.
I could simply compile the vanilla kernel, substitute it for my fallback kernel, and use that. Either way, it looks like my custom kernel won't be rebuilt for ages, unless Kolivas' website is back in proper working order any time soon. Is it possible to simply download the module source, build it, and insert? my running kernel is a 3.8.8 version.
Ah, you use localmodconfig. See now everything makes a bit more sense. So why not just use /proc/config.gz as the starting configuration, then use nconfig, menuconfig, xconfig, etc to make any further modifications? That is, it sounds like what you have is already to your liking with the exception of the fuse module. So take what you've got, use it, then make the necessary modifications to make that improvment... compile!
BTW, I am getting to CK's patches just fine on my machine. If you had done this before compilation/patching before, I don't see why that file would have been accessible before and not now.
tried a recompile, did everything by the book, and rendered kernel unbootable. Nothing I did (regen initcpio, etc) could fix it, and the same cryptic GRUB error message appeared when attempting to boot any of the three kernels I have. Something about cryptouuid. I did a complete system reinstall and am now using the stock arch kernel. After going back to stock, I can say that the bfs scheduler was not all it's cracked up to be... I'll stick with stock from now on. No more kernel-compile forays for me.
Got my phone working with mtpfs now that fuse is in the running kernel, so I can get files transferred despite the lack of MSC mode. Why the android devs didn't stick with MSC, I'll never know. It's so much less of an issue, on any given system. Only thing that supports MTP out of the box is Micro$oft's crashware turd, M$ Windows... they took linux (a UNIX-like system), built a phone OS out of it, then denied UNIX-based systems easy access to said OS in favor of a slower, inefficient, Micro$oft-invented protocol. Bah.
Bluetooth is having issues now, despite the reinstall. The bluetooth device (hci0) is missing, even though the systemd unit for bluez is running. I had this issue on my previous stock install before I moved to a custom kernel and built bluetooth directly into the kernel, and if it behaves as before it will randomly work and not work across reboots. If anyone in this thread has an answer, that would be awesome. Otherwise I'll repost under networking. Either way, the original GRUB issue is fixed, so I'm marking this thread solved.
So I am a relatively new android user. I have a nexus 7 and that is all. My phone is actually a really ghetto pay-as-you-go flip phone. But when I got my device, I also wondered how they could build a Linux based system that is so difficult to access from real Linux (or any other *nix for that matter). I ended up just using sftp or samba or even adb to move files between devices. I found it to be much easier and much, much faster than the mtp bs they have going there.