:11): avc: denied
{ getattr } for pid=3104 comm="daemon-init"
path="/home/bcv/.thunderbird" dev="dm-5" ino=257
scontext=system_u:system_r:virtd_t:s0
tcontext=system_u:object_r:thunderbird_home_t:s0 tclass=lnk_file
permissive=0
I am not sure why on earth
comm="daemon-init" path="/home/bcv/.thunderbird"
dev="dm-5" ino=257 scontext=system_u:system_r:virtd_t:s0
tcontext=system_u:object_r:thunderbird_home_t:s0 tclass=lnk_file
permissive=0
I am not sure why on earth would daemon-init try to read .thunderbird
directory
You might have better luck asking on debian-cloud:
https://lists.debian.org/debian-cloud/
On December 19, 2020 4:31:22 PM CST, James Allsopp
wrote:
>Hi,
>Does anyone have an example or tutorial for using cloud-init with
>debian
>images. I'm currently trying to do terraf
Hi,
Does anyone have an example or tutorial for using cloud-init with debian
images. I'm currently trying to do terraform with kvm, but struggling as
although terraform picks up the cloud-init, the fqdn and the ssh key isn't
working. I'm trying to use this image
https://cdimage.deb
Quoting Mark Raynsford (2020-02-22 17:38:20)
> 'Ello.
>
> On 2020-02-22T17:32:59 +0100
> Jonas Smedegaard wrote:
> >
> > Maybe you have... held broken packages?
> >
> > If you use aptitude instead of apt, then you can step through more
> > options, including options involving downgrading (which
On Sat, Feb 22, 2020 at 04:51:01PM +, Mark Raynsford wrote:
> On 2020-02-22T17:39:15 +0100
> to...@tuxteam.de wrote:
> >
> > Not all is lost [...]
> Thanks! I was about to try that, but it seems that aptitude found an
> alternative solution. Firstly, "# aptitude install chromium" said:
Great
thing else,
> that might work.
>
> Cheers
> -- t
Thanks! I was about to try that, but it seems that aptitude found an
alternative solution. Firstly, "# aptitude install chromium" said:
The following packages have unmet dependencies:
runit-init : Conflicts: systemd-sysv
On Sat, Feb 22, 2020 at 04:24:01PM +, Mark Raynsford wrote:
> On 2020-02-22T17:08:48 +0100
> wrote:
> > I had a similar situation with firefox wanting to install systemd.
> >
> > Just for kicks, try
> >
> > apt install chromium sysvinit-core
> >
> > If that works, you'd perhaps want to ad
'Ello.
On 2020-02-22T17:32:59 +0100
Jonas Smedegaard wrote:
>
> Maybe you have... held broken packages?
>
> If you use aptitude instead of apt, then you can step through more
> options, including options involving downgrading (which is unsupported
> by Debian, but since your system is already
Hi Mark,
Quoting Mark Raynsford (2020-02-22 17:24:01)
> On 2020-02-22T17:08:48 +0100
> wrote:
> > I had a similar situation with firefox wanting to install systemd.
> >
> > Just for kicks, try
> >
> > apt install chromium sysvinit-core
> >
> > If that works, you'd perhaps want to adapt your
On 2020-02-22T17:08:48 +0100
wrote:
> I had a similar situation with firefox wanting to install systemd.
>
> Just for kicks, try
>
> apt install chromium sysvinit-core
>
> If that works, you'd perhaps want to adapt your apt-preferences
> (either pushing sysvinit-core or lowering systemd).
>
On Sat, Feb 22, 2020 at 04:02:16PM +, Mark Raynsford wrote:
> Hello!
>
> Attempting to install chromium results in the following:
>
> # apt install chromium
I had a similar situation with firefox wanting to install systemd.
Just for kicks, try
apt install chromium sysvinit-core
If that
libunicode-string-perl xml-twig-tools nvidia-vdpau-driver
nvidia-legacy-340xx-vdpau-driver nvidia-legacy-304xx-vdpau-driver
The following packages will be REMOVED:
runit-init
The following NEW packages will be installed:
adwaita-icon-theme at-spi2-core chromium chromium-common chromium-sandbox
> On Jun 27, 2019, at 12:42 AM, Rick Thomas wrote:
>
>
>
>> On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote:
>>
>> Seems this would work as well, with less collateral damage:
>>
>> apt install -y sysvinit-core elogind
>> apt --purge autoremove
>>
>
> This works great and, as noted,
> On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote:
>
> Seems this would work as well, with less collateral damage:
>
> apt install -y sysvinit-core elogind
> apt --purge autoremove
>
This works great and, as noted, is far more elegant.
Thanks, Jonas!
Rick
Quoting Rick Thomas (2019-06-26 09:13:37)
> Hi Jonas,
>
> > On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote:
> >
> > Would be helpful to know if those experiencing long pause in
> > dbus-depending environments had _no_ dbus installed (and actively
> > running) or had it running with elogi
Hi Jonas,
> On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard wrote:
>
> Would be helpful to know if those experiencing long pause in
> dbus-depending environments had _no_ dbus installed (and actively
> running) or had it running with elogind.
How can I tell which situation I have?
Thanks!
Ric
; switching a Debian buster system from systemd to sysv init.
> >
> > The short version [1]:
> >
> > apt-get install -y sysvinit-core
>
> So our goal is to start with a working Debian buster system with the
> Mate desktop using the systemd init, and convert
Rick Thomas wrote:
>
> In any case, the solution I came up with is
>
> apt-get --purge install -y sysvinit-core dbus- glib-networking-
> libgtk-3-0-
> apt-get --purge autoremove
>
> Note the trailing minus-signs on dbus- glib-networking- libgtk-3-0- These
> packages need to be delete
> On Jun 23, 2019, at 2:24 AM, to...@tuxteam.de wrote:
>
> On Sat, Jun 22, 2019 at 05:45:39PM -0700, Rick Thomas wrote:
>>
>> Purely out of curiosity, I'd like to see what's involved in
>> switching a Debian buster system from systemd to sysv init.
>
> On Jun 23, 2019, at 2:24 AM, to...@tuxteam.de wrote:
>
> On Sat, Jun 22, 2019 at 05:45:39PM -0700, Rick Thomas wrote:
>>
>> Purely out of curiosity, I'd like to see what's involved in
>> switching a Debian buster system from systemd to sysv init.
>
On Sun, 23 Jun 2019, Bob Bernstein wrote:
How should I approach this change with an eye to maximum
safety?
Again, the wiki proved spot on:
https://wiki.debian.org/systemd#Installing_and_Testing
Sorry about the false alarm.
Thank you
--
These are not the droids you are looking for.
On Sun, 23 Jun 2019 14:55:58 -0400
Bob Bernstein wrote:
> I encountered an error during the install of a deb which
> led me to the discovery that my current init system is
> still sysvinit.
>
> The error was:
>
> /sbin/init: invalid option -- '-'
> Usage
I encountered an error during the install of a deb which
led me to the discovery that my current init system is
still sysvinit.
The error was:
/sbin/init: invalid option -- '-'
Usage: init {-e VAR[=VAL] | [-t SECONDS]
{0|1|2|3|4|5|6|S|s|Q|q|A|a|B|b|C|c|U|u}}
Thanks to the wi
On Sun, Jun 23, 2019 at 01:27:08PM +0200, arne wrote:
>
> > That's right. "Modern" desktop environments (Gnome and derivatives,
> > most probably also KDE) depend these days on systemd. I don't know
> > how hard those dependencies are -- you'd want to look at Devuan [2]
> > [3] to see how far they
> That's right. "Modern" desktop environments (Gnome and derivatives,
> most probably also KDE) depend these days on systemd. I don't know
> how hard those dependencies are -- you'd want to look at Devuan [2]
> [3] to see how far they went, if at all, into fixing this.
The Devuan default desktop
On Sat, Jun 22, 2019 at 05:45:39PM -0700, Rick Thomas wrote:
>
> Purely out of curiosity, I'd like to see what's involved in
> switching a Debian buster system from systemd to sysv init.
The short version [1]:
apt-get install -y sysvinit-core
> Please, I don't want
Purely out of curiosity, I'd like to see what's involved in switching a Debian
buster system from systemd to sysv init. Please, I don't want to restart or get
involved in any of the existing systemd/sysv flame wars. I'm *just curious* to
see if it would work?
First
#x27;s migration to testing.
>
> A grave bug in the testing version of module-init-tools (3.12~pre2-1)
> was fixed several weeks ago, and the package was uploaded with
> urgency=high:
>
> module-init-tools (3.12~pre2-2) unstable; urgency=high
>
>* Fixed an init scripts d
Hi Reco,
On 02/14/18 14:55, Reco wrote:
True. There's one tiny bit though - try
pidof -o %PPID -x /usr/sbin/sshd
and watch it output several pids as well.
Yes, indeed. If pidofproc would rely upon the pidfile only, then
there is no reason to call pidof.
And you don't have to spawn yet ano
Hi.
On Wed, Feb 14, 2018 at 02:33:16PM +0100, Harald Dunkel wrote:
> Hi Reco,
>
> wrt "pgrep --ns 1 -f /usr/sbin/sshd":
>
> The executable path simply doesn't tell if this is the right service
> to stop. If I run 2 services in parallel (e.g. for different network
> interfaces), then this
Hi Reco,
wrt "pgrep --ns 1 -f /usr/sbin/sshd":
The executable path simply doesn't tell if this is the right service
to stop. If I run 2 services in parallel (e.g. for different network
interfaces), then this approach is already broken. Sample:
# pgrep --ns 1 -f /usr/sbin/sshd
12602
# ps -ef | g
Hi.
On Mon, Feb 05, 2018 at 04:04:37PM +0100, Harald Dunkel wrote:
> Hi Reco,
>
> you mean this is a known issue???
Well, it's known to me (since then) at least as I merely read the
contents of /lib/lsb/init-functions in my Debian system.
Pinpointing the problem is easy,
Hi Reco,
you mean this is a known issue???
Harri
Hi.
On Fri, Feb 02, 2018 at 11:35:04AM +0100, Harald Dunkel wrote:
> Hi folks,
>
> I see a weird effect of pidofproc (defined in /lib/lsb/init-functions):
> If there is no local daemon with a given search path running, then it
> returns the PIDs the daemons running in the
Hi folks,
I see a weird effect of pidofproc (defined in /lib/lsb/init-functions):
If there is no local daemon with a given search path running, then it
returns the PIDs the daemons running in the LXC containers. AFAICT this
affects the startup scripts of
apache2
opensmtpd
Jonathan de Boyne Pollard wrote:
> Sven Hartge:
>> systemd happily runs "legacy" LSB init scripts
>>
> ... except when its one-size-fits-all approach does not work, of
> course. Example:
> * https://unix.stackexchange.com/questions/386846/
> This is the
Sven Hartge:
systemd happily runs "legacy" LSB init scripts
... except when its one-size-fits-all approach does not work, of
course. Example:
* https://unix.stackexchange.com/questions/386846/
This is the problem with even Mewburn rc scripts (as I can attest from
personal exp
Tom Browder:
# systemctl enable postfix # systemctl daemon-reload
Minor note: enable incorporates a daemon-reload.
Christian Seiler wrote:
> Now, that doesn't mean that you should still write _new_ init scripts
> for custom services if you're going to use systemd anyway. There it
> will be a good idea to learn how to do that with native systemd
> service units.
Exactly.
I was able
Am 2017-08-21 11:52, schrieb Tom Browder:
On Mon, Aug 21, 2017 at 02:36 Sven Hartge wrote:
Question: Why do you want to manually replace the init-script from
postfix in Jessie with a systemd.unit? What do you want to
accomplish by
doing so (other than creating a possible broken system)?
I
e convoluted handling that I haven't
>>> figured out yet. Surely some expert can write a postfix.service
>>> file that drives postfix commands.
>> Question: Why do you want to manually replace the init-script from
>> postfix in Jessie with a systemd.unit? What do you w
figured
> > out yet. Surely some expert can write a postfix.service file that
> > drives postfix commands.
...
> Question: Why do you want to manually replace the init-script from
> postfix in Jessie with a systemd.unit? What do you want to accomplish by
> doing so (other than
fix-instance-generator" which creates
new instances on the fly, based on the output of "postmulti -l -a".
I don't know if you could transplant this mechanism from postfix3
(version in Stretch) to postfix2 (version in Jessie).
Question: Why do you want to manually replace the in
On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
> Tom Browder wrote:
>
> > The contents of the postfix.service file are;
>
...
> That unit file does effectivly nothing. It just starts "/bin/true" and
> exits.
>
> What it *not* does is starting postfix in any way.
>
> This looks like there shou
On Sun, Aug 20, 2017 at 12:30 Sven Hartge wrote:
> Tom Browder wrote:
>
> > The contents of the postfix.service file are;
>
...
>
> That unit file does effectivly nothing. It just starts "/bin/true" and
> exits.
>
> What it *not* does is starting postfix in any way.
...
> .
> Are you sure you
Tom Browder wrote:
> The contents of the postfix.service file are;
> [Unit]
> Description=Postfix Mail Transport Agent
> Conflicts=sendmail.service exim4.service
> ConditionPathExists=/etc/postfix/main.cf
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecReload=/bin/t
On Sun, Aug 20, 2017 at 11:41 AM, Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
>> So "disabled" is normal?
>
> Indeed. See:
>
> https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/ch-Services_and_Daemons.html#s3-services-configuration-enabling
I d
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> So "disabled" is normal?
Indeed. See:
https://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/ch-Services_and_Daemons.html#s3-services-configuration-enabling
Regards,
--
Nicolas George
signature.asc
Description: Digital s
On Sun, Aug 20, 2017 at 10:17 AM, Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
>> > # systemctl start postfix
>> > # systemctl status postfix
>> >
>> > and got several lines basically saying posfix.service was disabled.
>
>> The exact message is:
>>
>> * postfi
On Sun, Aug 20, 2017 at 10:17 Nicolas George wrote:
> Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> > > # systemctl start postfix
> > > # systemctl status postfix
> > >
> > > and got several lines basically saying posfix.service was disabled.
>
> > The exact message is:
> >
> > * po
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> > # systemctl start postfix
> > # systemctl status postfix
> >
> > and got several lines basically saying posfix.service was disabled.
> The exact message is:
>
> * postfix.service - Postfix Mail Transport Agent
>Loaded: loaded (/etc
Le tridi 3 fructidor, an CCXXV, Tom Browder a écrit :
> I got a postfix.service file from a postfix developer and installed it in
> /etc/systemd/system as the docs mention.
>
> I then moved the /etc/init.d/postfix file away, reloaded the systemd
> daemon, and did:
>
> # systemctl start postfix
On Sun, Aug 20, 2017 at 9:42 AM, Tom Browder wrote:
> I got a postfix.service file from a postfix developer and installed it in
> /etc/systemd/system as the docs mention.
>
> I then moved the /etc/init.d/postfix file away, reloaded the systemd daemon,
> and did:
>
> # systemctl start postfix
>
I got a postfix.service file from a postfix developer and installed it in
/etc/systemd/system as the docs mention.
I then moved the /etc/init.d/postfix file away, reloaded the systemd
daemon, and did:
# systemctl start postfix
# systemctl status postfix
and got several lines basically saying
does *not* have systemd
unit files, it falls back to the sysvinit scripts.
Thanks Greg
That makes sense. Does this mean init will disappear from Debian in a
future release?
It is interesting that you gave ssh as an example because we seem to
have encountered strange problems with mixed IDE
On Mon, Sep 12, 2016 at 07:32:52PM +0100, Clive Menzies wrote:
> However, studying documentation on systemd v init, I'm a bit confused. I
> assumed the reinstall would implement systemd for all services and init
> wouldn't be visible although symlinks will use init where ne
espect of mounting the shares but one works,
one doesn't.
As server_U is working after reinstallation, following much
exploration, we reinstalled jessie 8.3 on server_M and committed to
systemd to avoid potential progressive sysv-init problems we'd
learned of during our investigation
On Sun, 17 Jan 2016 11:26:54 +0100
Aldo Maggi wrote:
> Yesterday while updating my system via dselect (I'm using testing)
> I've received the warning that "init and systemd-sysv" were going to
> be uninstalled and I had to approve or deny that action.
You have to be
On Sun, 17 Jan 2016 12:00:02 +0100, Aldo Maggi wrote:
> Yesterday while updating my system via dselect (I'm using testing) I've
> received the warning that "init and systemd-sysv" were going to be
> uninstalled and I had to approve or deny that action.
> I've
Yesterday while updating my system via dselect (I'm using testing) I've
received the warning that "init and systemd-sysv" were going to be
uninstalled and I had to approve or deny that action.
I've thought that as in previous cases (to be frank not recently but
ma
Yesterday while updating my system via dselect (I'm using testing) I've
received the warning that "init and systemd-sysv" were going to be
uninstalled and I had to approve or deny that action.
I've thought that as in previous cases (to be frank not recently but
ma
wrote:
>>
>> As a next step, I made the /etc/init.d/test-script file executable and
>> added a symlink to /etc/rc3.d/("ln -s ../init.d/test-script
>> /etc/rc3.d/S23test-script") directory and changed my runlevel from
>> 2(default) to 3 with "init 3&quo
On 2015-08-31, wrote:
>
>> I understand the whole "oh noes, firmware is a binary blob with unknown
>> contents [...]
>
> It seems you don't :-)
>
>> By not installing the firmware package, you are just making your life
>> harder without gaining anything but a delayed boot.
>
> There sure should b
On Mon, 31 Aug 2015 11:56:09 +0300
Reco wrote:
> > there's this in dmesg:
> >
> > [6.210098] EXT4-fs (sda7): mounted filesystem with ordered data mode.
> > Opts:
> > (null)
> > [ 35.827945] r8169 :03:00.0: firmware: failed to load
> > rtl_nic/rtl8168f-1.fw (-2)
> > [ 35.827963] r8
On Mon 31 Aug 2015 at 11:56:09 +0300, Reco wrote:
> On Sun, Aug 30, 2015 at 06:58:10AM -0700, bri...@aracnet.com wrote:
> >
> > there's this in dmesg:
> >
> > [6.210098] EXT4-fs (sda7): mounted filesystem with ordered data mode.
> > Opts:
> > (null)
> > [ 35.827945] r8169 :03:00.0: f
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 31, 2015 at 11:56:09AM +0300, Reco wrote:
> Hi.
>
> On Sun, Aug 30, 2015 at 06:58:10AM -0700, bri...@aracnet.com wrote:
[...]
> > so it is the dreaded r8169 firmware crappola. the system works fine not
> > loading it.
>
> My-my. Call
Hi.
On Sun, Aug 30, 2015 at 06:58:10AM -0700, bri...@aracnet.com wrote:
> On Sun, 30 Aug 2015 13:18:19 +0200
> Sven Hartge wrote:
>
> > bri...@aracnet.com wrote:
> > > On Sun, 30 Aug 2015 04:25:36 +0200 Sven Hartge wrote:
> > >> bri...@aracnet.com wrote:
> >
> > >>> There's no way anyone can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Aug 31, 2015 at 12:39:14AM +0200, Sven Hartge wrote:
> bri...@aracnet.com wrote:
>
> > [6.210098] EXT4-fs (sda7): mounted filesystem with ordered data mode.
> > Opts:
> > (null)
> > [ 35.827945] r8169 :03:00.0: firmware: failed to
bri...@aracnet.com wrote:
> [6.210098] EXT4-fs (sda7): mounted filesystem with ordered data mode.
> Opts:
> (null)
> [ 35.827945] r8169 :03:00.0: firmware: failed to load
> rtl_nic/rtl8168f-1.fw (-2)
> [ 35.827963] r8169 :03:00.0: Direct firmware load failed with error -2
> [
On Sun, 30 Aug 2015 13:18:19 +0200
Sven Hartge wrote:
> bri...@aracnet.com wrote:
> > On Sun, 30 Aug 2015 04:25:36 +0200 Sven Hartge wrote:
> >> bri...@aracnet.com wrote:
>
> >>> There's no way anyone can help until i can get a trace of what's
> >>> going on at boot.
> >>
> >> Jessie or newer?
bri...@aracnet.com wrote:
> On Sun, 30 Aug 2015 04:25:36 +0200 Sven Hartge wrote:
>> bri...@aracnet.com wrote:
>>> There's no way anyone can help until i can get a trace of what's
>>> going on at boot.
>>
>> Jessie or newer? With systemd?
>>
>> systemd-analyze blame
> 29.597s network
On Sun, 30 Aug 2015 04:25:36 +0200
Sven Hartge wrote:
> bri...@aracnet.com wrote:
>
> > it almost looks like something is timing out, and yet the system works
> > fine, so whatever it is that the process is waiting on it doesn't seem
> > to matter.
>
> > i have a bad feeling it's the dreade eth
bri...@aracnet.com wrote:
> it almost looks like something is timing out, and yet the system works
> fine, so whatever it is that the process is waiting on it doesn't seem
> to matter.
> i have a bad feeling it's the dreade ethernet firmware loading thing
> (just a guess) since that's the message
it almost looks like something is timing out, and yet the system works fine, so
whatever it is that the process is waiting on it doesn't seem to matter.
i have a bad feeling it's the dreade ethernet firmware loading thing (just a
guess) since that's the message that comes up immediately after th
Stuart Longland:
> I've used the OpenVPN init script as a template for creating my init
scripts, [...]
And that's the point at which you went wrong. OpenVPN was one of the
earliest things converted to systemd with its service management set up
very differently to the way that
Hi Stuart,
Am 20.08.2015 um 23:48 schrieb Stuart Longland:
> I've used the OpenVPN init script as a template for creating my init
> scripts, which allows me to not only start and stop all drivers, but
> also start or stop an individual driver. e.g.
>
> /etc/init.d/
ata
> interface for trending and analysis. Basically the data-gathering
> guts of a SCADA system.
>
> The system is built on the Unix philosophy, so each communications
> driver and service runs as a separate process, communicating over
> AMQP. So far so good.
>
> I'v
ically the data-gathering
guts of a SCADA system.
The system is built on the Unix philosophy, so each communications
driver and service runs as a separate process, communicating over
AMQP. So far so good.
I've used the OpenVPN init script as a template for creating my init
scripts, which allows
Hi Reco,
On 09/07/15 16:43, Reco wrote:
>> > Is there a way to tell systemd to LEAVE the script alone while I debug
>> > it and get it working?
> Yes. Setting _SYSTEMCTL_SKIP_REDIRECT environment variable to any value
> should allow you to run it directly.
Ahh, that's EXACTLY what I needed. Thank
Hi.
On Thu, 09 Jul 2015 14:37:52 +1000
Stuart Longland wrote:
> Hi all,
>
> Is there any way to debug a LSB init script under systemd? I'm trying
> to write an init script for a service that starts multiple daemons, much
> like OpenVPN and how it starts a separate daemon
Hi all,
Is there any way to debug a LSB init script under systemd? I'm trying
to write an init script for a service that starts multiple daemons, much
like OpenVPN and how it starts a separate daemon for each connection.
So I've taken the OpenVPN init script and hacked it to make it
there - but I don't know of any way to do that using
> standard tools; if I wanted to try it, I'd have to write code for the
> purpose myself.
>
> Presumably appropriate tools do exist, if only within the kernel tree...
is it the kernel or the init script that initramfs-tools
On 04/25/2015 at 11:01 PM, Henrique de Moraes Holschuh wrote:
> On Sat, Apr 25, 2015, at 17:16, songbird wrote:
>
>> # cpio -i -v < /boot/initrd.img-3.18.0-trunk-686-pae
>> kernel
>> kernel/x86
>> kernel/x86/microcode
>> kernel/x86/microcode/GenuineIntel.bin
>> 22 blocks
>
> Yeah, well, you have
On Sat, Apr 25, 2015, at 17:16, songbird wrote:
> # cpio -i -v < /boot/initrd.img-3.18.0-trunk-686-pae
> kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/GenuineIntel.bin
> 22 blocks
Yeah, well, you have a multi-segment initramfs. There's an uncompressed cpio
archive first with t
The Wanderer wrote:
>Ric Moore wrote:
...
>> Sorry I missed it, but what version of Debian does this occur on??
>
> My system, which does not have the problem, is on current testing -
> dist-upgraded just this afternoon.
>
> songbird is at least running initramfs-tools from testing (it's the same
>
On 04/25/2015 at 05:36 PM, Ric Moore wrote:
> On 04/25/2015 05:29 PM, songbird wrote:
>
>> The Wanderer wrote:
>>> That's _very_ weird. If my experience is any guide, there should
>>> be an entire root-like hierarchy in there; mine contains
>>>
&g
0
# du .
du .
16 ./kernel/x86/microcode
20 ./kernel/x86
24 ./kernel
28 .
That's _very_ weird. If my experience is any guide, there should be an
entire root-like hierarchy in there; mine contains
bin/ conf/ etc/ init lib/ lib64/ run/ sbin/ scripts/
with appropriate co
gt;> # cpio -i -v < /boot/initrd.img-3.18.0-trunk-686-pae
>> kernel
>> kernel/x86
>> kernel/x86/microcode
>> kernel/x86/microcode/GenuineIntel.bin
>> 22 blocks
>>=20
>> # du .
>> du .
>> 16 ./kernel/x86/microcode
>> 20 ./ker
t; kernel
> kernel/x86
> kernel/x86/microcode
> kernel/x86/microcode/GenuineIntel.bin
> 22 blocks
>
> # du .
> du .
> 16./kernel/x86/microcode
> 20./kernel/x86
> 24./kernel
> 28.
That's _very_ weird. If my experience is any guide, there shou
The Wanderer wrote:
> songbird wrote:
>> The Wanderer wrote:
>>> songbird wrote:
>
doesn't work for me, hmm:
=20
# gunzip - < /boot/initrd.img-3.18.0-trunk-686-pae | cpio -i
=20
gzip: stdin: not in gzip format
>>>=20
>>> What does
>>>=20
>>> file /boot/initrd.img-3.18.0-trunk
On 04/25/2015 at 02:50 PM, songbird wrote:
> The Wanderer wrote:
>
>> songbird wrote:
>>> doesn't work for me, hmm:
>>>
>>> # gunzip - < /boot/initrd.img-3.18.0-trunk-686-pae | cpio -i
>>>
>>> gzip: stdin: not in gzip format
>>
>> What does
>>
>> file /boot/initrd.img-3.18.0-trunk-686-pae
>>
The Wanderer wrote:
> songbird wrote:
>> Mike Kupfer wrote:
>>> songbird wrote:
>>>
how did you expand the initramfs? i tried the
command given and didn't get it to work and so set
it aside until i could read further docs today.
>>>
>>> I did
>>>
>>> $ su
>>> # cd /root
>>
On 04/25/2015 at 02:08 PM, songbird wrote:
> Mike Kupfer wrote:
>
>> songbird wrote:
>>
>>> how did you expand the initramfs? i tried the
>>> command given and didn't get it to work and so set
>>> it aside until i could read further docs today.
>>
>> I did
>>
>> $ su
>> # cd /root
>>
Mike Kupfer wrote:
> songbird wrote:
>
>> how did you expand the initramfs? i tried the
>> command given and didn't get it to work and so set
>> it aside until i could read further docs today.
>
> I did
>
> $ su
> # cd /root
> # mkdir initrd
> # cd initrd
>
> and then ran the pip
>> how did you expand the initramfs? i tried the
>> command given and didn't get it to work and so set
>> it aside until i could read further docs today.
>
> lsinitramfs can be used to list the contents of the initramfs.
yes, i found that via the man pages but no
gave. I think I just
copy/pasted it.
> i meant to reply last night saying that the 401: was
> likely a line number from init, but got sidetracked...
Ah, yes, that makes sense.
regards,
mike
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsub
ocs today.
lsinitramfs can be used to list the contents of the initramfs.
> i meant to reply last night saying that the 401: was
> likely a line number from init, but got sidetracked...
songbird, do you have the busybox uninstalled or BUSYBOX=n in
/etc/initramfs-tools/initramfs.conf?
[1
mfs? i tried the
command given and didn't get it to work and so set
it aside until i could read further docs today.
i meant to reply last night saying that the 401: was
likely a line number from init, but got sidetracked...
songbird
--
To UNSUBSCRIBE, email to debian-user-requ...@l
The Wanderer wrote:
> If that doesn't help, then I'd advise that you expand the initramfs /
> initrd file from under /boot into an empty directory, and see what it
> contains. It may very well be missing either bin/touch or some related
> thing.
Indeed, it's missing bin/touch. Thanks for the det
1 - 100 of 1538 matches
Mail list logo
