Re: [arch-general] Cannot tether from Android using USB or bluetooth

[Kyle Terrien]

On 08/24/2015 02:13 PM, Alfredo Palhares wrote:
> I enabled the usb tethering on the phone, but ip link didn't show any new
> interface:
>
> 
>
> The important stuff seems to be here:
> rndis_host 1-1:1.0 enp0s20u1: renamed from usb0
> usb 1-1: USB disconnect, device number 41
> rndis_host 1-1:1.0 enp0s20u1: unregister 'rndis_host' usb-:00:14.0-1, 
> RNDIS device
> usb 1-1: new low-speed USB device number 43 using xhci_hcd
> 
> The interface comes up but its immediately down, for some weird reason. I 
> can't
> reproduce the problem every time.

On my phone (Nexus 4 running CM 12.1 nightlies which are based on
Android 5.1), activating USB tethering creates another Ethernet device.

The USB disconnect message is disturbing and generally indicates
hardware problems.  Furthermore, it sounds like this issue is
intermittent.  This smells of hardware problems.  I recommend cleaning
the MicroUSB port if it looks dirty.  Unfortunately, there is generally
no easy way to do this without disassembling the phone.

Personal anecdote:  My phone's MicroUSB port (same Nexus 4) once got
dirty enough to the point where the data pins no longer worked.
However, the charge pins *did* work.  I ended up taking the phone apart
to clean the MicroUSB port.  I'm still using that phone to this day.
:-)

--Kyle



signature.asc
Description: OpenPGP digital signature

Re: [arch-general] ABS

[Doug Newgard]

On Tue, 25 Aug 2015 03:05:14 +0200
Jens Adam  wrote:

> Tue, 25 Aug 2015 01:44:38 +0100 (BST)
> flow :
> 
> > Where I can get old ABS content?
> 
> https://wiki.archlinux.org/index.php/Arch_User_Repository#Git_repositories_for_AUR3_packages
> 
> --byte

ABS != AUR

Flow, you can get it through SVN or the Git mirror. Info should be in the wiki.


pgpGFvl3uoDHw.pgp
Description: OpenPGP digital signature

Re: [arch-general] ABS

[Jens Adam]

Tue, 25 Aug 2015 03:05:14 +0200
Jens Adam :

> Tue, 25 Aug 2015 01:44:38 +0100 (BST)
> flow :
> 
> > Where I can get old ABS content?
> 
> https://wiki.archlinux.org/index.php/Arch_User_Repository#Git_repositories_for_AUR3_packages
> 
> --byte

Err .. "ABS", yeah, sorry.

If you got a specific package, you could just use
:
- search your package and click on "View Changes"
- click on the commit message from the date you want
- there's a "download" link to a tar.gz containing the old PKGBUILD

Else, the whole repo history ist available at
https://projects.archlinux.org/svntogit/

--byte


pgpaPHvbye_Yq.pgp
Description: Digitale Signatur von OpenPGP

Re: [arch-general] Process 13696 (systemctl) of user 0 dumped core ??

[David C. Rankin]

On 08/24/2015 06:17 PM, Damjan Georgievski wrote:

   I haven't seen or noticed this happening before, but obviously the first
>core dump was back in April related to cups. The question is "What should I
>check?" and "Does any of this look related to BIOS settings and the new disk
>controller?" (that looks more doubtful after looking over all the
>information)
>
>   Anybody have experience with this type thing?


are you running everything Arch up-to-date vanilla or do you have some
custom stuff?
if you're vanilla, run memtest on the machine.


All vanilla, I'll double-check with memtest. After putting the pci-sata 
controller in, I have noticed an IRQ 13 error on boot related to the failed 
onboard disk controller. I suspect disabling the onboard controller completely 
will eliminate that error.


(next snip)
>> are you running everything Arch up-to-date vanilla or do you have some
>> >custom stuff?
>> >if you're vanilla, run memtest on the machine.
> also, make sure to:
> update the bios
> and
> do you have the inte-ucode installed and configured (this is very
> important for certain cpus)?
> https://wiki.archlinux.org/index.php/Microcode

Thankfully, this is a situation where I have an older AMD Phenom-9850 Black in 
the box, so linux-firmware should catch it. Thanks for your reply.


--
David C. Rankin, J.D.,P.E.

Re: [arch-general] ABS

[Jens Adam]

Tue, 25 Aug 2015 01:44:38 +0100 (BST)
flow :

> Where I can get old ABS content?

https://wiki.archlinux.org/index.php/Arch_User_Repository#Git_repositories_for_AUR3_packages

--byte


pgpmDUwspY8Kr.pgp
Description: Digitale Signatur von OpenPGP

[arch-general] ABS

[flow]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Where I can get old ABS content?
- -- 
_


~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.mixmin.net.
Date: Tue Aug 25 00:44:38 2015 GMT
From: f...@nym.mixmin.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlXbunYACgkQViYZwngkfDtL5wCgpFYYT87OjDJ3B3VIF51QCiWp
d4sAnisyEo3f5AzAeqkzQwsBBpKkWpDa
=6mxf
-END PGP SIGNATURE-

Re: [arch-general] Cannot tether from Android using USB or bluetooth

[Neven Sajko]

Do you maybe have android-udev installed? If so try removing that package.

Re: [arch-general] Process 13696 (systemctl) of user 0 dumped core ??

[Damjan Georgievski]

On 25 August 2015 at 01:17, Damjan Georgievski  wrote:
>> Mon 2015-08-24 15:32:05 CDT   13580 0 0   7 * /usr/bin/systemctl
>> Mon 2015-08-24 15:53:37 CDT   13696 0 0   7 * /usr/bin/systemctl
>
>>
>>   I haven't seen or noticed this happening before, but obviously the first
>> core dump was back in April related to cups. The question is "What should I
>> check?" and "Does any of this look related to BIOS settings and the new disk
>> controller?" (that looks more doubtful after looking over all the
>> information)
>>
>>   Anybody have experience with this type thing?
>
>
> are you running everything Arch up-to-date vanilla or do you have some
> custom stuff?
> if you're vanilla, run memtest on the machine.

also, make sure to:
update the bios
and
do you have the inte-ucode installed and configured (this is very
important for certain cpus)?
https://wiki.archlinux.org/index.php/Microcode

-- 
damjan

Re: [arch-general] Process 13696 (systemctl) of user 0 dumped core ??

[Damjan Georgievski]

> Mon 2015-08-24 15:32:05 CDT   13580 0 0   7 * /usr/bin/systemctl
> Mon 2015-08-24 15:53:37 CDT   13696 0 0   7 * /usr/bin/systemctl

>
>   I haven't seen or noticed this happening before, but obviously the first
> core dump was back in April related to cups. The question is "What should I
> check?" and "Does any of this look related to BIOS settings and the new disk
> controller?" (that looks more doubtful after looking over all the
> information)
>
>   Anybody have experience with this type thing?


are you running everything Arch up-to-date vanilla or do you have some
custom stuff?
if you're vanilla, run memtest on the machine.


-- 
damjan

Re: [arch-general] unable to load virtualbox kernel module

[James]

On 08/24/15 19:00, Sean Greenslade wrote:

On Mon, Aug 24, 2015 at 06:52:43PM -0400, James wrote:

I just installed virtualbox  yesterday and I rebooted and can't load the
kernel module.

I reinstalled the package:
$ sudo pacman -S virtualbox-host-modules


(1/1) reinstalling virtualbox-host-modules
[##] 100%
In order to use the new version, reload all virtualbox modules manually.
$ sudo insmod vboxdrv
insmod: ERROR: could not load module vboxdrv: No such file or directory

insmod wants a filename. Try modprobe instead.

--Sean

Thanks.
That and rebooting fixed it.

[arch-general] Process 13696 (systemctl) of user 0 dumped core ??

[David C. Rankin]

All,

  After bandaiding my server back together by putting a 4-port pci-sata 
controller in it to work around the failed onboard disk controller, the system 
is up and running fine. In the BIOS, currently the onboard sata controller is 
'Enabled', but each of the sata ports is 'Disabled'. When I check the status of 
something with systemclt, I get an odd error at the end of each command, eg:


[15:47 phoinix:~/.ssh] # sc status smbd
● smbd.service - Samba SMB/CIFS server
   Loaded: loaded (/usr/lib/systemd/system/smbd.service; enabled; vendor 
preset: disabled)

   Active: active (running) since Sat 2015-08-22 22:57:26 CDT; 1 day 16h ago
 Main PID: 542 (smbd)
   CGroup: /system.slice/smbd.service
   ├─542 /usr/bin/smbd -D
   └─559 /usr/bin/smbd -D
Bus error (core dumped)

  Looking at the journal and looking at the core dumps, the only other process 
that is implicated is:


  Cannot add dependency job for unit cups.socket, ignoring: Unit cups.socket 
failed to load: No such file or directory.


  Nothing else is generating a core dump. But each time I check the status of a 
process, it ends with:


Bus error (core dumped)

  The only other thing I see in the journal that may or may not be related is:

Aug 24 14:21:58 phoinix systemd[13187]: pam_unix(systemd-user:session): session 
opened for user root by (uid=0)
Aug 24 14:21:58 phoinix systemd[13187]: Unit type .busname is not supported on 
this system.


  I don't know if that's related, but it was the only thing else tangentially 
related to 'bus'.


  Looking at the core dump list with 'coredumpctl list' show a handful of files:

[17:46 phoinix:~/.ssh] # coredumpctl list
TIMEPID   UID   GID SIG PRESENT EXE
Mon 2015-04-06 19:00:15 CDT 342 0 0  11   /usr/bin/cupsd
Tue 2015-05-26 13:15:01 CDT   23265 0 0  11   /usr/bin/crond
Tue 2015-05-26 14:01:01 CDT   23563 0 0  11   /usr/bin/crond
Tue 2015-05-26 14:05:01 CDT   23593 0 0  11   /usr/bin/crond
Sun 2015-08-23 05:51:43 CDT3151 0 0   7 * /usr/bin/systemctl
Sun 2015-08-23 05:52:16 CDT3179 0 0   7 * /usr/bin/systemctl
Sun 2015-08-23 07:11:33 CDT3639 0 0   7 * /usr/bin/systemctl
Sun 2015-08-23 07:12:31 CDT3652 0 0   7 * /usr/bin/systemctl
Mon 2015-08-24 15:30:11 CDT   13565 0 0   7 * /usr/bin/systemctl
Mon 2015-08-24 15:32:05 CDT   13580 0 0   7 * /usr/bin/systemctl
Mon 2015-08-24 15:53:37 CDT   13696 0 0   7 * /usr/bin/systemctl

  Looking at the dumps in gdb shows:

[17:47 phoinix:~/.ssh] # coredumpctl gdb 13696
   PID: 13696 (systemctl)
   UID: 0 (root)
   GID: 0 (root)
Signal: 7 (BUS)
 Timestamp: Mon 2015-08-24 15:53:37 CDT (1h 54min ago)
  Command Line: systemctl status smbd
Executable: /usr/bin/systemctl
 Control Group: /user.slice/user-1000.slice/session-c2.scope
  Unit: session-c2.scope
 Slice: user-1000.slice
   Session: c2
 Owner UID: 1000 (david)
   Boot ID: aeecdf7479ea4b43aae7f1b9b83b2502
Machine ID: 8d32bcc3152b4a1f87c4d71f948f93fb
  Hostname: phoinix
  Coredump: 
/var/lib/systemd/coredump/core.systemctl.0.aeecdf7479ea4b43aae7f1b9b83b2502.13696.144044961700.lz4

   Message: Process 13696 (systemctl) of user 0 dumped core.

(gdb) bt
#0  0x7f353981becf in ?? ()
#1  0x7f3539801c09 in ?? ()
#2  0x7f3539801d38 in ?? ()
#3  0x7f3539801b64 in ?? ()
#4  0x7f3539801d38 in ?? ()
#5  0x7f3539801b64 in ?? ()
#6  0x7f353980310e in ?? ()
#7  0x7f35397f4080 in ?? ()
#8  0x7f353983340b in ?? ()
#9  0x7f35397ed1d1 in ?? ()
#10 0x7f35397e2414 in ?? ()
#11 0x7f35386f5790 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x7f35397e3049 in ?? ()
(gdb) frame 0
#0  0x7f353981becf in ?? ()
(gdb) info frame
Stack level 0, frame at 0x7ffed3907080:
 rip = 0x7f353981becf; saved rip = 0x7f3539801c09
 called by frame at 0x7ffed3907160
 Arglist at 0x7ffed3906fd8, args:
 Locals at 0x7ffed3906fd8, Previous frame's sp is 0x7ffed3907080
 Saved registers:
  rbx at 0x7ffed3907048, rbp at 0x7ffed3907050, r12 at 0x7ffed3907058, r13 at 
0x7ffed3907060, r14 at 0x7ffed3907068,

  r15 at 0x7ffed3907070, rip at 0x7ffed3907078
(gdb) quit

  I haven't seen or noticed this happening before, but obviously the first core 
dump was back in April related to cups. The question is "What should I check?" 
and "Does any of this look related to BIOS settings and the new disk 
controller?" (that looks more doubtful after looking over all the information)


  Anybody have experience with this type thing?

--
David C. Rankin, J.D.,P.E.

Re: [arch-general] unable to load virtualbox kernel module

[Sean Greenslade]

On Mon, Aug 24, 2015 at 06:52:43PM -0400, James wrote:
> 
> I just installed virtualbox  yesterday and I rebooted and can't load the
> kernel module.
> 
> I reinstalled the package:
> $ sudo pacman -S virtualbox-host-modules
> 
> >(1/1) reinstalling virtualbox-host-modules
> >[##] 100%
> >In order to use the new version, reload all virtualbox modules manually.
> >$ sudo insmod vboxdrv
> >insmod: ERROR: could not load module vboxdrv: No such file or directory

insmod wants a filename. Try modprobe instead.

--Sean

[arch-general] unable to load virtualbox kernel module

[James]

I just installed virtualbox  yesterday and I rebooted and can't load the 
kernel module.


I reinstalled the package:
$ sudo pacman -S virtualbox-host-modules

(1/1) reinstalling virtualbox-host-modules 
[##] 100%

In order to use the new version, reload all virtualbox modules manually.
$ sudo insmod vboxdrv
insmod: ERROR: could not load module vboxdrv: No such file or directory

Re: [arch-general] Realtek 8111/8168/8411 Blues - cannot get dhcpcd address (link UP)

[David C. Rankin]

On 08/24/2015 01:26 PM, Aaron Laws wrote:

Eek, sorry you're having so much trouble. I may have already said this, but
I'll give it another go. I'm using the same board (GA-990FXA-UD3) with the
same ethernet card. I decided the onboard NIC was trash, so I installed a
PCI ethernet card, installed arch, and started using it. Later, I went back
to troubleshoot the NIC, and found that if I sudo pacman -Syu r8168; echo
'blacklist r8169' > /etc/modprobe.d/r8169_blacklist.conf; reboot;
everything went okay, and no need for PCI card.

I'm afraid that beyond that, I don't think I can help.


You were a great help! What I learned is that board has gone through a lot of 
changes (chipset, etc.) between Version 1.0 - 4.1 (I have Ver. 4.1). What is 
needed to fix the issues differs depending on the chipset. Mine works fine with 
the native r8169 driver as long as IOMMU is enable in the bios. I'll try 
disabling in the kernel to kill the Page_Faults on boot.


--
David C. Rankin, J.D.,P.E.

[arch-general] Cannot tether from Android using USB or bluetooth

[Alfredo Palhares]

Hello fellow Arch Linux users,

I recently tried to use USB tethering, without success. The interface just won't
come up.

I enabled the usb tethering on the phone, but ip link didn't show any new
interface:

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s25:  mtu 1500 qdisc fq_codel state 
DOWN mode DEFAULT group default qlen 1000
link/ether 28:d2:44:6c:0b:f8 brd ff:ff:ff:ff:ff:ff
3: wlp3s0:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
link/ether 7c:7a:91:21:19:39 brd ff:ff:ff:ff:ff:ff
5: wwp0s20u4i6:  mtu 1500 qdisc noop state DOWN mode 
DEFAULT group default qlen 1000
link/ether 02:15:e0:ec:01:00 brd ff:ff:ff:ff:ff:ff

(wwp0s20u4i6 is my builtin modem interface)

journalctl -k tells me the following:

myhost kernel: usb 1-1: device descriptor read/64, error -110
myhost kernel: usb 1-1: new low-speed USB device number 37 using xhci_hcd
myhost kernel: usb 1-1: device descriptor read/64, error -71
myhost kernel: usb 1-1: device descriptor read/64, error -110
myhost kernel: usb 1-1: new low-speed USB device number 38 using xhci_hcd
myhost kernel: usb 1-1: Device not responding to setup address.
myhost kernel: usb 1-1: Device not responding to setup address.
myhost kernel: usb 1-1: device not accepting address 38, error -71
myhost kernel: usb 1-1: new low-speed USB device number 39 using xhci_hcd
myhost kernel: usb 1-1: Device not responding to setup address.
myhost kernel: usb 1-1: Device not responding to setup address.
myhost kernel: usb 1-1: device not accepting address 39, error -71
myhost kernel: usb usb1-port1: unable to enumerate USB device
myhost kernel: usb 1-1: new high-speed USB device number 40 using xhci_hcd
myhost kernel: cdc_acm 1-1:1.1: ttyACM3: USB ACM device
myhost kernel: usb 1-1: USB disconnect, device number 40
myhost kernel: cdc_acm 1-1:1.1: failed to set dtr/rts
myhost kernel: usb 1-1: new high-speed USB device number 41 using xhci_hcd
myhost kernel: rndis_host 1-1:1.0 usb0: register 'rndis_host' at 
usb-:00:14.0-1, RNDIS device, aa:bb:cc:dd:ee:ff
myhost kernel: rndis_host 1-1:1.0 enp0s20u1: renamed from usb0
myhost kernel: usb 1-1: USB disconnect, device number 41
myhost kernel: rndis_host 1-1:1.0 enp0s20u1: unregister 'rndis_host' 
usb-:00:14.0-1, RNDIS device
myhost kernel: usb 1-1: new low-speed USB device number 43 using xhci_hcd

The important stuff seems to be here:
rndis_host 1-1:1.0 enp0s20u1: renamed from usb0
usb 1-1: USB disconnect, device number 41
rndis_host 1-1:1.0 enp0s20u1: unregister 'rndis_host' usb-:00:14.0-1, RNDIS 
device
usb 1-1: new low-speed USB device number 43 using xhci_hcd

The interface comes up but its immediately down, for some weird reason. I can't
reproduce the problem every time.

Anyone can point me on how to debug this further?

Regards,

-- 
Alfredo Palhares
GPG/PGP Key Fingerprint
68FC B06A 6C22 8B9B F110
38D6 E8F7 4D1F 0763 CAAD


signature.asc
Description: PGP signature

Re: [arch-general] SOLVED Re: Realtek 8111/8168/8411 Blues - cannot get dhcpcd address (link UP)

[Aaron Laws]

>
>
> $#%#@%#$%... You have to enable IOMMU in the BIOS before the NIC will
> work!


Oh yeah, that, too. Mine is the last comment on
https://bbs.archlinux.org/viewtopic.php?id=186503. I had to enable IOMMU in
bios, then disable it in kernel using iommu=soft.

Yes, the BIOS eats up your flash drive. Maybe it only knows FAT32 or NTFS
or something. Just don't have it do any reading or writing to a drive with
anything important on it. It also does this to hard drives, so stay away
from screenshots, etc.

I'm happy you got it worked out!

Re: [arch-general] Realtek 8111/8168/8411 Blues - cannot get dhcpcd address (link UP)

[Aaron Laws]

On Thu, Aug 20, 2015 at 10:34 PM, David C. Rankin <
drankina...@suddenlinkmail.com> wrote:
>
>   Has anyone ever had a board or an install where the network was just
> flaky or dead for multiple NICs? Thoughts?
>
>
> --
> David C. Rankin, J.D.,P.E.
>

Eek, sorry you're having so much trouble. I may have already said this, but
I'll give it another go. I'm using the same board (GA-990FXA-UD3) with the
same ethernet card. I decided the onboard NIC was trash, so I installed a
PCI ethernet card, installed arch, and started using it. Later, I went back
to troubleshoot the NIC, and found that if I sudo pacman -Syu r8168; echo
'blacklist r8169' > /etc/modprobe.d/r8169_blacklist.conf; reboot;
everything went okay, and no need for PCI card.

I'm afraid that beyond that, I don't think I can help.

Aaron

Re: [arch-general] Any ETA on the Tex Live 2015 update?

[Leonid Isaev]

On Mon, Aug 24, 2015 at 12:15:32PM -0500, Doug Newgard wrote:
> On Mon, 24 Aug 2015 17:00:18 +
> Leonid Isaev  wrote:
> 
> > > I'm also curious about this. It seems like the maintainer hasn't been
> > > active for the past 5 months.[1]
> > > What is the normal course of action in such a case? For instance, how 
> > > could
> > > I contact the maintainer?
> > 
> > TeXLive is not a critical package, so what's the rush updating it? If you
> > really want to see an updated version, open a bugreport and attach there a
> > patched PKGBUILD. And of course, you can always build the latest version
> > locally (just clone the svn trunk and run makepkg)...
> > 
> > Cheers,
> 
> Please do not file a bug report because a package is outdated. This is the #1
> rule of the bugtracker.

Sorry, I meant feature request. Of course, opening tickets just to say that a
package X is out-of-date is silly.

But if the project is complex (like texlive-*) then bumping it may not be a
simple issue. So if I happen to go through this exercise before the maintainer,
how am supposed to communicate the working PKGBUILD, in an open fashion? A ML
would be best of course, but arch-general isn't a place for this...

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Any ETA on the Tex Live 2015 update?

[Doug Newgard]

On Mon, 24 Aug 2015 17:00:18 +
Leonid Isaev  wrote:

> > I'm also curious about this. It seems like the maintainer hasn't been
> > active for the past 5 months.[1]
> > What is the normal course of action in such a case? For instance, how could
> > I contact the maintainer?
> 
> TeXLive is not a critical package, so what's the rush updating it? If you
> really want to see an updated version, open a bugreport and attach there a
> patched PKGBUILD. And of course, you can always build the latest version
> locally (just clone the svn trunk and run makepkg)...
> 
> Cheers,

Please do not file a bug report because a package is outdated. This is the #1
rule of the bugtracker.

Doug

Re: [arch-general] Any ETA on the Tex Live 2015 update?

[Leonid Isaev]

> I'm also curious about this. It seems like the maintainer hasn't been
> active for the past 5 months.[1]
> What is the normal course of action in such a case? For instance, how could
> I contact the maintainer?

TeXLive is not a critical package, so what's the rush updating it? If you
really want to see an updated version, open a bugreport and attach there a
patched PKGBUILD. And of course, you can always build the latest version
locally (just clone the svn trunk and run makepkg)...

Cheers,
-- 
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6  20DF 9291 EE8A 043C B8C4
  C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

Re: [arch-general] Any ETA on the Tex Live 2015 update?

[Sebastiaan Lokhorst]

2015-08-22 21:27 GMT+02:00 Mohammad_AlSaleh :
>
> I'm wondering if there is any reason for the hold-up. Other than
> the maintainers(s) being busy of course.
>

I'm also curious about this. It seems like the maintainer hasn't been
active for the past 5 months.[1]
What is the normal course of action in such a case? For instance, how could
I contact the maintainer?

Thanks,
Sebastiaan

[1] https://www.archlinux.org/packages/?maintainer=remy

Re: [arch-general] Failed kernel update

[Maarten de Vries]

On 24 August 2015 at 15:14, Doug Newgard  wrote:

> On Mon, 24 Aug 2015 10:46:33 +0200
> Maarten de Vries  wrote:
>
> > ​Would that work correct with the post install/upgrade hooks running
> > mkinitcpio?​
>
>
> Yes, it would work fine.
>
> Doug
>

​Ah, so pacman/alpm itself chroots into the root directory for the post
install/upgrade scripts? That is useful to know.​

-- Maarten

Re: [arch-general] Failed kernel update

[Doug Newgard]

On Mon, 24 Aug 2015 10:46:33 +0200
Maarten de Vries  wrote:

> On 23 August 2015 at 23:49, Doug Newgard  wrote:
> 
> > On Sun, 23 Aug 2015 23:12:07 +0200
> > Maarten de Vries  wrote:
> >
> >
> > > I would try to arch-chroot​ into the broken system and reinstall the
> > kernel
> > > package with pacman. I'd think that should fix it.
> >
> > This, or use pacman's --root option from the live environment.
> >
> > Doug
> >
> 
> ​Would that work correct with the post install/upgrade hooks running
> mkinitcpio?​
> 
> ​I would chroot anyway, to make sure.
> 
> -- Maarten

Yes, it would work fine.

Doug

Re: [arch-general] Failed kernel update

[Maarten de Vries]

On 23 August 2015 at 23:49, Doug Newgard  wrote:

> On Sun, 23 Aug 2015 23:12:07 +0200
> Maarten de Vries  wrote:
>
>
> > I would try to arch-chroot​ into the broken system and reinstall the
> kernel
> > package with pacman. I'd think that should fix it.
>
> This, or use pacman's --root option from the live environment.
>
> Doug
>

​Would that work correct with the post install/upgrade hooks running
mkinitcpio?​

​I would chroot anyway, to make sure.

-- Maarten

Re: [arch-general] LTS Kernels

[David C. Rankin]

On 08/22/2015 03:54 AM, Iru Cai wrote:

>install kernel: pacman -S linux-lts

edit grub config file: grub-mkconfig -o /boot/grub/grub.cfg


>


Iru,

  I didn't completely understand what if any edit needs to be made in any of 
the /etc/grub.d/XX_files to have the LTS entry listed in the boot menu. The 
following in 10_linux:


machine=`uname -m`
case "x$machine" in
xi?86 | xx86_64)
list=`for i in /boot/vmlinuz-* /vmlinuz-* /boot/kernel-* ; do
  if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
  done` ;;
*)
	list=`for i in /boot/vmlinuz-* /boot/vmlinux-* /vmlinuz-* /vmlinux-* 
/boot/kernel-* ; do

  if grub_file_is_not_garbage "$i" ; then echo -n "$i " ; fi
 done` ;;
esac

indicates that whatever 'vmlinuz-*' files found should automatically be included 
in the grub list by grub-mkconfig. In the case of the normal kernel and lts, 
then it would find both:


  vmlinuz-linux
  vmlinuz-linux-lts

So what new lines are needed in the config files before just running:

# grub-mkconfig -o /boot/grub/grub.cfg

?

--
David C. Rankin, J.D.,P.E.