Bug#845818: Re: Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2

[Martin Michlmayr]

Hi Heinrich,

* Heinrich Schuchardt  [2017-03-18 02:39]:
> U-Boot 2017-3 does not contain MMC support for the Odroid C2.
> I have seen a recent patch series for MMC support. But I did not yet
> build with it.

If they are accepted for 2017.05, maybe Vagrant could add them to the
2017.03 Debian package.

> You are right in that with MMC support in mainline u-boot we should be
> able to use a generic boot script.

Are you ok with the approach I proposed (i.e. requiring users to
install a new u-boot, which hopefully we'll have in Debian unstable at
some point) or would you prefer your original solution that works with
the built-in u-boot?  My worries are about supporting upgrades from
the original u-boot to mainline u-boot.  Going with the generic u-boot
approach would avoid this issue.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#855960: flash-kernel: Please add support for NETGEAR ReadyNAS Duo v2

[Martin Michlmayr]

* Scott Barker  [2017-03-17 17:47]:
> I know the db entry for the NETGEAR ReadyNAS Duo v2 is missing from this
> installer image, which is the one I've been using:

Yeah, I just added the db entry to git.  It's not even in the archive
yet.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#855960: flash-kernel: Please add support for NETGEAR ReadyNAS Duo v2

[Scott Barker]

I know the db entry for the NETGEAR ReadyNAS Duo v2 is missing from this
installer image, which is the one I've been using:

  
http://ftp.debian.org/debian/dists/jessie/main/installer-armel/20150422+deb8u4+b2/images/kirkwood/netboot/marvell/openrd/uInitrd

On Fri, Mar 17, 2017 at 04:28:46PM -0700, Martin Michlmayr wrote:
> * Scott Barker  [1969-12-31 17:52]:
> > Please add suuport for NETGEAR ReadyNAS Duo v2. The db entry that works for 
> > me is:
> 
> Thanks, I added this in git.
> 
> Do we also have to create any installation images in debian-installer?
> 
> -- 
> Martin Michlmayr
> http://www.cyrius.com/

-- 
Scott Barker

Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2

[Martin Michlmayr]

* Heinrich Schuchardt  [2016-11-26 22:57]:
> As mainline u-boot support is still under construction boot.scr
> is build such that the stock u-boot can execute it.

As you know, I added your prerequisite patch but I never added this
patch and didn't explain why (apart from hoping someone else would
take ownership).

Basically, it seems to me like an hack to add this specific boot
script when work is going on to support Odroid-C2 properly upstream.

I don't have such a device, but I looked at the u-boot list a few
weeks ago and it seems there has been a lot of progress recently.

So I'm wondering whether this approach makes sense:

* In flash-kernel, add an entry that uses the generic boot script
* Get an u-boot-armlogic (or whatever) package into unstable using 2017.03
* Document the install process on wiki.deban.org, i.e. take the u-boot
  from unstable and then install stable.

What do you think about this approach?  Do you know how well u-boot
2017.03 works on this device?

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#855960: flash-kernel: Please add support for NETGEAR ReadyNAS Duo v2

[Martin Michlmayr]

* Scott Barker  [1969-12-31 17:52]:
> Please add suuport for NETGEAR ReadyNAS Duo v2. The db entry that works for 
> me is:

Thanks, I added this in git.

Do we also have to create any installation images in debian-installer?

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#839595: flash-kernel: Please add support for SolidRun Clearfog

[Martin Michlmayr]

* Christoph Egger  [2016-12-27 17:55]:
> Christoph Egger  writes:
> > I haven't updated u-boot yet, though it's still on my todo
> 
> Seems to have worked. I have now u-boot 2016-11 SPL and "normal"
> u-boot and everything works so far \o/

Karsten, I think this one is waiting for you.  Can you take a look?

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#855965: libdebian-installer: Please add support for NETGEAR ReadyNAS Duo v2

[Martin Michlmayr]

* Scott Barker  [1969-12-31 18:48]:
> Please add support for NETGEAR ReadyNAS Duo v2, which uses a "kirkwood" 
> processor:

Thanks, I added this patch.

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: 8.8 planning

[Adam D. Barratt]

On Tue, 2017-03-14 at 12:00 +0100, Julien Cristau wrote:
> It's time to start thinking about our next stable point release.  Here
> are some dates, please let us know which ones would work.
> 
> * April 8-9
> * April 15-16
> * April 22-23
> * April 29-30
> * May 6-7
> 
> I know at least Adam can't do 15-16 so that one is most likely out anyway.

For completeness, any of the other dates currently work for me.

Cheers,

Adam

Re: 8.8 planning

[Laura Arjona Reina]

Hi

El 14/03/17 a las 12:00, Julien Cristau escribió:
> It's time to start thinking about our next stable point release.  Here
> are some dates, please let us know which ones would work.
> 
> * April 8-9
> * April 15-16

Not sure, but could be

> * April 22-23
> * April 29-30
> * May 6-7

Those, at least two people from publicity are available.

> 
> I know at least Adam can't do 15-16 so that one is most likely out anyway.
> 
> Cheers,
> Julien
> 

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Miguel Hermanns]

I don't have them, sorry :-(

Sadly, I cannot reproduce the error for you, since the computer is already
in use now.

On Fri, Mar 17, 2017 at 5:54 PM, Steve McIntyre  wrote:

> On Fri, Mar 17, 2017 at 05:37:07PM +0100, Miguel Hermanns wrote:
> >No other OS installed and I did not get that message.
> >
> >I'm using an NVMe Samsung 960 EVO drive for / and swap, and a traditional
> >WD Red for /home. I don't know if that may have an influence.
>
> OK, this is weird. :-/
>
> I don't suppose you kept the installation logs from the first
> installation attempt? I can't explain the differences in what we're
> seeing, and they would help.
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "You can't barbecue lettuce!" -- Ellie Crane
>
>

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Steve McIntyre]

On Fri, Mar 17, 2017 at 05:37:07PM +0100, Miguel Hermanns wrote:
>No other OS installed and I did not get that message.
>
>I'm using an NVMe Samsung 960 EVO drive for / and swap, and a traditional
>WD Red for /home. I don't know if that may have an influence.

OK, this is weird. :-/

I don't suppose you kept the installation logs from the first
installation attempt? I can't explain the differences in what we're
seeing, and they would help.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Miguel Hermanns]

No other OS installed and I did not get that message.

I'm using an NVMe Samsung 960 EVO drive for / and swap, and a traditional
WD Red for /home. I don't know if that may have an influence.

Best regards,

Miguel


On Fri, Mar 17, 2017 at 5:20 PM, Steve McIntyre  wrote:

> On Fri, Mar 17, 2017 at 05:03:17PM +0100, Miguel Hermanns wrote:
> >Dear Steve,
> >
> >It was the first time I installed something in EFI mode, as in the past I
> >always switched back to legacy mode. So I'm quite sure I booted in EFI
> >mode.
> >
> >After the installation and seeing that the computer was not booting, I
> >started to research in the internet and found the Debian installation
> guide
> >I mention in the bug report. After that I started to understand what was
> >going wrong and I installed again Debian from scratch and without changing
> >anything in the BIOS. But this time I allowed partman to do a guided
> >partitioning, which I afterwards tuned to my needs. Partman of course
> >included the EFI boot partition, and this time everything went fine.
>
> OK, I'm struggling to reproduce this here. I've just started 2 test
> EFI installations in a VM. Create just a single filesystem on a blank
> disk with no ESP and I get
>
>   No EFI partition was found.
>
>   Go back to the menu and resume partitioning?
>
> when I say "Finish partitioning". Was there any other OS installed
> already on the system?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> Google-bait:   http://www.debian.org/CD/free-linux-cd
>   Debian does NOT ship free CDs. Please do NOT contact the mailing
>   lists asking us to send them to you.
>
>

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Steve McIntyre]

On Fri, Mar 17, 2017 at 05:03:17PM +0100, Miguel Hermanns wrote:
>Dear Steve,
>
>It was the first time I installed something in EFI mode, as in the past I
>always switched back to legacy mode. So I'm quite sure I booted in EFI
>mode.
>
>After the installation and seeing that the computer was not booting, I
>started to research in the internet and found the Debian installation guide
>I mention in the bug report. After that I started to understand what was
>going wrong and I installed again Debian from scratch and without changing
>anything in the BIOS. But this time I allowed partman to do a guided
>partitioning, which I afterwards tuned to my needs. Partman of course
>included the EFI boot partition, and this time everything went fine.

OK, I'm struggling to reproduce this here. I've just started 2 test
EFI installations in a VM. Create just a single filesystem on a blank
disk with no ESP and I get

  No EFI partition was found.

  Go back to the menu and resume partitioning?

when I say "Finish partitioning". Was there any other OS installed
already on the system?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Miguel Hermanns]

Dear Steve,

It was the first time I installed something in EFI mode, as in the past I
always switched back to legacy mode. So I'm quite sure I booted in EFI
mode.

After the installation and seeing that the computer was not booting, I
started to research in the internet and found the Debian installation guide
I mention in the bug report. After that I started to understand what was
going wrong and I installed again Debian from scratch and without changing
anything in the BIOS. But this time I allowed partman to do a guided
partitioning, which I afterwards tuned to my needs. Partman of course
included the EFI boot partition, and this time everything went fine.

Best regards,

Miguel

On Fri, Mar 17, 2017 at 3:57 PM, Steve McIntyre  wrote:

> On Fri, Mar 17, 2017 at 03:20:33PM +0100, Miguel Hermanns wrote:
> >Package: partman-efi
> >Version: 75
> >Severity: important
> >
> >Dear Maintainer,
> >
> >When installing debian stretch RC2, manual partitioning was done without
> >specifying an EFI boot partition. This did not trigger an error message
> >by partman, although according to section 6.3.3.3 of the installation
> >guide it should have done so.
>
> Hi Miguel,
>
> That's how the code has worked for me in the past, and it's not
> changed in quite a while. Are you sure you booted in EFI mode?
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
> "When C++ is your hammer, everything looks like a thumb." -- Steven M.
> Haflich
>
>

Bug#785149: patch working (and missing) on jessie

[geoffroy desvernay]

Hi all,

Found this bug after trying to install "as usual" (network preseed) new
machines here.

Just to report that patching /usr/bin/grub-installer manually in d-i
works (and resulting debian works flawlessly with standard kernel)

Do you think backporting this to jessie will take time ? It would allow
me not to replace ~30 working disks on new machines :-/

Anyway, thank you all for inputs here !!
-- 
*geoffroy desvernay*
C.R.I - Administration systèmes et réseaux
Ecole Centrale de Marseille




signature.asc
Description: OpenPGP digital signature

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Steve McIntyre]

On Fri, Mar 17, 2017 at 03:20:33PM +0100, Miguel Hermanns wrote:
>Package: partman-efi
>Version: 75
>Severity: important
>
>Dear Maintainer,
>
>When installing debian stretch RC2, manual partitioning was done without
>specifying an EFI boot partition. This did not trigger an error message
>by partman, although according to section 6.3.3.3 of the installation
>guide it should have done so. 

Hi Miguel,

That's how the code has worked for me in the past, and it's not
changed in quite a while. Are you sure you booted in EFI mode?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#858029: partman-efi: Manual partinioning in EFI system without EFI boot partition does not trigger an error message

[Miguel Hermanns]

Package: partman-efi
Version: 75
Severity: important

Dear Maintainer,

When installing debian stretch RC2, manual partitioning was done without
specifying an EFI boot partition. This did not trigger an error message
by partman, although according to section 6.3.3.3 of the installation
guide it should have done so. 

The result was that the computer was unable to boot after the
first stage of the installation.




-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#818065: live-config / console-setup issue

[Anton Zinoviev]

On Fri, Mar 17, 2017 at 08:17:42AM +0100, Jörn Heissler wrote:
> 
> It appears to me that "Set console font and keymap" is done before
> live-config regenerates the files.

I think this explains the bug.

Anton Zinoviev

Bug#858009: Debian "Full Disk Encryption" is a misnomer, /boot not encrypted, Evil Maid attacks, enable grub cryptodisk, improve guided encrypted partitioning

[of....@protonmail.com]

Package: debian-installer
Version: stretch-rc2

The Debian Stretch RC2 installer and previous versions do not allow Full Disk 
Encryption since /boot is more vulnerable to Evil Maid attacks due to it being 
unencrypted. Securing /boot makes Evil Maid attacks slightly more difficult, 
raising the cost / time for an adversary with physical access.

I suggest looking at prior bugs from over a year ago suggesting how to start 
fixing this by enabling the cryptodisk option for grub, then modifying the 
debian-installer flows to automatically partition using a base encrypted volume 
for which all other partitions / LVM2 groups sit atop of, including /boot. This 
would hopefully replace the current and slightly more insecure "Guided - Use 
Entire Disk and Set Up Encrypted LVM..." option.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814798

Tested Debian Stretch RC2 and prior versions.

Bug#818065: live-config / console-setup issue

[Jörn Heissler]

On Thu, Mar 16, 2017 at 07:03:04PM +0200, Anton Zinoviev wrote:
> ls --full-time /etc/console-setup/cached* /etc/default/console-setup 
> /etc/default/keyboard

This is from a configuration where I hard coded the two files in
/etc/default/ and did not set the keyboard parameters elsewhere.
Files in /etc/default/ aren't overwritten in the booted system (i.e.
looks same in booted system):
-rw-r--r-- root/root  4024 2017-03-17 06:50 
squashfs-root/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- root/root  4147 2017-03-17 06:50 
squashfs-root/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rwxr-xr-x root/root   471 2017-03-17 06:50 
squashfs-root/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x root/root   174 2017-03-17 06:50 
squashfs-root/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x root/root73 2017-03-17 06:50 
squashfs-root/etc/console-setup/cached_setup_terminal.sh
-rw-rw-r-- root/root   136 2017-03-14 09:47 
squashfs-root/etc/default/console-setup
-rw-rw-r-- root/root   172 2017-03-12 17:39 squashfs-root/etc/default/keyboard


Same image, but this time I set on kernel command line:
locales=de_DE.UTF-8 keyboard-layouts=de keyboard-variants=nodeadkeys
The file date is newer, still keyboard layout not set.
-rw-rw-r-- 1 root root  136 2017-03-14 09:47:49.0 +0100 console-setup
-rw-rw-r-- 1 root root  172 2017-03-17 07:12:20.128082454 +0100 keyboard
-rwxr-xr-x 1 root root  471 2017-03-17 06:50:38.0 +0100 
/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 06:50:38.0 +0100 
/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 06:50:38.0 +0100 
/etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 06:50:38.0 +0100 
/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 06:50:38.0 +0100 
/etc/console-setup/cached_UTF-8_del.kmap.gz


I made a new image, without the hard coded keyboard + console-setup files.

Contents in squashfs:
"keyboard" has XKBLAYOUT="us", so not what I want.
-rwxr-xr-x 1 root root  471 2017-03-17 07:11:05.0 +0100 
squashfs-root/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 07:11:05.0 +0100 
squashfs-root/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 07:11:05.0 +0100 
squashfs-root/etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 07:11:04.0 +0100 
squashfs-root/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 07:11:04.0 +0100 
squashfs-root/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- 1 root root  285 2017-03-17 07:11:04.0 +0100 
squashfs-root/etc/default/console-setup
-rw-r--r-- 1 root root  150 2017-03-17 07:10:59.0 +0100 
squashfs-root/etc/default/keyboard


After I boot (still same kernel command line parameters):
-rwxr-xr-x 1 root root  471 2017-03-17 07:11:05.0 +0100 
/etc/console-setup/cached_setup_font.sh
-rwxr-xr-x 1 root root  174 2017-03-17 07:11:05.0 +0100 
/etc/console-setup/cached_setup_keyboard.sh
-rwxr-xr-x 1 root root   73 2017-03-17 07:11:05.0 +0100 
/etc/console-setup/cached_setup_terminal.sh
-rw-r--r-- 1 root root 4147 2017-03-17 07:11:04.0 +0100 
/etc/console-setup/cached_Uni2-Fixed16.psf.gz
-rw-r--r-- 1 root root 4024 2017-03-17 07:11:04.0 +0100 
/etc/console-setup/cached_UTF-8_del.kmap.gz
-rw-r--r-- 1 root root  285 2017-03-17 07:11:04.0 +0100 
/etc/default/console-setup
-rw-r--r-- 1 root root  160 2017-03-17 07:18:22.112087333 +0100 
/etc/default/keyboard


Here is an excerpt from /var/log/syslog:
Mar 17 07:18:24 localhost systemd[1]: Reached target Local File Systems.
Mar 17 07:18:24 localhost systemd[1]: Starting live-config contains the 
components that configure a live system during the boot process (late 
userspace)
Mar 17 07:18:24 localhost systemd[1]: Starting Create Volatile Files and 
Directories...
Mar 17 07:18:24 localhost systemd[1]: Starting Raise network interfaces...
Mar 17 07:18:24 localhost systemd[1]: Starting Set console font and keymap...
Mar 17 07:18:24 localhost systemd[1]: Started Create Volatile Files and 
Directories.
Mar 17 07:18:24 localhost systemd[1]: Starting Update UTMP about System 
Boot/Shutdown...
Mar 17 07:18:24 localhost systemd[1]: Starting Network Time Synchronization...
Mar 17 07:18:24 localhost systemd[1]: Started Set console font and keymap.
Mar 17 07:18:24 localhost systemd[1]: Started Update UTMP about System 
Boot/Shutdown.
Mar 17 07:18:24 localhost systemd[1]: Started Network Time Synchronization.
Mar 17 07:18:24 localhost systemd[1]: Reached target System Time Synchronized.
Mar 17 07:18:24 localhost live-config[393]: live-config: debconf hostnameDevice 
"eth0" does not exist.
Mar 17 07:18:24 localhost live-config[393]: Device "eth0" does not exist.
Mar 17 07:18:24 localhost live-config[393]: