Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.bugs.dist > #885933 > unrolled thread

Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

Started byKevin Hilman <khilman@baylibre.com>
First post2018-03-08 20:20 +0100
Last post2018-03-09 03:30 +0100
Articles 6 — 2 participants

Back to article view | Back to linux.debian.bugs.dist


Contents

  Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Kevin Hilman <khilman@baylibre.com> - 2018-03-08 20:20 +0100
    Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Ben Hutchings <ben@decadent.org.uk> - 2018-03-09 02:00 +0100
      Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Kevin Hilman <khilman@baylibre.com> - 2018-03-09 02:20 +0100
        Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Ben Hutchings <ben@decadent.org.uk> - 2018-03-09 03:40 +0100
          Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Kevin Hilman <khilman@baylibre.com> - 2018-03-09 20:30 +0100
      Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram* Ben Hutchings <ben@decadent.org.uk> - 2018-03-09 03:30 +0100

#885933 — Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*

FromKevin Hilman <khilman@baylibre.com>
Date2018-03-08 20:20 +0100
SubjectBug#892407: initramfs-tools: scripts/local: ignore /dev/ram*
Message-ID<vr9f4-2vP-3@gated-at.bofh.it>
Package: initramfs-tools
Version: 0.130

From a2aef0d83cd19d9b69a747c7ddbcee564faac914 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman@baylibre.com>
Date: Thu, 8 Mar 2018 11:01:38 -0800
Subject: [PATCH] scripts/local: ignore /dev/ram*

These scripts are already running in a ramdisk, so ignore
any root=/dev/ram* so we don't waste 30 sec looping.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 scripts/local | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/scripts/local b/scripts/local
index 4ec926cae6cb..103a8fffd7c7 100644
--- a/scripts/local
+++ b/scripts/local
@@ -60,6 +60,14 @@ local_device_setup()
 	local time_elapsed
 	local count
 
+	# We're already in a ramdisk, don't waste 30 sec looping waiting
+	# for /dev/ram* devices
+	expr match ${dev_id#/dev/} "ram" > /dev/null
+	if [ $? = 0 ]; then
+		echo "Ignoring ${dev_id}.  We're already in a ramdisk."
+		return 1
+	fi
+
 	wait_for_udev 10
 
 	# Load ubi with the correct MTD partition and return since fstype
-- 
2.11.0

[toc] | [next] | [standalone]


#885962

FromBen Hutchings <ben@decadent.org.uk>
Date2018-03-09 02:00 +0100
Message-ID<vrey5-5Oh-1@gated-at.bofh.it>
In reply to#885933

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 moreinfo

Are you trying to fix the LAVA health check?

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

[toc] | [prev] | [next] | [standalone]


#885963

FromKevin Hilman <khilman@baylibre.com>
Date2018-03-09 02:20 +0100
Message-ID<vreRr-6cw-1@gated-at.bofh.it>
In reply to#885962
I'm not sure exactly what you're referring to, so I guess that means no.

I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
(mistakenly) used on the command-line when passing in the debian
ramdisk.  If that happens, it eventually falls through to the
initramfs shell, but not before trying 30 times (with a "sleep 1"
between each) to find another ramdisk on /dev/ramX

On Thu, Mar 8, 2018 at 4:55 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> Control: tag -1 moreinfo
>
> Are you trying to fix the LAVA health check?
>
> Ben.
>
> --
> Ben Hutchings
> compatible: Gracefully accepts erroneous data from any source
>

[toc] | [prev] | [next] | [standalone]


#885969

FromBen Hutchings <ben@decadent.org.uk>
Date2018-03-09 03:40 +0100
Message-ID<vrg6R-72t-1@gated-at.bofh.it>
In reply to#885963

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2018-03-08 at 17:08 -0800, Kevin Hilman wrote:
> I'm not sure exactly what you're referring to, so I guess that means no.

Aren't you using LAVA in conjunction with kernelci?  That's where I've
seen this odd usage of "root=/dev/ram0" before.

> I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
> (mistakenly) used on the command-line when passing in the debian
> ramdisk.  If that happens, it eventually falls through to the
> initramfs shell, but not before trying 30 times (with a "sleep 1"
> between each) to find another ramdisk on /dev/ramX

I'm pretty sure "break" does what you need.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

[toc] | [prev] | [next] | [standalone]


#886121

FromKevin Hilman <khilman@baylibre.com>
Date2018-03-09 20:30 +0100
Message-ID<vrvSh-Xf-1@gated-at.bofh.it>
In reply to#885969
On Thu, Mar 8, 2018 at 6:37 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Thu, 2018-03-08 at 17:08 -0800, Kevin Hilman wrote:
>> I'm not sure exactly what you're referring to, so I guess that means no.
>
> Aren't you using LAVA in conjunction with kernelci?  That's where I've
> seen this odd usage of "root=/dev/ram0" before.

Yes, this came up in the contect of kernelCI.

>> I'm just trying to avoid an unnecessary delay when "root=/dev/ram*" is
>> (mistakenly) used on the command-line when passing in the debian
>> ramdisk.  If that happens, it eventually falls through to the
>> initramfs shell, but not before trying 30 times (with a "sleep 1"
>> between each) to find another ramdisk on /dev/ramX
>
> I'm pretty sure "break" does what you need.

Well, break does what you describe, but not exactly what I need.  I'm
trying to workaround the (mis)use of root=/dev/ramX on the
commandline.  If I could add stuff to the kernel command-line, I would
instead just remove the "root=/dev/ramX" rather than add
"break=premount", but I'm trying to solve the problem for LAVA labs
that we don't control, so we cannot change all the device-types out
there and remove "root=/dev/ram0".

So, back to the patch at hand...

Is there ever a usecase for the debian initrd.img to switch_root to
another initrd/ramdisk?

If so, then my proposed patch is invalid.  If not, then it's a nice
optimization and fixup for (mis)use of root=/dev/ram in conjuction
with an existing initrd/ramdisk.

Kevin

[toc] | [prev] | [next] | [standalone]


#885966

FromBen Hutchings <ben@decadent.org.uk>
Date2018-03-09 03:30 +0100
Message-ID<vrfXb-6VV-1@gated-at.bofh.it>
In reply to#885962

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2018-03-09 at 00:55 +0000, Ben Hutchings wrote:
> Control: tag -1 moreinfo
> 
> Are you trying to fix the LAVA health check?

A longer and possibly more helpful answer:

1. initramfs-tools is primarily meant for booting a "real" system.  The
"root" kernel parameter says where that system is.  It doesn't make
sense to me to overload that parameter.

2. An initramfs is not the same thing as a ramdisk.  Treating device
names matching /dev/ram* specially could possibly conflict with a
configuration where both an initramfs and a ramdisk are used.

3. There is already a way to tell initramfs-tools abort the boot
process and start a shell - the "break" parameter, documented in
initramfs-tools(8).  (Hmm, that should probably be in section 7.)

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.bugs.dist


csiph-web