# enabling CONFIG_SUSPEND leads to invalid block device

## ccosse

Hi, I'm trying to get my Sony Vaio (model VPCF1) to suspend ... I used to do it via "acpitool -s" command but now /sys/power directory does not exist and "acpitool" says that /sys/power is required for acpitool to work.  

So I figure it's a kernel setting that's missing ... and the (seemingly) obvious ones like CONFIG_SUSPEND and CONFIG_HIBERNATE both lead to an unbootable system ... right after switching to udev it gives me the "/dev/sda3 not a valid block device" error.   

Does this sound familiar to anyone?  Thanks in advance!  Here are my kernel .config and output from dmesg:

/usr/src/linux/.config = http://bpaste.net/show/146160/

dmesg output = http://bpaste.net/show/146161/

----------

## eccerr0r

CONFIG_SUSPEND and CONFIG_HIBERNATE should not make partitions disappear.

Are you sure you didn't change any other options when enabling these?

----------

## ccosse

 *eccerr0r wrote:*   

> Are you sure you didn't change any other options when enabling these?

 

Yes, I made kernels with each toggled separately ... either variable alone causes it.   

The only other thing I did was manually set CONFIG_FB to "is not set" although I see it should be "m" even for no framebuffer stuff.  (any fb support led to no nvidia support)

Other than that I have exhaustively concluded that these 2 vars really do produce that behavior ... i just want to put my laptop to sleep so i can keep my work open     :Sad: 

----------

## eccerr0r

What I don't understand : Where is it failing?

You mentioned it reports a problem after loading udev.  The thing that's confusing me is that the error you're implying is that it couldn't find the root partition but if it loaded udev, it indeed did.

Please post a more detailed error message and some context to the error message.

----------

## ccosse

 *eccerr0r wrote:*   

> What I don't understand : Where is it failing?
> 
> You mentioned it reports a problem after loading udev.  The thing that's confusing me is that the error you're implying is that it couldn't find the root partition but if it loaded udev, it indeed did.
> 
> Please post a more detailed error message and some context to the error message.

 

Yeah, sorry ... I'm rebuilding with CONFIG_SUSPEND=y and will install/reboot and copy the exact message from another machine ... your point makes me think that i have 2 msgs confused ... one moment please! 

Thank you!

----------

## ccosse

I remade the kernel with only CONFIG_SUSPEND=y (i.e. if I unset it will boot fine), and here is the !!error

```

>> Activating mdev

>> Loading modules

>> Hint: User parameter scandelay[=seconds] if you need waiting here

>> Determining root device ...

!! Block device /dev/sda3 is not a valid root device

!! Could not find the root block device in .

```

----------

## eccerr0r

This is implying that you're using an initramfs, did you also update the initramfs with your new kernel?

mdev is not the same as udev, mdev is the busybox "udev" that's in the initramfs to setup your disks.  If the modules in your initramfs don't match your kernel it will have a hard time getting your disks.

----------

## ccosse

 *eccerr0r wrote:*   

> This is implying that you're using an initramfs, did you also update the initramfs with your new kernel?
> 
> mdev is not the same as udev, mdev is the busybox "udev" that's in the initramfs to setup your disks.  If the modules in your initramfs don't match your kernel it will have a hard time getting your disks.

 

Yes, it's definitely updated correctly because if i remake bzImage with that single CONFIG_SUSPEND unset then works fine.  Same initramfs either way.  I dunno! ... but thanks for your continued help, eccerr0r ... both past and future  :Smile: 

----------

## eccerr0r

You need to update the initramfs when updating the kernel.  The initramfs contains modules that are only relevant to the kernel it was built with.

----------

## ccosse

 *eccerr0r wrote:*   

> You need to update the initramfs when updating the kernel.  The initramfs contains modules that are only relevant to the kernel it was built with.

 

But I only changed CONFIG_SUSPEND to built-in, not as a module, so the modules should have all been the same, no?  (I'm positive about only the one change made in .config)

----------

## eccerr0r

No. You can't always assume that.  When you rebuild the kernel a whole bunch of files got recompiled.  If you tried to make modules again, most likely you'll also rebuild a bunch of files too.  If it did rebuild files - that means the initramfs modules also need to be updated.  Try it...

----------

## ccosse

 *eccerr0r wrote:*   

> No. You can't always assume that.  When you rebuild the kernel a whole bunch of files got recompiled.  If you tried to make modules again, most likely you'll also rebuild a bunch of files too.  If it did rebuild files - that means the initramfs modules also need to be updated.  Try it...

 

okay, thank you for double-checking that reasoning for me.  I will do it but, as you know, it takes a while for the modules ... so be back soon ...

thanks eccerr0r

----------

## ccosse

 *ccosse wrote:*   

>  *eccerr0r wrote:*   No. You can't always assume that.  When you rebuild the kernel a whole bunch of files got recompiled.  If you tried to make modules again, most likely you'll also rebuild a bunch of files too.  If it did rebuild files - that means the initramfs modules also need to be updated.  Try it... 
> 
> okay, thank you for double-checking that reasoning for me.  I will do it but, as you know, it takes a while for the modules ... so be back soon ...
> 
> thanks eccerr0r

 

So i rebuilt the entire module tree and installed for the matching bzImage with CONFIG_SUSPEND set as built-in ... and no dice.  Same error after mdev. 

Afterwards I rebooted with the no-suspend bzImage and the yes-suspend module tree and did see errors about unmatched modules and kernel code ... so thank you for enlightening me about that!  

My "acpitool -s" command seems like it would work if I just had a /sys/power directory ... would CONFIG_SUSPEND even affect that?  getting /sys/power is the real problem, i guess ... would that still be a kernel issue?

----------

## eccerr0r

I feel like a broken record here...:  Did you rebuild initramfs?

The modules in your real_root /lib/modules cannot be read until after initramfs is finished.  So the modules need to exist *inside* initramfs, hence the initramfs rebuild.  I don't know the method most people use as I have my own hand-built initramfs which I (try to) carefully install needed modules within - or complete do without initramfs if possible and build all drivers statically.

----------

## ccosse

 *eccerr0r wrote:*   

> I feel like a broken record here...:  Did you rebuild initramfs?
> 
> 

 

Yes I did.  I rebuilt the module tree first, then used genkernel to build the initramfs from the installed tree matching the bzImage with CONFIG_SUSPEND set.  And same error results after mddv.

----------

## eccerr0r

When using the new initramfs did all those module version/symbol mismatches go away?

I suppose the easiest thing to do is to compile all your hardware statically "Y" into the kernel including disk drivers, filesystems, etc.  That way you won't have to deal with initramfs version problems - which is one thing I did with my custom initramfs when I really got tired of updating its modules...

----------

## ccosse

 *eccerr0r wrote:*   

> When using the new initramfs did all those module version/symbol mismatches go away?
> 
> I suppose the easiest thing to do is to compile all your hardware statically "Y" into the kernel including disk drivers, filesystems, etc.  That way you won't have to deal with initramfs version problems - which is one thing I did with my custom initramfs when I really got tired of updating its modules...

 

Yeah, all of the mismatch stuff went away as expected when i switched back ... of course the hung version never got that far, but i did everything right, procedurally ... it's just something weird ... i've never been able to get my machine to sleep since an old version with old udev ... not that it's related, just that it's been a while.  

Do you know anything about my other underlying question about how to make /sys/power directory show up?  That's what my sleep command ("acpitool -s") complains about missing.

```
vaio charlie # acpitool -s

 Function Do_Suspend : could not open file : /sys/power/state. 

 You must have write access to /sys/power/state to suspend your computer.

```

----------

