Bug#919813: comparison with earlier release

[Steve McIntyre]

On Sun, Jan 20, 2019 at 10:25:54AM -0500, Hendrik Boom wrote:
>Just for comparison, on Devuan ascii (stretch wirhout systend), I get:
>
>root@midwinter:/home/hendrik# os-prober
>File descriptor 8 (socket:[13898]) leaked on lvs invocation. Parent PID 2831: 
>/bin/sh
>File descriptor 9 (socket:[13899]) leaked on lvs invocation. Parent PID 2831: 
>/bin/sh
>File descriptor 10 (socket:[16454]) leaked on lvs invocation. Parent PID 2831: 
>/bin/sh
>File descriptor 11 (socket:[16455]) leaked on lvs invocation. Parent PID 2831: 
>/bin/sh
>File descriptor 18 (socket:[13991]) leaked on lvs invocation. Parent PID 2831: 
>/bin/sh
>/dev/sda6:Debian GNU/Linux buster/sid:Debian:linux
>root@midwinter:/home/hendrik# 
>
>Here it also does not recognise the OS it runs on, but it *does* recognise
>Debian.
>
>Could the problem be that it is does not recognise
>  (a) its own OS, nor

os-prober is not supposed to find the OS it's running under, that's
the design. It's only looking for other OS installations.

>  (b) any OS those root partition in on an LVM volume, even if its /boot
>  is on a primary partition?

It should happily find such setups. One of my own test systems at home
has root on LVM, no issues.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Bug#802179: debian-installer: wrong numeration of dmraid device

[Ryan Goodfellow]

I have hit this behavior in the debian-buster-alpha4 installer as
well. Exact same issue. I setup a RAID1 in the installer and then
installed the base system. In the Grub dialog I choose the first disk,
let's call it /dev/sda to install Grub on. Then the installer goes and
tries to install grub on /dev/md. Manually entering /dev/sda is a
workaround and I confirm that the newly installed system boots
afterwords.

-- 
~ ry

Re: Multiple console support in d-i

[Steve McIntyre]

On Sat, Jan 19, 2019 at 01:16:43PM +, Ian Campbell wrote:
>On Sat, 2019-01-19 at 11:08 +, Steve McIntyre wrote:
>> >So far I have done a proof-of-concept hack and demonstrated that
>> >running two instances does in fact work nicely without anything
>> >obvious breaking. The console selection still needs some work/checking
>> >(I've run out of time for that tonight, but it can easily be fished
>> >out of the kernel command line args. (or we could get fancier).
>> 
>> Nod. Potentially we might end up of running on multiple
>> consoles.
>
>IIRC (and it hasn't changed in the years since I knew this stuff) we
>already have this on some of the netconsole install images for
>arm{el,hf}, you end up with an installer on serial and one on the ssh
>connection. Not an identical situation since I think the second one is
>only spawned when you login via ssh, but some sort of precedence I
>guess!

Yup, the netconsole case was exactly my inspiration for going down
this route. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me 

Re: Multiple console support in d-i

[Steve McIntyre]

On Sun, Jan 20, 2019 at 03:02:33AM +, Ben Hutchings wrote:
>On Sun, 2019-01-20 at 01:21 +, Wookey wrote:

...

>> My current code leaves all this alone and just records/uses all
>> enabled consoles on the command line, not just the last one, but
>> ideally we'd autodetect and/or hardcode all the sensible available
>> consoles and run on them.
>> 
>> If 'read /proc/consoles (and check the devices exist)' does this, then
>> that sounds very sensible.
>
>Reading /proc/consoles is exactly what you should do.

Aha, thanks! I genuinely wasn't aware of /proc/consoles, and it does
sound like exactly the right thing to be looking at. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back

Re: Multiple console support

[Steve McIntyre]

On Sat, Jan 19, 2019 at 02:38:46PM +, peter green wrote:
>On 19/01/19 04:27, Wookey wrote:
>> 
>> Steve (McIntyre) and I have been thinking about what to do about this,
>> so did some investigation and came up with a plan. Essentially it was
>> to run d-i on both if they are configured/available. This way anyone
>> looking at just one or the other will see D-I as they expect. The
>> patch is not intrusive and essentially nothing changes if there is
>> only one console so this should be a low-risk change.
>
>One concern I would have is preseeding or other more-automated
>install modes. Presumablly this works out ok on a "normal" install
>because the instance of the installer that the user is *NOT*
>interacting with just sits there doing nothing but I would question
>if that is a reasonable assumption in general.

Ah, yes. Definitely worth checking on once we have something up and
running. We might need to make sure that only one of the running d-i
instances works like this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Re: Multiple console support

[Steve McIntyre]

On Sun, Jan 20, 2019 at 01:08:24AM +1300, Richard Hector wrote:
>On 19/01/19 5:27 PM, Wookey wrote:
>> This problem doesn't arise on x86 where there is 'always' a screen (or
>> some BIOs magic to reflect what would be on the screen to serial).
>
>Is that true? I'm sure the Soekris box I've got (in storage)
>(admittedly, probably not a supported cpu any more) only has serial. And
>only server-class machines generally do the redirection, don't they?
>There are plenty of use cases for a headless machine that doesn't need
>to be expensive, where serial would be useful and a screen inconvenient.
>
>Is there a disadvantage to doing the same thing on all arches?

Good question! :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.

Re: UEFI Secure Boot changes in d-i and live images

[Steve McIntyre]

On Sun, Jan 20, 2019 at 12:35:16AM +, Ben Hutchings wrote:
>On Sun, 2019-01-20 at 00:16 +0100, Philipp Kern wrote:
>> Hi,
>> 
>> On 2019-01-13 20:23, Steve McIntyre wrote:
>[...]
>> > I'll test all these again in the next couple of days to verify that
>> > things have pulled through as I expect, then it's time to post to
>> > d-d-a and write a blog too. We've made great progress already. These
>> > last changes just tie it all together for end users.
>> 
>> I just tried to test this. As far as I can see grub is still signed by 
>> "secure-boot-test-key-lfaraone" as of netinst from yesterday (Saturday). 
>[...]
>
>Yes, this is expected.

Yup. I'd *thought* I'd tested end-to-end with a clean machine, but it
looks like I fat-fingered the mok key removal and still had Luke's
test key installed. I've just forced cleanup now and retested and I
see the same behaviour as Philipp.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I've only once written 'SQL is my bitch' in a comment. But that code 
 is in use on a military site..." -- Simon Booth

Re: Import eject into Salsa

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi all,
> 
> is someone willing to help migrating eject source to Salsa?
> 
> Currently there is no debian repository for eject, and d-i depends on its 
> udeb.
> 
> 
> It can be imported from
> https://alioth-archive.debian.org/git/collab-maint/eject.git.tar.xz
> and should be added to 'debian' namespace on Salsa (analogous to collab-maint
> on Alioth).

Hmm, I should have CC'ed djpig as maintainer... (now done)
Even though I'm unsure if he is still that active these days... 
And I had also filed a bugreport for this already:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901714


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Import eject into Salsa

[Holger Wansing]

Hi all,

is someone willing to help migrating eject source to Salsa?

Currently there is no debian repository for eject, and d-i depends on its udeb.


It can be imported from
https://alioth-archive.debian.org/git/collab-maint/eject.git.tar.xz
and should be added to 'debian' namespace on Salsa (analogous to collab-maint
on Alioth).



Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: live-installer_57_amd64.changes ACCEPTED into unstable

[Holger Wansing]

Hi Jonathan,

Debian FTP Masters  wrote:
> 
> 
> Accepted:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Format: 1.8
> Date: Thu, 17 Jan 2019 14:03:40 +0200
> Source: live-installer
> Binary: live-installer
> Architecture: source amd64
> Version: 57
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Install System Team 
> Changed-By: Jonathan Carter 
> Description:
>  live-installer - Install the system (udeb)
> Changes:
>  live-installer (57) unstable; urgency=medium
>  .
>* Add calamares-settings-debian as packaged to be removed at
>  the end of installation
>* Add self to uploaders
>* Update standards-version to 4.3.0
>* Run wrap-and-sort

friendly reminder:
maybe you forgot to add a tag for this release? 
https://salsa.debian.org/installer-team/live-installer/tags

Thanks


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#919813: comparison with earlier release

[Hendrik Boom]

Just for comparison, on Devuan ascii (stretch wirhout systend), I get:

root@midwinter:/home/hendrik# os-prober
File descriptor 8 (socket:[13898]) leaked on lvs invocation. Parent PID 2831: 
/bin/sh
File descriptor 9 (socket:[13899]) leaked on lvs invocation. Parent PID 2831: 
/bin/sh
File descriptor 10 (socket:[16454]) leaked on lvs invocation. Parent PID 2831: 
/bin/sh
File descriptor 11 (socket:[16455]) leaked on lvs invocation. Parent PID 2831: 
/bin/sh
File descriptor 18 (socket:[13991]) leaked on lvs invocation. Parent PID 2831: 
/bin/sh
/dev/sda6:Debian GNU/Linux buster/sid:Debian:linux
root@midwinter:/home/hendrik# 

Here it also does not recognise the OS it runs on, but it *does* recognise
Debian.

Could the problem be that it is does not recognise
  (a) its own OS, nor
  (b) any OS those root partition in on an LVM volume, even if its /boot
  is on a primary partition?

-- hendrik

Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file

[OGAWA Hirofumi]

bash-5.0 fixed the nanosecond timestamp compare bug.  So, in the case of
/bin/sh == /bin/bash, this will be fixed.
-- 
OGAWA Hirofumi 

Re: UEFI Secure Boot changes in d-i and live images

[Bastian Blank]

On Sun, Jan 20, 2019 at 12:35:16AM +, Ben Hutchings wrote:
> Yes, this is expected.  Does anyone want to implement the proposal I
> made at 
> or are we just going to have a flag day and hope no-one screws up after
> that?

The FTP team aggreed on this solution.[1]

Bastian

[1]: http://meetbot.debian.net/debian-ftp/2019/debian-ftp.2019-01-11-19.58.html
-- 
Power is danger.
-- The Centurion, "Balance of Terror", stardate 1709.2