Root Device
Violetta Wagganer
Your problem seems to be something different. And as this is a [SOLVED] thread you will not likely get much attention here. Start a new thread detailing what you have done and a description of when in the boot process you get the kernel panic, and link back to this thread if you think it is relevant.
Sorry my bad. I should know that I should not post anymore to [SOLVED] posts. Anyway my error was that I missunderstood the above stated post from you which is about kernel building and kernel hooks. I finally understood that I only had to edit the grub.cfg. Sorry again...
@wucherpfennig, posting in a thread marked as [solved] is okay. It is just that the issue you are posting about seems to be something totally different than the one described in the thread. So Trilby is just pointing this out. You'd likely be better off trying to address your problem in either a new thead, or one that directly relates to the problem that you are having (without hijacking the thread of course).
The above post is bad advice. The point of the fsck hook was never about what pid 1 might or might not do (hint, init has always fsck'd devices going back to sysvinit) but that fsck can be performed in early userspace before the filesystem is even mounted. This lets you fix more errors without rebooting, as fsck'ing later on necessitates that the disk is mounted (and read-only).
@silent, Considering that Fedora uses systemd and is likely going to have this same requirement for rw to skip the fsck, I expect that the issue should be easily resolvable. But also, the Arch kernel name and initramfs file name do not change. They stay persistent and the old kernel gets removed. We do not end up with countless kernel version like some other distributions. So I am not sure how it would be an excessive amount of work to make a persistent grub addition for Arch Linux. Apparently grub2 has a hell of a time recognizing Arch Linux anyway, so making something in the custom configuration grub script would probably be easiest, and not require the user to change anything "each time".
Also, the wiki is not always right, but someone once said, that falconindy is. That being the case, I would listen to falconindy. But in this particular case, you are advising that people use one fsck facility over the other, which is fine. But the fsck in the intiramfs has advantages, none of which were addressed in your post of (what falconindy called) bad advice. So you are giving up the advantages of having an initramfs fsck simply so you don't have to possibly change the 'ro' to 'rw'?!
Thank you falconindy! I've been trying to understand how to fix this for a few days. Finally after carefully reading enough I figured out where the change needed to be made (in my grub.cfg file). I found that file early on, but it said not to change it (because it was automatically generated...). Just wanted to say I appreciate your efforts (and can feel your frustration from reading all your posts on this topic).
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
@nixcamic @uroni How exactly did you end up fixing the issue with your root device. I seem to have run into the same thing on linux mint and i really dont know enough about the boot system to figure out how to fix it.
On the distribution that I am using right now, Arch Linux ARM, Linux is launched without an initial RAM disk, meaning the kernel does all the work in mounting the root filesystem. This system is installed on an SD card and it has a script on it that needs to determine the device node of the filesystem that it resides on. This device node can change depending on how I boot the device up (e.g., I attach it to another device that is already running).
However, I wanted to create an new instance which needed a larger root file system, actually around 3GB to fit the initial image into. Since the default is to create a 2.5GB root partition, I tried the following in order to get an initial (larger) partition:
However, can I suggest that this sounds like a right old b@ll ache? Could I ask for a feature request to allow the initial default profile to be overridden when creating an instance??!! It would be massively easier to be able to do something along the lines of:
It feels baffling to me that the simplest way to change the size of the initial size of an instance is to edit the defaults for your storage pool, create the instance and then revert the changes on the storage pool?? Surely there must be a simpler method??
It just feels unexpected that one of the most important aspects of a virtual machine (storage size of the root filesystem) cannot be specified anywhere, except very indirectly via the storage pool itself? I feel I must be missing something? Can we not use profiles or config keys to override the storage volume?
But, for VMs, this is controlling the volume size, not the filesystem size.
As I explained above, this is because for VMs (not containers) LXD does not mandate a particular partition layout or filesystem be used.
Can you advise if there is a way to create an initial server with a blank filesystem, grow it, then later on I can have the image installed? Note, a process which would be convenient for this current requirement (migrating VMs from another machine) is to be able to create a skeleton VM, rsync the data across, replacing the whole image?
Is there another way to create the initial instances? Assume a user moderately familiar with LVM and not looking for a supported lxc path here. This is strictly to get access to the raw partitions to preload initial data?
However there was a bug in the recently added -d flag that would not work properly when combined with the -s flag, in that it would restore the original profile root disk storage pool, and then override the size.
I don't have enough rep to add a comment to the selected answer, but I do want to point out that for me, /dev/sda1 did not work (did not attach as root), but using /dev/xvda worked (attached as root). The instance is one of the newer t2.micro ones using HVM.
To elaborate on Diomidis Spinellis's comment in the the accepted answer's comments thread, it's important to check the filesystem label of the device you're attempting to switch in as your new root device. While troubleshooting my own server migration, I had to do the following before my instance would boot up:
This is the aws suggested solution You can detach the root volume from the original instance after stopping it. The root volume is attached at /dev/sda1. Once this is detached, please attach it to the new instance. After the volume is attached, you may have to mount it from the OS. After it's mounted, you should see the data within it.
When your volume is mounted, it gets a post-fix with numbers, eg: when /dev/sda is mounted, its mounted as /dev/sda1, /dev/sda2 depending on the partitions you make.As we are mounting the root device itself, it assumes the device is already mounted, so we need to give /dev/sda1 for mounting the volume as root device.Note: There shouldn't be any root volume attached.
Thank you for all of your support so far in helping get our board up and running. I'm able to load SPL and u-boot from an SD card, and then begin loading the Linux kernel, but it hangs on the message "waiting for root device"
I've been reading through several of the existing posts and this seems to be related to an SD card detect problem. I'm able to successfully read from the SD card during u-boot because the bootloader doesn't use the SD card detect pin. I confirmed with a scope that the pin is high when unplugged, and pulled low when an SD card is inserted. At this stage, I would be ok disabling the SD card detect altogether but I haven't been able to do so successfully.
How can I completely disable checking the SD card detect pin in order to get around this error? Are there any kernel changes required? Why is it not detecting the SD card detect pin pulled low? Here's the relevant source in my dts file.
This ended up being a problem with my device tree file. I had used the auto-generated copy from TI pinmux tool, but I noticed that they are defined slightly differently syntax for the MMC signals in some of the reference dts files. I changed PIN_INPUT to PIN_INPUT_PULLUP and it loaded Linux from the SD card. Perhaps the pinmux tool generated dts file for an older copy of Linux source.
I assume that this is a custom board. U-boot appears to successfully read uImage from the SD-Card. The bootlog should say something about detecting the card and size. Perhaps your kernel is using the wrong GPIO for card detect. Or maybe pinmux hasn't been changed to reflect your custom board.
On the OMAP-L138, the pinmux is not usually set by the device driver. On that processor, the peripheral can be muxed to more than one pin. The choice of which pin is board dependent. For the OMAP-L138, see kernel source here:
Although your custom board may have the same SD design as the EVM, you may had added a peripheral that uses the same pins are the SD. The add peripheral may configure the pinmux after the SD. This will overwrite the SD's pinmux configuration. The board code does try to check for conflicts. In your bootlog, these lines are from the checks:
59fb9ae87f