Re: Bug#753816: [systemd] Broken audio

2014-07-06 Thread Antonio Marcos López Alonso

El 06/07/14 05:34, Ben Hutchings escribió:

On Sat, 2014-07-05 at 18:58 +0200, Michael Biebl wrote:

Am 05.07.2014 18:38, schrieb Antonio Marcos López Alonso:

El 05/07/14 17:06, Michael Biebl escribió:

Am 05.07.2014 17:56, schrieb Antonio Marcos López Alonso:

Just in case, have you noticed I'm using an ALSA-Jack loopback setting
for audio?

Under sysvinit, udev (including udevadm settle) is started before the
kmod init script, which loads snd_aloop.
That means, snd_aloop is loaded after snd_hda_intel.

Under systemd, it looks like the snd_aloop module is loaded about the
same time systemd-udevd is started. There might be a race here and
snd_aloop is loaded before snd_hda_intel.

This *might* be the reason, but I'm no expert on this matter.

Can you try removing snd_aloop from /etc/modules and test if that makes
a difference.


OK removed snd_aloop and audio is back. Then reloaded the module,
restarted JACK and audio is still fine. So as you said there must be
some race condition in there. Should I keep this ticket opened?


Hm, not sure what to do about this. We could order
systemd-load-modules.service after systemd-udevd.service. But that
doesn't guarantee the loading order of the modules and it feels like
papering over the underlying issue.

I'm no sound expert, but I'd say that the loading order should not
matter. Maybe we need some input from the kernel team or some alsa
experts here.

I think this is due to ALSA userland (or maybe higher levels) being
stupid about device selection.  I think the default is to use sound
device 0, which can be whichever driver won the race.


I took the liberty to CC the Debian kernel team and the maintainer of
the snd_aloop module. I hope they can help us here.

For reference the complete bug report is at [1]


Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753816

I think the usual workaround is to add 'index=1' to the snd-aloop line
in /etc/modules.  It is probably possible to do something more
sophisticated in an ALSA configuration file.

Ben.



Adding 'index=1' didn't work. I still have to reload snd_aloop and 
restart JACK to get audio back.


Antonio


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b90b59.6040...@gmail.com



Re: Bug#753816: [systemd] Broken audio

2014-07-06 Thread Michael Biebl
Am 06.07.2014 10:39, schrieb Antonio Marcos López Alonso:
> El 06/07/14 05:34, Ben Hutchings escribió:

>> I think the usual workaround is to add 'index=1' to the snd-aloop line
>> in /etc/modules.  It is probably possible to do something more
>> sophisticated in an ALSA configuration file.
> 
> Adding 'index=1' didn't work. I still have to reload snd_aloop and
> restart JACK to get audio back.

Be aware that systemd-modules-load does *not* read module parameters
from /etc/modules. You'll need to set them via a /etc/modprobe.d/ file.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature


Processing of linux_3.2.60-1+deb7u1_amd64.changes

2014-07-06 Thread Debian FTP Masters
linux_3.2.60-1+deb7u1_amd64.changes uploaded successfully to localhost
along with the files:
  linux_3.2.60-1+deb7u1.dsc
  linux_3.2.60.orig.tar.xz
  linux_3.2.60-1+deb7u1.debian.tar.xz
  linux-doc-3.2_3.2.60-1+deb7u1_all.deb
  linux-manual-3.2_3.2.60-1+deb7u1_all.deb
  linux-source-3.2_3.2.60-1+deb7u1_all.deb
  linux-support-3.2.0-4_3.2.60-1+deb7u1_all.deb
  linux-image-3.2.0-4-amd64_3.2.60-1+deb7u1_amd64.deb
  linux-image-3.2.0-4-amd64-dbg_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-amd64_3.2.60-1+deb7u1_amd64.deb
  xen-linux-system-3.2.0-4-amd64_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-common_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-all_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-all-amd64_3.2.60-1+deb7u1_amd64.deb
  linux-libc-dev_3.2.60-1+deb7u1_amd64.deb
  linux-image-3.2.0-4-rt-amd64_3.2.60-1+deb7u1_amd64.deb
  linux-image-3.2.0-4-rt-amd64-dbg_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-rt-amd64_3.2.60-1+deb7u1_amd64.deb
  linux-headers-3.2.0-4-common-rt_3.2.60-1+deb7u1_amd64.deb
  kernel-image-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-extra-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-wireless-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-shared-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  serial-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  usb-serial-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ppp-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  pata-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  cdrom-core-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  firewire-core-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  scsi-core-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  scsi-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  scsi-common-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  scsi-extra-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  plip-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  floppy-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  loop-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  btrfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ext2-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ext3-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ext4-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  isofs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  jfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ntfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  reiserfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  xfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  fat-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ufs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  qnx4-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  md-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  multipath-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  usb-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  usb-storage-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  pcmcia-storage-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  fb-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  input-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  event-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  mouse-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  irda-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  parport-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-pcmcia-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  pcmcia-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nic-usb-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  sata-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  core-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  acpi-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  i2c-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  crc-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  crypto-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  crypto-dm-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  efi-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  ata-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  mmc-core-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  mmc-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  nbd-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  squashfs-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  speakup-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  virtio-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  uinput-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  sound-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  zlib-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  hyperv-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  udf-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb
  fuse-modules-3.2.0-4-amd64-di_3.2.60-1+deb7u1_amd64.udeb

Greetings,

Re: Kernel 3.2.0 panics

2014-07-06 Thread Ben Hutchings
On Sat, 2014-07-05 at 20:07 -0700, Alexander Carver wrote:
> On 2014-07-05 19:29, Ben Hutchings wrote:
> > On Sat, 2014-07-05 at 13:41 -0700, AC wrote:
> >> Hi all,
> >>
> >> I've been searching for about a month trying to fix the kernel panic on
> >> boot for 3.2.0-4 with no luck so far.  I get the well documented error:
> >>
> >> No filesystem could mount root: tried:
> >> Kernel Panic - not syncing: VFS: Unable to mount root fs on
> >> unknown-block(0,0)
> >> (plus stack dump)
> >>
> >> however none of the suggested fixes (the few that exist) work.  My
> >> system is a Pentium II and recently upgraded to wheezy.  I've tried both
> >> the 3.2.0-4-686pae and the 3.2.0-4-486 images with identical results,
> >> they all end with the kernel panic above.
> >>
> >> I'm currently running kernel image 2.6.39 which is working fine, I just
> >> can't get any 3.2 image to work at all.  Suggestions and help are very
> >> much appreciated.
> > 
> > It sounds like your boot loader is not loading the initramfs, or the
> > initramfs is somehow corrupted.  Are you using LILO or GRUB?
> 
> I'm currently using LILO.

Then you probably need to fix /etc/lilo.conf to specify the initramfs
for the 3.2 kernel.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


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


Re: Kernel 3.2.0 panics

2014-07-06 Thread AC
On 2014-07-06 11:20, Ben Hutchings wrote:

> Then you probably need to fix /etc/lilo.conf to specify the initramfs
> for the 3.2 kernel.

Yes, that was it.  I feel dumb now.  The package scripts created all the
other lilo.conf configuration entries but I never noticed that it didn't
create the initrd line for the newly installed kernel.  That fixed it,
thanks, 3.2.0-4-686-pae is booting just fine now.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b99bd2.8000...@acarver.net



Re: Bug#753816: [systemd] Broken audio

2014-07-06 Thread Bjørn Mork
Michael Biebl  writes:

> Be aware that systemd-modules-load does *not* read module parameters
> from /etc/modules. You'll need to set them via a /etc/modprobe.d/ file.

Hmm... Is that considered a bug, or is it just the way things are going
to be?

The modules(5) man page from the kmod package still says

   The /etc/modules file contains the names of kernel modules that
   are to be loaded at boot time, one per line. Arguments can be
   given in the same line as the module name. Lines beginning with a
   '#' are ignored.

and I would expect a few might have used that feature in the past. It
seems unnecessary to break such configurations.


Bjørn


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87oax2s3oq@nemi.mork.no



Re: Bug#753816: [systemd] Broken audio

2014-07-06 Thread Antonio Marcos López Alonso

El 06/07/14 12:59, Michael Biebl escribió:

Am 06.07.2014 10:39, schrieb Antonio Marcos López Alonso:

El 06/07/14 05:34, Ben Hutchings escribió:

I think the usual workaround is to add 'index=1' to the snd-aloop line
in /etc/modules.  It is probably possible to do something more
sophisticated in an ALSA configuration file.

Adding 'index=1' didn't work. I still have to reload snd_aloop and
restart JACK to get audio back.

Be aware that systemd-modules-load does *not* read module parameters
from /etc/modules. You'll need to set them via a /etc/modprobe.d/ file.


Ah! It sounded somewhat strange but as this module stuff is a sort of 
terra incognita for me... :) Now I created a 
/etc/modprobe.d/snd-aloop.conf file which contains a single line with 
'options snd-aloop index=1' and everything is fine again after boot!


Thanks a lot for your tips!
Antonio


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b9a5b1.10...@gmail.com



New debconf template for the linux package

2014-07-06 Thread Aurelien Jarno
Hi,

I intend to add a new debconf template in the linux package, that will
appear on mips/mipsel systems. As English is a foreign language for me
I appreciate if some people can review it. Thanks in advance.

Best regards,
Aurelien


Index: debian/templates/image.plain.templates.in
===
--- debian/templates/image.plain.templates.in   (révision 21498)
+++ debian/templates/image.plain.templates.in   (copie de travail)
@@ -36,3 +36,17 @@
  .
  It is highly recommended to abort the kernel removal unless you are
  prepared to fix the system after removal.
+
+Template: 
linux-image-@abiname@@localversion@/postinst/mips-initrd-@abiname@@localversion@
+Type: note
+_Description: Boot loader configuration must be updated
+ Historically MIPS kernels were compiled so that they can boot without
+ initrd (i.e. with disk and filesystem drivers built-in), as some bootloaders
+ did not support booting with an initrd. This isn't the case anymore, so this
+ image now uses initrd.
+ .
+ Your current kernel has been booted without initrd. Please make sure to
+ configure your bootloader to use initrd, otherwise there is a danger that
+ the system will fail to boot. Your system might still be able to boot
+ without initrd, but this likely won't be the case for the next versions
+ of this package.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140706202541.ga21...@volta.rr44.fr



Re: New debconf template for the linux package

2014-07-06 Thread Bastian Blank
On Sun, Jul 06, 2014 at 10:25:41PM +0200, Aurelien Jarno wrote:
> I intend to add a new debconf template in the linux package, that will
> appear on mips/mipsel systems. As English is a foreign language for me
> I appreciate if some people can review it. Thanks in advance.

Don't you think this belongs to linux-base like the id switch?

Bastian

-- 
Women professionals do tend to over-compensate.
-- Dr. Elizabeth Dehaver, "Where No Man Has Gone Before",
   stardate 1312.9.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140706211036.ga27...@mail.waldi.eu.org



Re: New debconf template for the linux package

2014-07-06 Thread Ben Hutchings
On Sun, 2014-07-06 at 23:10 +0200, Bastian Blank wrote:
> On Sun, Jul 06, 2014 at 10:25:41PM +0200, Aurelien Jarno wrote:
> > I intend to add a new debconf template in the linux package, that will
> > appear on mips/mipsel systems. As English is a foreign language for me
> > I appreciate if some people can review it. Thanks in advance.
> 
> Don't you think this belongs to linux-base like the id switch?

The disk ID changes were worth doing and were safe whether or not you
upgraded the linux-image package at the same time as installing
linux-base.

However, if we put this in linux-base now, you may be prompted to change
boot loader config before you install a linux-image package that
actually builds an initramfs.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg


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


Re: New debconf template for the linux package

2014-07-06 Thread Ben Hutchings
On Sun, 2014-07-06 at 22:25 +0200, Aurelien Jarno wrote:
> Hi,
> 
> I intend to add a new debconf template in the linux package, that will
> appear on mips/mipsel systems. As English is a foreign language for me
> I appreciate if some people can review it. Thanks in advance.
> 
> Best regards,
> Aurelien
> 
> 
> Index: debian/templates/image.plain.templates.in
> ===
> --- debian/templates/image.plain.templates.in (révision 21498)
> +++ debian/templates/image.plain.templates.in (copie de travail)
> @@ -36,3 +36,17 @@
>   .
>   It is highly recommended to abort the kernel removal unless you are
>   prepared to fix the system after removal.
> +
> +Template: 
> linux-image-@abiname@@localversion@/postinst/mips-initrd-@abiname@@localversion@
> +Type: note
> +_Description: Boot loader configuration must be updated
> + Historically MIPS kernels were compiled so that they can boot without
> + initrd (i.e. with disk and filesystem drivers built-in), as some bootloaders
> + did not support booting with an initrd. This isn't the case anymore, so this
> + image now uses initrd.
> + .
> + Your current kernel has been booted without initrd. Please make sure to
> + configure your bootloader to use initrd, otherwise there is a danger that
> + the system will fail to boot. Your system might still be able to boot
> + without initrd, but this likely won't be the case for the next versions
> + of this package.

This doesn't seem specific enough.  It also doesn't seem to accurately
report what's changing now - as far as I know, you haven't yet
modularised anything that was built-in.

I would write something like:

Boot loader configuration must be updated to load initramfs
 This kernel package will build an 'initramfs' file
 (/boot/initrd.img-@abiname@) that should be loaded by the boot loader
 in addition to the kernel itself.  The initramfs enables a more
 flexible boot process, and it is likely that future kernel versions
 will not boot without an initramfs.
 .
 The currently running kernel has been booted without an initramfs.
 You should reconfigure your boot loader to load the initramfs for
 Linux version @abiname@ and for each later version.

But I think that still needs improvement, for example to say clearly
that each kernel version needs its own initramfs.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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


Processed: Re: Bug#753768: ath9k: Cannot disable 802.11n in the ath9k driver

2014-07-06 Thread Debian Bug Tracking System
Processing control commands:

> tag -1 - patch
Bug #753768 [src:linux] ath9k: Cannot disable 802.11n in the ath9k driver
Removed tag(s) patch.

-- 
753768: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753768
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/handler.s.b753768.140469629725355.transcr...@bugs.debian.org



Bug#753768: ath9k: Cannot disable 802.11n in the ath9k driver

2014-07-06 Thread Ben Hutchings
Control: tag -1 - patch

On Fri, 2014-07-04 at 21:04 +0100, Chris wrote:
> Package: src:linux
> Version: 3.14.7-1
> Severity: normal
> File: ath9k
> Tags: patch
> 
> Dear Maintainer,
> 
> The ath9k drive does not support an option for disabling 802.11n.
> 
> I (as do many other users) suffer from frequent disconnections when connected 
> to a
> a wireless AP using 802.11n. Disconnections are accompanied by a message
> indicating that the client has deauthenticated by local choice (reason=3).
> 
> Researching the issue seems to point towards a problem with 802.11n roaming
> and various open source WiFi drivers *[1]. Some drivers provide an option to
> work around this i.e. '11n_disable=1'.
> 
> I notice that 'Michel Alexandre Salim' has contributed the following patch
> to enable this functionality *[2]:
[...]

This approach was rejected upstream, so we will not apply this patch.
Sorry about that, but we do not want to support Debian-specific hacks.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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


Re: New debconf template for the linux package

2014-07-06 Thread Christian PERRIER
Quoting Ben Hutchings (b...@decadent.org.uk):

> I would write something like:
> 
> Boot loader configuration must be updated to load initramfs
>  This kernel package will build an 'initramfs' file
>  (/boot/initrd.img-@abiname@) that should be loaded by the boot loader
>  in addition to the kernel itself.  The initramfs enables a more
>  flexible boot process, and it is likely that future kernel versions
>  will not boot without an initramfs.
>  .
>  The currently running kernel has been booted without an initramfs.
>  You should reconfigure your boot loader to load the initramfs for
>  Linux version @abiname@ and for each later version.
> 
> But I think that still needs improvement, for example to say clearly
> that each kernel version needs its own initramfs.


Ben's version has the advantage (seen from my POV) to drop the "your
kernel" which I was about to suggest to change (this is indeed not
"my" kernel but the one running on the machine, which is not
necessarily "mine").

OTOH, the same remark stands for "your" boot loader which I would
replace by "the boot loader".

And, of course, Ben's rewrite puts a big "reviewed by native speaker"
sticker on the template, which is great..:-)




signature.asc
Description: Digital signature