Can you please join the liveid conversation where I'm proposing a change
to live-build that would probably fix your issue?
There's the long live-boot Merge Request discussion at:
https://salsa.debian.org/live-team/live-boot/-/merge_requests/52 .
Then there's the sister Merge Request on live-bui
Package: live-build
Severity: normal
X-Debbugs-Cc: safinas...@gmail.com
Current Live image (
https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-kde.iso
)
contains file /EFI/boot/grubx64.efi , which is binary identical to the file
/usr/lib/grub/x86_6
Your message dated Thu, 05 May 2022 10:34:23 +
with message-id
and subject line Bug#934701: fixed in live-boot 1:20220505
has caused the Debian Bug report #934701,
regarding live-boot: fixed handling of live media device in case of persistence
to be marked as done.
This means that you claim
Package: live-boot
Version: 1:20190614
Severity: normal
When using persistence, the live media mount point is moved from
/run/live/medium to /run/live/persistence/$something.
This is probably unintended and makes it much harder for third-party
tools to find the original live medium. The attached
Hello,
I have a question about live media encryption. live-boot has a
parameter of :
{live-media-encryption|encryption}=TYPE
live-boot will mount the encrypted rootfs TYPE, asking the
passphrase, useful to build paranoid live systems :-). TYPE supported so
far is "aes" fo
Your message dated Thu, 3 May 2018 19:41:37 +0200
with message-id <40358303-db7c-d932-d2e6-5527c5a1c...@debian.org>
and subject line Done
has caused the Debian Bug report #897585,
regarding debian-live: Please add keyutils to live media package pool
to be marked as done.
This means that you
Package: debian-live
Severity: normal
Please add keyutils to the live media package pool.
This is required for users who set up encrypted volumes and use luks keys to
either encrypt
further volumes, or when using GRUB to unlock luks from an encrypted GRUB.
Alternatively it could also be
Hi,
On Sun, 13 Nov 2016, Ronny Standtke wrote:
> Package: live-boot
> Version: 1:20160511
> Severity: normal
>
> If a preferred medium (device or medium type) is given with the
> live-media parameter then waiting for the timeout to expire before
> scanning for these dev
Package: live-boot
Version: 1:20160511
Severity: normal
If a preferred medium (device or medium type) is given with the
live-media parameter then waiting for the timeout to expire before
scanning for these devices is not necessary. Just pick the device as soon
as it appears. If a criterion would
close 598935 3.0~a5-1
thanks
--binary-pool was removed in above version, closing.
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
--
To UNSUBSCRI
Processing commands for cont...@bugs.debian.org:
> close 598935 3.0~a5-1
Bug #598935 [live-build] support using package pool of live-media
Marked as fixed in versions live-build/3.0~a5-1.
Bug #598935 [live-build] support using package pool of live-media
Marked Bug as done
> thanks
St
Your message dated Tue, 28 May 2013 06:42:53 +0200
with message-id <51a435cd.6040...@progress-technologies.net>
and subject line Re: improving live-media= to immediately detect medium
has caused the Debian Bug report #700920,
regarding improving live-media= to immediately detect medium
can you provide an updated patch for this?
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.d
Hi,
Daniel Baumann wrote (19 Feb 2013 13:21:29 GMT) :
> On 02/19/2013 01:28 PM, Ronny Standtke wrote:
>> How about a priority list, e.g.
>> "live-media=removable-usb,removable,any"
> sounds good.
Looks good to me too :)
--
To UNSUBSCRIBE, email to debian-live-req
[ do not drop the bts from CC. ]
On 02/19/2013 01:28 PM, Ronny Standtke wrote:
How about a priority list, e.g.
"live-media=removable-usb,removable,any"
sounds good.
, where "any" is a wildcard
keyword that allows booting from whatever medium is found. This way
Tails d
use case.. therefore.. if such fail-to-boot is
> desired, the parameter should be something like
> live-media=strict-removable or something like that.
>
How about a priority list, e.g.
"live-media=removable-usb,removable,any", where "any" is a wildcard
keyword that allows
On 02/19/2013 12:07 PM, intrigeri wrote:
In Tails [1], we rely on live-media=removable to avoid trusting the
content of internal drives. So it's critical for us to have live-boot
*always* obey live-media=removable.
as usual, we should allow both use cases to co-exist.
imho the de
p 17 00:00:00 2001
From: Gaudenz Steinlin
Date: Thu, 17 Jan 2013 16:45:27 +0100
Subject: [PATCH 1/2] Immediately detect medium from live-media parameter
If a preferred medium (device or medium type) is given with the
live-media parameter then waiting for the timeout to expire before
scaning for th
Hi,
Gaudenz Steinlin wrote (19 Feb 2013 10:19:30 GMT) :
> If no removable or removable-usb device is found after the timeout
> expires, just boot any live medium available instead of panicing.
In Tails [1], we rely on live-media=removable to avoid trusting the
content of internal drives. S
On 02/19/2013 11:19 AM, Gaudenz Steinlin wrote:
The attached patch implements a solution to both of these issues.
can you split it in two patches please?
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: h
Package: live-boot
Severity: wishlist
Tags: patch
If a preferred medium (device or medium type) is given with the
live-media parameter then waiting for the timeout to expire before
scaning for these devices is not necessary. Just pick the device as soon
as it appears. If a criterium would match
Hi,
Daniel Baumann wrote (03 Oct 2012 08:48:32 GMT) :
> * read-write live media be 'upgradeable' easily: a user with a big
> enough live medium can, rather than re-download and re-write an
> entirely new image, just download the partial squashfs and put
> it o
On 3 October 2012 13:44, Daniel Baumann
wrote:
> On 10/03/2012 12:47 PM, Michal Suchanek wrote:
>> How many layers would a live system with multitude of
>> squashfs images and multitude of persistence layers have?
>
> in the gnome-desktop case, that would be 3
> (base+standard+gnome-desktop), plus
Am 03.10.2012 13:44, schrieb Daniel Baumann:
On 10/03/2012 12:47 PM, Michal Suchanek wrote:
How many layers would a live system with multitude of
squashfs images and multitude of persistence layers have?
in the gnome-desktop case, that would be 3
(base+standard+gnome-desktop), plus one for pers
On 10/03/2012 12:47 PM, Michal Suchanek wrote:
> How many layers would a live system with multitude of
> squashfs images and multitude of persistence layers have?
in the gnome-desktop case, that would be 3
(base+standard+gnome-desktop), plus one for persistence (when using full
or only one-directo
Hello,
On 3 October 2012 11:10, Daniel Baumann
wrote:
> and my personal opinion is:
>
> * use use multiple squashfs images by default
Note that
1) number of layers in an overlay is limited.
That's an arbitrary limit that cnaby changed usually but something to
keep in mind. How many layers wo
On 10/03/2012 06:10 AM, Daniel Baumann wrote:
> and my personal opinion is:
>
> * use use multiple squashfs images by default
>
> * name them 'base.squashfs' plus anything on top of that based on the
> package list name
>
> * use '/live/filesystems.list' as the list of filesystems to b
and my personal opinion is:
* use use multiple squashfs images by default
* name them 'base.squashfs' plus anything on top of that based on the
package list name
* use '/live/filesystems.list' as the list of filesystems to be loaded
by live-boot.
--
Address:Daniel Baumann
mages, we could do:
/live/standard.squashfs
/live/rescue.squashfs
/live/gnome-desktop.squashfs
/live/kde-desktop.squashfs
/live/lxde-desktop.squashfs
/live/xfce-desktop.squashfs
advantages:
* read-write live media be 'upgradeable' easily: a user with a
big enough live
On 09/20/2012 05:24 PM, Steve R wrote:
> I would love to be able to contribute back to the project! But like many
> other users, I suspect my
> programming skills are hardly up to the task. That said, I am more than
> willing to put in the
> effort. Can someone guide me on where to start looking
ebian.org
> Subject: Re: Debian-live systems with encrypted live-media device - what do
> you specify for the live-media boot parameter?
>
> On 09/16/2012 05:39 AM, Steve R wrote:
> > Is there some way I can indicate to live-boot that the live-media is on
> > a LUKS
On 09/16/2012 05:39 AM, Steve R wrote:
Is there some way I can indicate to live-boot that the live-media is on
a LUKS encrypted device and needs to be decrypted first?
currently not, no.
we do support booting live images stored on an unencrypted filesystem as
well as booting live systems
(With Grub
requesting a password for the encrypted file system and parsing grub.cfg,
displaying the menu, etc.. The problem arises with the linux command to load
the kernel. Loading the Debian-live based OS requires passing a reference to
the file system hosting the file system, via the live-
> -Original Message-
> From: Daniel Baumann [mailto:daniel.baum...@progress-technologies.net]
> Sent: Monday, April 30, 2012 2:14 PM
> To: debian-live@lists.debian.org
> Subject: Re: [PATCH] Allow live media volume to host persistence
>
> On 04/30/2012 10:59 AM, Ia
On 04/30/2012 10:59 AM, Ian Geiser wrote:
I always had my live-rw file at the root of the usb key. [...] Now I am not
sure if there is a design consideration to forbid using the live media as a
persistence backing, but here is the patch anyway to kickstart that discussion.
While it&#
sure if there is a
design consideration to forbid using the live media as a persistence backing,
but here is the patch anyway to kickstart that discussion. So far I have only
tested this with custom-ov and live-sn.cpio.g and they both work just fine.
Thanks!
0001-Added-the-ability-to-use
Your message dated Sat, 02 Oct 2010 09:02:39 +
with message-id
and subject line Bug#598536: fixed in live-config 3.0~a9-1
has caused the Debian Bug report #598536,
regarding live-config: config.d/ config files not parsed on live media
to be marked as done.
This means that you claim that the
Your message dated Sat, 02 Oct 2010 08:36:05 +
with message-id
and subject line Bug#598536: fixed in live-config 2.0.8-1
has caused the Debian Bug report #598536,
regarding live-config: config.d/ config files not parsed on live media
to be marked as done.
This means that you claim that the
Processing commands for cont...@bugs.debian.org:
> tag 598536 pending
Bug #598536 [live-config] live-config: config.d/ config files not parsed on
live media
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
598536: http://bugs.debian.o
tag 598536 pending
thanks
On 09/29/2010 10:09 PM, Scott Barker wrote:
> There is a typo in /lib/live/config.sh
> The attached patch should fix the problem.
aplied in git, thanks.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baum...@panthera-syst
Package: live-config
Version: 3.0~a8-1
Severity: normal
Tags: patch
There is a typo in /lib/live/config.sh
The attached patch should fix the problem.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (900, 'testing'), (700, 'experimental')
Architecture: amd64
On 04/14/2010 03:44 PM, Ronny Standtke wrote:
I patched live-initramfs so that the value for the live-media option can
now be an ordered comma separated list and also added support for the
value "usb" which accepts all usb devices.
nice.
I also fixed some smaller
things like correc
dy switched to 4k or will switch in near future...
The only way to use these newer hard drives for Debian Live is to put
the livefs and persistency on the drive, boot from a Debian Live DVD and
let live-initramfs pick up the partitions on the hard drive.
Unfortunately, the live-initramfs option "
Your message dated Mon, 15 Mar 2010 07:04:29 +0100
with message-id <4b9dcded.3060...@debian.org>
and subject line Re: live-initramfs: live-media=removable does not work as
advertised,version graph
has caused the Debian Bug report #568750,
regarding live-initramfs: live-media=removable do
Hi,
I RFC for a boot parameter that I am about implementing:
live-media=only=udev=
where is the part of an udev/rule that do
selection of a /sys/ device.
It gives the user full control of which usb partition should hold live/
; more or less fine grained criteria can be used.
Threafter
intrigeri wrote:
Hi,
Philippe Lelédy wrote (08 Feb 2010 08:51:57 GMT) :
This solve the general issue that any live-media= cheatcode is
ineffective for USB
because find_livefs() starts before USB is ready ( BTW, I happily use
usb-storage.delay_use=1 kernel parameter which gains 4s over the
Hi,
Philippe Lelédy wrote (08 Feb 2010 08:51:57 GMT) :
> I am interested in this issue, although it was not for the same
> reason, but for speeding up boot-time.
I discovered this issue while trying to speed boot time up as well:
I removed the live-media-timeout=15 I was using previousl
uot;AA04012700341377",
NAME="-USB/$attr{manufacturer}-$attr{product}-%n"
and have a very very simple and fast find_livefs() starting with
mkdir -p /dev/-USB && notifywait /dev/-USB && mount
with would fail should the right USB key not be found.
This solve t
Processing commands for cont...@bugs.debian.org:
> tag 568750 - security
Bug #568750 [live-initramfs] live-initramfs: live-media=removable does not work
as advertised
Removed tag(s) security.
> tag 568750 pending
Bug #568750 [live-initramfs] live-initramfs: live-media=removable does not wo
tag 568750 - security
tag 568750 pending
thanks
intrig...@boum.org wrote:
> The *only* part of the specification is pretty important when some
> high degree of trust has to be put into a Live system:
ack.
> This is why I set the security tag to this bug, which might be disputable.
imho, the tag
Package: live-initramfs
Version: 1.173.1-1
Severity: normal
Tags: security, patch
Hi,
The manpage section about the live-media= boot parameter states
that
the keyword 'removable' can be used to limit the search of
acceptable live media to removable type only.
The *only* p
Your message dated Sun, 18 Oct 2009 19:17:54 +
with message-id
and subject line Bug#534878: fixed in live-initramfs 1.157.4-1
has caused the Debian Bug report #534878,
regarding live-initramfs: live-media-path and toram don't play well together
to be marked as done.
This means that you
tag 534878 pending
thanks
Applied in git, sorry for the delay, and thank you for bringing it up
and fixing it.
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baum...@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-ba
Processing commands for cont...@bugs.debian.org:
> tag 534878 pending
Bug #534878 [live-initramfs] live-initramfs: live-media-path and toram don't
play well together
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug trac
Hi again!
I am trying to boot a live usb memory stick on a system that has a live image
installed on its solid state drive.
In order to prevent live-initramfs to use the image on the SSD, I have used
LH_BOOTAPPEND_LIVE="live-media=removable-usb nopersistent"
when I built the OS on
Package: live-initramfs
Version: 1.157.2-1
Severity: normal
Tags: patch
The function copy_live_to in scripts/live doesn't take the boot parameter
live-media-path into account, resulting in trying to copy the whole hard disk
to ram in my case. Attached a patch which should fix the pr
2009/2/19 Sebastian Hilbert :
> On Montag 16 Februar 2009, Chris Lamb wrote:
>> Sebastian Hilbert wrote:
>> > I have a dedicated server that could server for development purposes.
>>
>> That's very kind of you, however the machine would be for significantly
>> more than mere "development"; it would
Sebastian Hilbert wrote:
> How much traffic is estimated ? A root server for 49 Euro/months in Germany
> has 1TB free traffic at 100Mbit and drops to 10MBit for unlimited traffic.
we had nearly 2tb/month in the beginning where live-webhelper was
available for a while. not much more my ds5000 (whe
On Montag 16 Februar 2009, Chris Lamb wrote:
> Sebastian Hilbert wrote:
> > I have a dedicated server that could server for development purposes.
>
> That's very kind of you, however the machine would be for significantly
> more than mere "development"; it would be a public service for building
> i
On Mittwoch 18 Februar 2009, Sebastian Hilbert wrote:
hetzner.de does not itself not in a position to sponsor traffic and bandwidth.
--
Sebastian Hilbert
Leipzig / Germany
[www.gnumed.de] -> PGP welcome, HTML ->/dev/null
--
To UNSUBSCRIBE, email to debian-live-requ...@lists.debian.org
with
Chris Lamb wrote:
> Sure, but uploading images in the size order of ~1GB to anywhere takes
> time and bandwidth. In particular, SourceForge is a terrible enterprise
> and I would not like to rely on their services nor have a project
> affiliated with them.
sourceforge may be an option for other pe
On Mittwoch 18 Februar 2009, Chris Lamb wrote:
> Sebastian Hilbert wrote:
> > I don't fully understand your point yet. Most of the bandwidth will be
> > consumed by downloading prepared images.
>
> Sure, but uploading images in the size order of ~1GB to anywhere takes
> time and bandwidth. In parti
Sebastian Hilbert wrote:
> I don't fully understand your point yet. Most of the bandwidth will be
> consumed by downloading prepared images.
Sure, but uploading images in the size order of ~1GB to anywhere takes
time and bandwidth. In particular, SourceForge is a terrible enterprise
and I would
On Montag 16 Februar 2009, Chris Lamb wrote:
> Sebastian Hilbert wrote:
> > I have a dedicated server that could server for development purposes.
>
> That's very kind of you, however the machine would be for significantly
> more than mere "development"; it would be a public service for building
> i
Daniel Baumann wrote:
> when i'll find after the whole lenny upgrade circus, i'll ping nine.ch
> again, they would offer to host a machine. if the machine they would be
> providing itself is not decent enough, i'd be willing to use my own
> hardware for that.
You're officially awesome. Okay, I'll
Sebastian Hilbert wrote:
> I have a dedicated server that could server for development purposes.
That's very kind of you, however the machine would be for significantly
more than mere "development"; it would be a public service for building
images.
> > * Large amount of bandwidth for downloads
Chris Lamb wrote:
> I believe this last requirement would rule out the use of any DSA-maintained
> machines. If anyone has any ideas, please let me know.
when i'll find after the whole lenny upgrade circus, i'll ping nine.ch
again, they would offer to host a machine. if the machine they would be
p
Hi Sebastian,
> Take a look at
> http://bornkessel.com/kesselblog/?p=30
>
> given that I am constantly trying to keep up with providing recent
> versions of GNUmed as live media let me compare the solutions for openSUSE
> and Debian
I found your comparison intriguing. First,
Tzafrir Cohen wrote:
> What about dependencies of those packages? Should they be manuall added
> to the list of packages to install?
if they are either resolvable in debian, or if they are resolvable
within the local packages, then no dependencies have to be added to the
package list - they will b
Tzafrir Cohen wrote:
> Is this an official or semi-official location?
official for my unofficial repositories :)
--
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baum...@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-
On Fri, Feb 13, 2009 at 04:31:45PM +0100, Daniel Baumann wrote:
> Sebastian Hilbert wrote:
> > non-standard repositories
> > openSUSE: all packages in openSUSE buildservice can be included
> > Debian: a custom sources list for apt needs to be carefully crafted
>
> as someone else already explained
On Fri, Feb 13, 2009 at 04:10:46PM +0100, Daniel Baumann wrote:
> Tzafrir Cohen wrote:
> > Is there an automated way to get the public key for the repository
> > from a repository URL? If so, those steps could be automated.
>
> for 'my' repositories, you actually can. i always put a file
> 'ar
Sebastian Hilbert wrote:
> non-standard repositories
> openSUSE: all packages in openSUSE buildservice can be included
> Debian: a custom sources list for apt needs to be carefully crafted
as someone else already explained, actually creating a repository is
very easy. if you don't want to do that,
Tzafrir Cohen wrote:
> Is there an automated way to get the public key for the repository
> from a repository URL? If so, those steps could be automated.
for 'my' repositories, you actually can. i always put a file
'archive-key.asc' in the root directory of the repository that contains
the cur
On Fri, Feb 13, 2009 at 01:46:12PM +0100, Andreas Tille wrote:
> On Fri, 13 Feb 2009, Sebastian Hilbert wrote:
> >non-standard repositories
> >openSUSE: all packages in openSUSE buildservice can be included
> >Debian: a custom sources list for apt needs to be carefully crafted
>
> ???
> I've thou
On Fri, 13 Feb 2009 13:15:19 +0100, Sebastian Hilbert wrote:
> Hi all,
Hello Sebastian,
> [..]
>
> backend
> openSUSE : kiwi
> Debian: Live-helper
>
> both are script based available for the command line. live-helper has been a
> moving target for me. I have not tried kiwi in a while. This r
On Fri, 13 Feb 2009, Sebastian Hilbert wrote:
backend
openSUSE : kiwi
Debian: Live-helper
both are script based available for the command line. live-helper has been a
moving target for me. I have not tried kiwi in a while. This reflects my
personal very biased view and I am looking for comments
Hi all,
Take a look at
http://bornkessel.com/kesselblog/?p=30
given that I am constantly trying to keep up with providing recent versions of
GNUmed as live media let me compare the solutions for openSUSE and Debian
backend
openSUSE : kiwi
Debian: Live-helper
both are script based available
On Sunday 07 December 2008, 05:50:54, T o n g wrote:
> What's the default scan order to find the device that contains the "/
> live" directory?
Alphabetic, based on /sys/block/ directory listing.
> I hope it always search HD first, so that the copy found on the fast HD
> would be used instead of
sane
> default and offer (almost) any other behaviour as optional boot
> parameters.
Yes, '{live-media|bootfrom}=DEVICE' to be exactly.
--
Tong (remove underscore(s) to reply)
http://xpt.sourceforge.net/techdocs/
http://xpt.sourceforge.net/tools/
--
To UNSUBSCRIBE, email to [E
[EMAIL PROTECTED] wrote:
> Right. The point I was trying to make is that there is no Right Way to
> scan the media. There might be a sane default (actually "fastest first"
> might be a good sane default), but I see some need for a way to choose
> another at (boot|config) time.
to avoid any further
Hi.
[EMAIL PROTECTED] wrote (08 Dec 2008 04:28:00 GMT) :
> Right. The point I was trying to make is that there is no Right Way to
> scan the media. There might be a sane default (actually "fastest first"
> might be a good sane default), but I see some need for a way to choose
> another at (boot|co
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Dec 07, 2008 at 06:28:38PM +, T o n g wrote:
> On Sun, 07 Dec 2008 10:57:46 +0100, Ronny Standtke wrote:
>
> > My use case looks a little different: My users
[...]
> Yes, that's the scan order that Slax uses too. I like it, 'cause
> faster
On Sun, 07 Dec 2008 10:57:46 +0100, Ronny Standtke wrote:
> My use case looks a little different: My users
> (http://www.imedias.ch/lernstick) have both a live DVD and a USB flash
> drive. Whenever possible (i.e. the BIOS of the machine in front of you
> permits) they boot from USB flash drive. Un
Hi,
> So what was my lesson from there? I think the sanest scan order would
> be to try first the media which we just "booted from", meaning where we
> got the initrd (and/or the kernel) from. But I have no clue how to find
> out that (the kernel should know though). And still, this won't cover
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Dec 07, 2008 at 04:50:54AM +, T o n g wrote:
> Hi,
>
> What's the default scan order to find the device that contains the "/
> live" directory?
>
> I hope it always search HD first, so that the copy found on the fast HD
> would be used i
Hi,
What's the default scan order to find the device that contains the "/
live" directory?
I hope it always search HD first, so that the copy found on the fast HD
would be used instead of slow CD or USB.
thanks
--
Tong (remove underscore(s) to reply)
http://xpt.sourceforge.net/techdocs/
On Sunday 23 November 2008, 22:21:09, Daniel Baumann wrote:
> + # Eject live media
> + if [ -x /bin/eject ] && [ "${NOEJECT}" != "Yes" ]
> + then
> + eject ${dev}
> + fi
> +
> or is the live-media used for an
port NOFASTBOOT
@@ -662,6 +667,12 @@ copy_live_to ()
mount -r -o move ${copyto} ${copyfrom}
fi
+ # Eject live media
+ if [ -x /bin/eject ] && [ "${NOEJECT}" != "Yes" ]
+ then
+ eject ${dev}
+ fi
+
rmdi
89 matches
Mail list logo
