Re: [gentoo-user] [OT] Read date input from text file problem

[Paul Colquhoun]

On Sunday, August 6, 2023 12:28:26 P.M. AEST Walter Dnes wrote:
>   I have a situation where something that works as a literal but
> doesn't work when reading from a text file.  Here's the problem,
> simplified...
> 
>   I have a text file ztest.txt consisting of one line...
> 
> "August 14, 2021"
> 
>   ...and I have a script ztest consisting of...
> 
> #!/bin/bash
> xtoday=$( date --date="August 14, 2021" +%F )
> echo ${xtoday}
> read < ztest.txt
> echo "${REPLY}"
> xtoday=$( date --date="${REPLY}" +%F )
> echo ${xtoday}
> 
>   Running the script produces three lines of output...
> 
> 2021-08-14
> "August 14, 2021"
> date: invalid date ‘"August 14, 2021"’
> 
>   What am I doing wrong?

The date in the text file shoudn't have the quotes around it.

-- 
Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/
  Asking for technical help in newsgroups?  Read this first:
 http://catb.org/~esr/faqs/smart-questions.html#intro

[gentoo-user] [OT] Read date input from text file problem

[Walter Dnes]

  I have a situation where something that works as a literal but
doesn't work when reading from a text file.  Here's the problem,
simplified...

  I have a text file ztest.txt consisting of one line...

"August 14, 2021"

  ...and I have a script ztest consisting of...

#!/bin/bash
xtoday=$( date --date="August 14, 2021" +%F )
echo ${xtoday}
read < ztest.txt
echo "${REPLY}"
xtoday=$( date --date="${REPLY}" +%F )
echo ${xtoday}

  Running the script produces three lines of output...

2021-08-14
"August 14, 2021"
date: invalid date ‘"August 14, 2021"’

  What am I doing wrong?

-- 
I've seen things, you people wouldn't believe; Gopher, Netscape with
frames, the first Browser Wars.  Searching for pages with AltaVista,
pop-up windows self-replicating, trying to uninstall RealPlayer.  All
those moments, will be lost in time like tears in rain... time to die.

[gentoo-user] dmcrypt error during boot

[Michael]

This is a simple installation on 3 partitions for /boot, / and /home 
respectively.  There is no initrd and no 3rd party boot manager.  The system 
is booted directly by the UEFI firmware.

Only the /home partition is encrypted with dm-crypt/luks.  The dm-crypt key is 
itself encrypted with gpg and stored in /etc/keys/enc.key.gpg.

When the system boots a couple of error messages ominously flash through about 
dmcrypt service failing to start.  Then the pinentry pops up asking for the 
gpg passphrase.  The passphrase is promptly typed in, the boot process 
continues and the /dev/mapper/home block device is set up as 'dev/mapper/home 
-> /dev/dm-0'.

However, the decrypted partition is NOT mounted under /home, unless I login as 
root and proceed to do this manually.

I have tried a few things, unsuccessfully, including:

1. Specifying in fstab the UUID for device to be used for the /home partition, 
then changing this to '/dev/mapper/home'.

2. Adding an entry in /etc/dmtab, generated by 'dmsetup table', after manually 
decrypting and mounting the /home partition.

3. Adding in '/etc/conf.d/device-mapper':

rc_verbose="YES"
rc_after="dmcrypt"

to the default entry of:

RC_AFTER="lvm"

(NOTE: There is no lvm service in this system.)

This is what rc.log reveals:

rc boot logging started at Fri Aug  4 16:21:38 2023

 * Setting system clock using the hardware clock [UTC] ...
 [ ok ]
 * Mounting misc binary format filesystem ...
 [ ok ]
 * Loading custom binary format handlers ...
 [ ok ]
 * Setting up dm-crypt mappings ...
 *   home using:open /dev/sda9 home ...
Nothing to read on input.
Nothing to read on input.
Nothing to read on input.
Nothing to read on input.
Nothing to read on input.
 * failure running cryptsetup
 [ !! ]
 * Failed to setup dm-crypt devices
 [ !! ]
 * ERROR: dmcrypt failed to start
 *  Setting up device-mapper volumes:
 *   Creating volume: home ...
 *   Error creating volume: home
 [ !! ]
 * ERROR: device-mapper failed to start
 * Checking local filesystems  ...
 [ ok ]
 * Remounting root filesystem read/write ...
 [ ok ]
 * Remounting filesystems ...
 [ ok ]
 * Updating /etc/mtab ...
 * Creating mtab symbolic link
 [ ok ]
 * Activating swap devices ...
 [ ok ]
 * Mounting local filesystems ...
 [ ok ]
 * Configuring kernel parameters ...
 [ ok ]
 * Creating user login records ...
 [ ok ]
 * Wiping /tmp directory ...
 [ ok ]
 * Starting dbus ...
 [ ok ]
 * Starting elogind ...
 [ ok ]
 [snip ...]
 
 * Create Volatile Files and Directories ...
 [ ok ]

rc boot logging stopped at Fri Aug  4 16:21:41 2023


rc default logging started at Fri Aug  4 16:21:41 2023

 * Starting chronyd ...
 [ ok ]
 * Setting up dm-crypt mappings ...
 *   home using:open /dev/sda9 home ...
 [ ok ]
 [ ok ]
 * Checking your configfile (/etc/syslog-ng/syslog-ng.conf) ...
 [ ok ]
 * Starting syslog-ng ...
 [ ok ]
 * Starting cronie ...
 [ ok ]
 * Initializing sensors ...
 [ ok ]
 * Starting DHCP Client Daemon ...
 [ ok ]
 * Mounting network filesystems ...
 [ ok ]
 * Starting local ...
 [ ok ]

rc default logging stopped at Fri Aug  4 16:21:59 2023
===

I don't fully understand why dmcrypt service does not wait for gpg to decrypt 
the key, but proceeds immediately to run 5 retries of the still unencrypted 
key and fails.  The relevant entry I have in /etc/conf.d/dmcrypt is:

# Definition for /dev/mapper/home (for /home)
target=home
source=UUID="3e9c0cff-6b09-4461-8679-6cb7fd9f55f3"
key='/etc/keys/enc.key.gpg:gpg'

Sakaki's installation guide with the buildkernel script created a 'staticgpg' 
file without pinentry, but this was for use in an initrd image and booting off 
a USB stick.  I assume this should not be needed for a non-initrd boot process 
- am I wrong?  What am I missing here?


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

Re: [gentoo-user] Problem loading r8169 kernel module

[Michael]

On Saturday, 5 August 2023 14:40:00 BST Peter Humphrey wrote:
> Hello list,
> 
> I decided to find out why the kernel had trouble loading the r8169 module on
> my Intel NUC server. I found
>  which seemed
> to tell me all I needed to know.
> 
> I got this result after installing sys-apps/fwts and running it:
> 
> -
> Test 1 of 2: PCIe ASPM ACPI test.
> PCIe ASPM is not controlled by Linux kernel.
> 
> ADVICE: BIOS reports that Linux kernel should not modify ASPM settings that
> BIOS configured. It can be intentional because hardware vendors identified
> some capability bugs between the motherboard and the add-on cards.
> -
> 
> The BIOS offered two choices:
> 
> PCIe ASPM support enable/disable
> Native ACPI OS PCIe Support   enable/disable
> 
> I've tried all four combinations of those settings and got almost the same
> result: the boot-up console output complained that the r8169 module couldn't
> be loaded because it was already in the kernel. (I think that's just a
> coder's assumption from the inability to load the module.)
> 
> The only tiny difference was in the fwts log: that PCIe ASPM was or was not
> controlled by the kernel.
> 
> Is there a way forward from here, or should I just ignore it and get on with
> life?

I don't have the same hardware to know how it is meant to behave, but it is 
reasonable to assume fwts will try to load/unload the driver to test it.  What 
do you get when you compile the driver as a module, to give a chance to the 
fwts to do its thing?

NOTE: I don't have the same hardware to know how it is meant to behave.

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

[gentoo-user] Problem loading r8169 kernel module

[Peter Humphrey]

Hello list,

I decided to find out why the kernel had trouble loading the r8169 module on my 
Intel NUC server. I found 
 which seemed to 
tell me all I needed to know.

I got this result after installing sys-apps/fwts and running it:

-
Test 1 of 2: PCIe ASPM ACPI test.
PCIe ASPM is not controlled by Linux kernel.

ADVICE: BIOS reports that Linux kernel should not modify ASPM settings that 
BIOS configured. It can be intentional because hardware vendors identified some
capability bugs between the motherboard and the add-on cards.
-

The BIOS offered two choices: 

PCIe ASPM support   enable/disable
Native ACPI OS PCIe Support enable/disable

I've tried all four combinations of those settings and got almost the same 
result: the boot-up console output complained that the r8169 module couldn't 
be loaded because it was already in the kernel. (I think that's just a coder's 
assumption from the inability to load the module.)

The only tiny difference was in the fwts log: that PCIe ASPM was or was not 
controlled by the kernel.

Is there a way forward from here, or should I just ignore it and get on with 
life?

-- 
Regards,
Peter.