Re: Bug#886968: btrfs-progs-udeb: depends on non-udeb: libzstd1

[Nicholas D Steeves]

On Mon, Jan 15, 2018 at 02:20:28PM +, Dimitri John Ledkov wrote:
> On 15 January 2018 at 00:27, Cyril Brulebois  wrote:
> > Hi,
> >
> > Cyril Brulebois  (2018-01-12):
> >> Your package is no longer installable (along with its rev-dep
> >> partman-btrfs) because it now depends on libzstd1, which isn't
> >> a udeb.
> >
> > It seems zstd is only an option for btrfs-progs, and I've just confirmed
> > that setting --disable-zstd on the dh_auto_configure line lets btrfs-progs
> > build just fine, without the libzstd1 dependency. As far as I can tell,
> > there's no absolute need for this feature in d-i, and we could consider
> > building the udeb without zstd support, instead of requesting the addition
> > of a libzstd1-udeb. What do you think?
> >
> 
> That's an oversight on my part. From the recovery point of view, it
> would be desired to have zstd compression support built-into
> btrfs-progs-udeb such that one can use d-i recovery mode to
> backup/restore btrfs filesystems with zstd compression.
> 
> -- 
> Regards,
> 
> Dimitri.

Hi Cyril! 

I agree that it's not essential for d-i; although, it's worth
mentioning that zstd seems like it will more likely satisfy users who
are coming from zfs' "lz4 compression is usually beneficial" school of
thought than lzo will.

Dmitri, does btrfs send/receive actually require userspace libzstd?
Or is it needed for defrag? (rewrites files, and also optionally
applies, removes, or changes compression type) I'm guessing that
btrfs-check requires it. (check --repair is, broadly speaking,
equivalent to 'fsck.ext4 -p')

The worst-case d-i bloat for an official arch seems to be 193.4kB for
i386, before compression.  Would you please 'reassign -1 libzstd' if
you agree that Debian's rescue mode should support cloning/restoring
subvolumes with compressed files, and/or being able to repair the
(unmounted) rootfs?  It seems strange that buster's initramfs has this
functionality and that rescue mode doesn't.  Alternatively, the btrfs
binary in the udeb could be statically linked...

Thanks,
Nicholas


signature.asc
Description: PGP signature

Bug#890262: (no subject)

[Martin Michlmayr]

* Arthur  [2018-02-21 23:03]:
> I now have another problem (should I file another bugs?), openning up

These are different issues so please don't follow up here.

Let's continue this on the thread on debian-arm:
https://lists.debian.org/debian-arm/2018/02/msg00086.html

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

Bug#872577: debootstrap: Handle existing /dev

[Geert Stappers]

On Thu, Feb 22, 2018 at 06:26:32AM -0600, Dan Nicholson wrote:
> On Wed, 22 Nov 2017 05:08:47 -0600 Dan Nicholson  wrote:
> > On Fri, Aug 25, 2017 at 4:07 PM -0600, Dan Nicholson 
> >  > 
> > Ping? Patch is pretty straightforward, but I'd be happy to adjust any
> > direction people like.
> 
> Ping? It seemed like people were interested in having this change. Happy
> to change the patch in whatever way anyone wants or just step aside and
> let one of the maintainers fix it the way they want.
 
Pong.
Bugreport has several patches, is tagged with 'patch'

@Dan: If you want maintaining debootstrap, just tell.
  We will find a way for doing the upload to Debian archive.


Groeten
Geert Stappers
DD
-- 
Leven en laten leven

Bug#891113: Mostly successful install of buster Alpha 2 on Lenovo Yoga 720

[Jonathan McDowell]

Package: installation-reports
Severity: minor



-- Package-specific info:

Boot method: USB drive
Image version: debian-buster-DI-alpha2-amd64-netinst.iso
Date: 2018-02-19

Machine: Lenovo Yoga 720-13IKB
Partitions:

Device StartEnd   Sectors   Size Type
/dev/nvme0n1p1  2048 534527532480   260M EFI System
/dev/nvme0n1p2534528 567295 3276816M Microsoft reserved
/dev/nvme0n1p3567296  410298367 409731072 195.4G Microsoft basic data
/dev/nvme0n1p4 945737728  998166527  5242880025G Microsoft basic data
/dev/nvme0n1p5 998166528 1000214527   2048000  1000M Windows recovery environmen
/dev/nvme0n1p6 410298368  412252159   1953792   954M Linux filesystem
/dev/nvme0n1p7 412252160  945737727 533485568 254.4G Linux LVM

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[E]
Overall install:[O]

Comments/Problems:

Initial problems getting the installer to boot; grub would load the
kernel + ramdisk and then there would be no further output - it wasn't
clear if the kernel had started, but not printed anything, or hadn't
started at all. Saw the same issue with a SystemRescueCD image so not
specific to Debian. Enabling Legacy Boot in the BIOS (but still booting
via EFI) allowed the installer to start correctly.

Wifi needed the firmware-iwlwifi package but worked fine with that.

Boot loader installation was not successful. efibootmgr showed the grub
entry as being created, but the laptop continued to boot directly to
Windows. The list of installed boot managers in the BIOS only showed the
Windows install. I ended up adding the grub menu entry using bcdedit
from within the Windows install.

So far since boot everything seems to be working; installed
firmware-misc-nonfree for the Skylake graphics firmware (worked without
it, but I understand is necessary for better power management). External
monitor over USB3/thunderbolt port works fine. Battery life (so far)
seems good. Haven't managed to get the fingerprint reader working but
haven't tried more than installing fprint and seeing if it detected it.

More details at
https://www.earth.li/~noodles/blog/2018/02/yoag720-linux.html

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20171204"
X_INSTALLATION_MEDIUM=hd-media

==
Installer hardware-summary:
==
uname -a: Linux eris 4.13.0-1-amd64 #1 SMP Debian 4.13.13-1 (2017-11-16) x86_64 
GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] 
(rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3813]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device 
[8086:5916] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3988]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Skylake Processor Thermal Subsystem [8086:1903] (rev 02)
lspci -knn: Subsystem: Lenovo Device [17aa:3807]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP 
USB 3.0 xHCI Controller [8086:9d2f] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:383e]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Thermal subsystem [8086:9d31] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:3831]
lspci -knn: 00:15.0 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #0 [8086:9d60] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:3836]
lspci -knn: 00:15.1 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #1 [8086:9d61] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:3837]
lspci -knn: 00:15.2 Signal processing controller [1180]: Intel Corporation 
Sunrise Point-LP Serial IO I2C Controller #2 [8086:9d62] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:380c]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Sunrise 
Point-LP CSME HECI #1 [8086:9d3a] (rev 21)
lspci -knn: Subsystem: Lenovo Device [17aa:383d]
lspci 

Bug#872577: debootstrap: Handle existing /dev

[Dan Nicholson]

On Wed, 22 Nov 2017 05:08:47 -0600 Dan Nicholson  wrote:
> On Fri, Aug 25, 2017 at 4:07 PM, Dan Nicholson 
> wrote:
> 
> > On Tue, Aug 22, 2017 at 10:23 AM, Dan Nicholson 
> > wrote:
> > >
> > > That certainly helps, but it doesn't cover everything since the
> > > mkdir's and ln's could fail. Those are easier to handle by adding
-p
> > > and -f, respectively, but that's a subtle change in behavior for
ln
> > > relative to the mknod change. In the mknod case, an existing
device is
> > > left as is. In the ln case, it would be forcefully overwritten.
> >
> > Attached is a patch to handle all the potentially failing cases. I
> > tested this by running debootstrap once, wiping everything the
target
> > except /dev, and running debootstrap again. It succeeded. As
mentioned
> > above, an existing device is skipped while the symlinks are
forcefully
> > overwritten. That seems inconsistent, but I'm not sure it matters. I
> > could easily change the mknod function to forcefully remove, too.
> >
> 
> Ping? Patch is pretty straightforward, but I'd be happy to adjust any
> direction people like.

Ping? It seemed like people were interested in having this change. Happy
to change the patch in whatever way anyone wants or just step aside and
let one of the maintainers fix it the way they want.

Re: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Yves-Alexis Perez]

control: tag -1 -patch
On Thu, 2018-02-22 at 09:20 +0100, Geert Stappers wrote:
> Bugreport tagged with 'patch',  hope this helps.

Hi,

There is no patch in that bug report. While copying the whole directory might
be doable, it's not the first solution we would consider, and it would
definitely need a lot more testing.

Regards,
-- 
Yves-Alexis

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

newer kernel supports new hardware

[Geert Stappers]

Package: debian-kernel-handbook

On Thu, Feb 22, 2018 at 09:20:22AM +0100, Geert Stappers wrote:
> On Thu, Feb 22, 2018 at 06:21:00AM +0200, Doru Iorgulescu wrote:
> > I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid/ to
> > /usr/ser/linux-4.9.82/drivers/scsi/megaraid/
> > I compile the kernel 4.9.82, and the result is OK!
> > 
> > It is possible a kernel patch for that ?
> 
>:-)
> 
> I think that question is some what crippled by a language problem 
> or another source for misunderstanding.
> 

The question was raised
as https://lists.debian.org/debian-boot/2018/02/msg00339.html
and https://lists.debian.org/debian-kernel/2018/02/msg00194.html
and became https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891067

This bugreport against Debian kernel handbook is for asking 
to document what to do when new kernel supports new hardware.

That `make deb` builds a .deb which can be installed
with `dpkg -i ../linux-image-*.deb`

What the policy is about backporting and releasing new kernels in stable.
(See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890393 )


The idea, the wish, is that upon future simular questions
posted at d-kernel@l.d.o  and/or  d-boot@l.d.o. can be answered with:

  Please visit  URL=at=kernel=handbook for information what you can do


Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Patch for Backport of the Linux MegaRAID driver for SAS based RAID controllers for Debian Stretch

[Geert Stappers]

Control: tag -1 +patch

On Thu, Feb 22, 2018 at 06:21:00AM +0200, Doru Iorgulescu wrote:
> I copy /usr/src/linux-4.14.20/drivers/scsi/megaraid/ to
> /usr/ser/linux-4.9.82/drivers/scsi/megaraid/
> I compile the kernel 4.9.82, and the result is OK!

Bugreport tagged with 'patch',  hope this helps.


> It is possible a kernel patch for that ?

   :-)

I think that question is some what crippled by a language problem 
or another source for misunderstanding.



Groeten
Geert Stappers
-- 
Leven en laten leven