[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#892407: marked as done (initramfs-tools: scripts/local: ignore /dev/ram*)

Your message dated Fri, 09 Mar 2018 23:10:50 +0000
with message-id <1520637050.2495.57.camel@decadent.org.uk>
and subject line Re: Bug#892407: initramfs-tools: scripts/local: ignore /dev/ram*
has caused the Debian Bug report #892407,
regarding initramfs-tools: scripts/local: ignore /dev/ram*
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
892407: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892407
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
On Fri, 2018-03-09 at 11:16 -0800, Kevin Hilman wrote:
> 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.

Sorry, no.  This never worked before; it was a stupid decision by
whoever did this in LAVA; and it should be fixed there.

Ben.

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

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: