Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 224431 - Error message during boot using genkernel created initramfs
Summary: Error message during boot using genkernel created initramfs
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: x86 Linux
: Normal minor (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-06-01 03:32 UTC by Chuck Ross
Modified: 2008-06-04 01:38 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patches function swsusp_resume in /etc/inird.scripts to check for an empty variable before using it (patch.txt,635 bytes, patch)
2008-06-01 03:33 UTC, Chuck Ross
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chuck Ross 2008-06-01 03:32:01 UTC
During boot, using a genkernel created initramfs the following error is displayed:

>> Activating mdev
ls: : No such file or directory
>> Determining root device...
>> Mounting root...

the error "No such file or directory" occurs in the function "swsusp_resume" in /etc/initrd.scripts when the variable REAL_RESUME is an empty string.  The following patch adds a test to check if the variable is empty. 




--- old/etc/initrd.scripts	2008-05-31 22:41:43.000000000 -0400
+++ new/etc/initrd.scripts	2008-05-31 22:42:56.000000000 -0400
@@ -976,9 +976,11 @@
 }
 
 swsusp_resume() {
-	### determine swap resume partition
-	local device=$(ls -l "${REAL_RESUME}" | sed 's/\ */ /g' | cut -d \  -f 6-7 | sed 's/,\ */:/')
-	[ -f /sys/power/resume ] && echo "${device}" > /sys/power/resume
+	if [ ! -z "${REAL_RESUME}" ] ; then
+		### determine swap resume partition
+		local device=$(ls -l "${REAL_RESUME}" | sed 's/\ */ /g' | cut -d \  -f 6-7 | sed 's/,\ */:/')
+		[ -f /sys/power/resume ] && echo "${device}" > /sys/power/resume
+	fi
 	return 0
 }
Comment 1 Chuck Ross 2008-06-01 03:33:53 UTC
Created attachment 155057 [details, diff]
patches function swsusp_resume in /etc/inird.scripts to check for an empty variable before using it
Comment 2 Andrew Gaffney (RETIRED) gentoo-dev 2008-06-02 03:15:46 UTC
That patch is essentially a no-op. ${REAL_RESUME} is already checked in linuxrc before that function is called. What version of genkernel are you using?
Comment 3 Chuck Ross 2008-06-02 04:36:43 UTC
(In reply to comment #2)
> That patch is essentially a no-op. ${REAL_RESUME} is already checked in linuxrc
> before that function is called. What version of genkernel are you using?
> 

genkernel 3.4.9

kernel-genkernel-x86-2.6.24-gentoo-r8 and initramfs-genkernel-x86-2.6.24-gentoo-r8 built with the "genkernel all" command

This is from a fresh install of Gentoo 2008.0-beta2 into a VMWare Workstation 6.0 VM. 
Comment 4 Chuck Ross 2008-06-02 04:55:20 UTC
I found something else.  

I took a look at linuxrc and its includes and I only found two places where REAL_RESUME is set.  The first is in linuxrc where the script sets up variables based on the passed in kernel parameters.  if the "real_resume=xxx" parameter is not passed in as a kernel parameter, the REAL_RESUME variable does not get a value.

Later is in a call to startLUKS() (in etc/initrd.scripts included by linuxrc).  This is called before swsusp_resume().  Here's the relevant part:

if [ -n "${CRYPT_SWAP}" ]; then
        openLUKS "swap"
        if [ -z "${REAL_RESUME}" ]
        then
                # Resume from swap as default
                REAL_RESUME="/dev/mapper/swap"
        fi
fi

Here REAL_RESUME is initialized to "/dev/mapper/swap" if it is empty, but this check only occurs if CRYPT_SWAP is *not* an empty string.  Unfortunately CRYPT_SWAP is empty at this point (at least for me)

Finally in swssup_resume() is this line:
local device=$(ls -l "${REAL_RESUME}" | sed 's/\ */ /g' | cut -d \  -f

The ls returns "ls: : No such file or directory"

Comment 5 Andrew Gaffney (RETIRED) gentoo-dev 2008-06-03 12:10:36 UTC
I'm pretty sure this was fixed already in one of the 3.4.10_pre versions. Upgrade to the latest and check again. Reopen this bug if it's still an issue.
Comment 6 Guillaume Ramelet 2008-06-03 17:19:47 UTC
I keep it closed however 3.4.9 is considered as stable and 3.4.10 as ~.
Any plan to apply this patch to the stable version ?
Comment 7 Andrew Gaffney (RETIRED) gentoo-dev 2008-06-03 17:53:22 UTC
No
Comment 8 Chuck Ross 2008-06-04 01:38:48 UTC
Confirmed this bug does not occur in 3.4.10_pre10