Bug#814343: Fwd: Bug#814343: Bug on scretch installation

[Hiroshi Ohkubo]

Forwarding.


-- Forwarded message --
From: Patrick Foubet 
Date: Wed, Mar 9, 2016 at 8:06 PM
Subject: Re: Bug#814343: Bug on scretch installation
To: Hiroshi Ohkubo 


Hi Hiroshi,

Yes, there is no problem in debian-testing-amd64-netinst.iso.
The bug has encountered in debian-stretch-DI-alpha5-i386-netinst.iso
and debian-stretch-DI-alpha5-amd64-netinst.iso

Regards.

Patrick

Le 7 mars 2016 à 06:23, Hiroshi Ohkubo  a écrit :

Hello,

Works fine: debian-testing-amd64-netinst.iso (daily, today)

=

Reproducible: debian-stretch-DI-alpha5-amd64-netinst.iso
(see log below)

Looks like a systemd upgrading issue.

We can continue the installation with:
   # chroot /target apt-get -fy install


syslog (full log attached)

Mar  7 01:07:42 in-target: dpkg: dependency problems prevent
configuration of systemd:
Mar  7 01:07:42 in-target:  systemd depends on libsystemd0 (=
228-2+b1); however:
Mar  7 01:07:42 in-target:   Version of libsystemd0:amd64 on system is 229-2.
Mar  7 01:07:42 in-target:  ifupdown (0.8.10) breaks systemd (<<
228-3~) and is installed.
Mar  7 01:07:42 in-target:   Version of systemd to be configured is 228-2+b1.
Mar  7 01:07:42 in-target:
Mar  7 01:07:42 in-target: dpkg: error processing package systemd (--configure):
Mar  7 01:07:42 in-target:  dependency problems - leaving unconfigured
(snip)
Mar  7 01:07:49 in-target: Errors were encountered while processing:
Mar  7 01:07:49 in-target:  systemd
(snip)
Mar  7 01:07:52 main-menu[186]: WARNING **: Configuring 'pkgsel'
failed with error code 100
Mar  7 01:07:52 main-menu[186]: WARNING **: Menu item 'pkgsel' failed.


Kind regards,

--
Hiroshi Ohkubo




Patrick Foubet

-- 
S.E.R.I.A.N.E.  http://www.seriane.fr/
79-81 avenue Danièle CASANOVA   tel : 06 52 90 49 70
Bâtiment C  fax : 01 49 60 84 57
94200 IVRY sur Seine



-- 
Hiroshi Ohkubo

Bug#817946: Installation of Debian 8.3 alongside another distro renders it unbootable

[Ben Hutchings]

On Sun, 2016-03-13 at 20:20 +0100, Philip Hands wrote:
> cpblpublic+deb...@gmail.com writes:
> 
> > 
> > Package: installation-reports
> > 
> > Version: 8.3
> > 
> > Hello. I just installed Debian 8.3 in a partition alongside Ubuntu 15.10 
> > on a Lenovo X230 Tablet.
> > 
> > 
> > Everything goes okay, and it claims that it writing the boot record should 
> > be safe and will preserve the Ubuntu 15.10 that it found.
> > 
> > However, upon rebooting, Ubuntu no longer boots. Its graphical booting 
> > sequence just hangs on the little logo with dots moving along.
> > 
> > In the terminal 1 screen, the following errors are reported:
> > 
> > tpm_tis  A TPM error (6) occurred atempting to read a pcr
> OK, so that's failing to talk to the TPM (Trusted Platform Module)
> 
> I'm guessing (not having tried any of this) that the problem is that
> Ubuntu had installed the secure boot shim and GRUB, and that stuff is
> somehow needed for the TPM to work properly, and that having overwritten
> that GRUB with Debian's, it won't work.
[...]

I think you're confusing Secure Boot with Trusted Boot.  Secure Boot
does not use a TPM, and it ensures the integrity of the core OS in the
face of remote attacks only.  Trusted Boot requires a TPM and ensures
integrity even in the face of physically present attackers that can
tamper with hardware (to some extent).

If integrity is lost, that should not prevent reading PCRs, but it
would prevent reading secrets (such as disk decryption keys) that are
stored in the TPM.  I would instead suspect one of the following:

1. The error in the tpm_tis driver has been there all along, is
harmless (because nothing is using the TPM), and the failure is
unrelated to this message.
2. The Ubuntu kernel behaves differently on this hardware depending on
whether it was booted 'cold' (from power-off) or 'warm' (reboot).
3. This is a regression in the tpm_tis driver in the Ubuntu kernel that
is unrelated to the upgrade.

Ben.

-- 
Ben Hutchings
If at first you don't succeed, you're doing about average.

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

flash-kernel_3.35+deb8u3_source.changes ACCEPTED into proposed-updates->stable-new, proposed-updates

[Debian FTP Masters]

Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 10 Mar 2016 20:30:19 +0100
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source
Version: 3.35+deb8u3
Distribution: stable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Uwe Kleine-König 
Description:
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Closes: 794265 813995
Changes:
 flash-kernel (3.35+deb8u3) stable; urgency=medium
 .
   [ Karsten Merker ]
   * Disable the use of modprobe and udevadm in the mtdblock() function
 while running the testsuite.
 .
   [ Ian Campbell ]
   * Use /dev/mtdN when flashing, rather than needlessly going through the
 mtdblock layer (which is problematic on some platforms/kernels).
 (Closes: #794265)
 .
   [ Uwe Kleine-König ]
   * use nandwrite when writing to nand flash. (Closes: #813995)
Checksums-Sha1:
 9513e75b4356dd139b83bd2803e9a38e9333db13 1521 flash-kernel_3.35+deb8u3.dsc
 8e3fd25cac663e1970160592288d6369a59d2d17 57300 flash-kernel_3.35+deb8u3.tar.xz
Checksums-Sha256:
 7709407aca324aac211d9253a7a07e8ac100e6348e6068fc32cfd5068a18b016 1521 
flash-kernel_3.35+deb8u3.dsc
 f3dc8e240a6b98c15013f64e0d7ef17b5fb4a1a729f085890debabeeaa1197d4 57300 
flash-kernel_3.35+deb8u3.tar.xz
Files:
 22ec45ca580314816eae50f0d0ca70b3 1521 utils optional 
flash-kernel_3.35+deb8u3.dsc
 4bef47671a27faa3a65a46edfd40a537 57300 utils optional 
flash-kernel_3.35+deb8u3.tar.xz

-BEGIN PGP SIGNATURE-

iQEcBAEBCgAGBQJW5HtbAAoJEMH8FHityuwJdHMH/2NSrfdsdithVLt3fe5x4J6F
bH0hPeMUTghYUp6JgiUPXUfwywM9ggnB/Rx7JgAcRQhaXoXLdAY5LtQ1hT3g2Wue
A6EnQAL15PUxrrkBq3KnJhavL/g+Z06K4fLSQ0bJ4U8qJDD7J0Q0ZAkyorSPvJue
pIoFWeP3o2LMgrngQcPmj6/z/RCG+R31tqLTQtFhVMr09Er8+wpPORedJaCOTor2
8aPd3jAqze7ZPWrGcYuHwnAvDcLxXgNoUWsdLFavC2bBpLsc7jBz4mJFiL/rSOoP
Us/RuTxDSLp0DnFhziwNLYNmFaef9Ra3gd/BD5AL/+l4NR6a5RDYELgbw1QLemQ=
=m28c
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

Bug#813995: marked as done (flashcp writes to nand without being aware of bad blocks)

[Debian Bug Tracking System]

Your message dated Sun, 13 Mar 2016 19:47:11 +
with message-id 
and subject line Bug#813995: fixed in flash-kernel 3.35+deb8u3
has caused the Debian Bug report #813995,
regarding flashcp writes to nand without being aware of bad blocks
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
813995: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813995
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: flash-kernel
Version: 3.35+deb8u2
Severity: critical
Justification: causes serious data loss
Control: block 806926 with -1

Hello,

when flash-kernel writes a kernel/initrd to NAND flash it uses plain
write(2) to /dev/mtdX (flash-kernel < 3.52) or flashcp
(flash-kernel >= 3.52). If the device being written to has bad blocks
these are tried to be erased and written by both approaches.

This results in a non-booting system at best. In general writing to bad
blocks can also affect other (otherwise good) blocks and so result in
loss of unrelated data. I never saw this in practise, but the
manufacturers of NAND flash say so.

I didn't check which machines are affected, but Netgear ReadyNAS 102/104
(which isn't in flash-kernel's database yet, but see below for the
obvious entry to add support for them and #806926) is affected and flash
kernel managed to break a ReadyNAS 102 already (non-permanently by good
fortune as far as I can tell up to now).
I guess there are several other machines affected though.

The right fix is to use nandwrite to write to NAND flash and only use
flashcp for NOR.

Something like

test -f /sys/class/mtd/mtdX/oobsize

could be used to detect if the device is NAND or NOR. But there might be
more reliable ways I'm not aware of.

I will debug/test a bit more with the broken rn102 (and its owner :-) to
maybe come up with a patch, but if someone beats me that's very welcome,
too.

Best regards
Uwe

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 3.16.0-4-armmp (SMP w/1 CPU core)
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)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  devio  1.2-1
ii  initramfs-tools0.120
ii  linux-base 3.5
ii  ucf3.0030

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2014.10+dfsg1-5

flash-kernel suggests no packages.

-- Configuration Files:
/etc/flash-kernel/db changed:
Machine: NETGEAR ReadyNAS 104
DTB-Id: armada-370-netgear-rn104.dtb
DTB-Append: yes
Mtd-Kernel: uImage
Mtd-Initrd: minirootfs
U-Boot-Kernel-Address: 0x0400
U-Boot-Initrd-Address: 0x0500
Required-Packages: u-boot-tools


-- debconf information:
  flash-kernel/linux_cmdline: quiet
--- End Message ---
--- Begin Message ---
Source: flash-kernel
Source-Version: 3.35+deb8u3

We believe that the bug you reported is fixed in the latest version of
flash-kernel, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 813...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Uwe Kleine-König  (supplier of updated flash-kernel 
package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 10 Mar 2016 20:30:19 +0100
Source: flash-kernel
Binary: flash-kernel flash-kernel-installer
Architecture: source
Version: 3.35+deb8u3
Distribution: stable
Urgency: medium
Maintainer: Debian Install System Team 
Changed-By: Uwe Kleine-König 
Description:
 flash-kernel - utility to make certain embedded devices bootable
 flash-kernel-installer - Make the system bootable (udeb)
Closes: 794265 813995
Changes:
 flash-kernel (3.35+deb8u3) stable; urgency=medium
 .
   [ Karsten Merker ]
   * Disable the use of modprobe and udevadm in the mtdblock() function
 while running the testsuite.
 .
   [ Ian Campbell ]
   * Use /dev/mtdN when flashing, rather than needlessly going 

Bug#817946: Installation of Debian 8.3 alongside another distro renders it unbootable

[Philip Hands]

cpblpublic+deb...@gmail.com writes:

> Package: installation-reports
>
> Version: 8.3
>
> Hello. I just installed Debian 8.3 in a partition alongside Ubuntu 15.10 
> on a Lenovo X230 Tablet.
>
>
> Everything goes okay, and it claims that it writing the boot record should 
> be safe and will preserve the Ubuntu 15.10 that it found.
>
> However, upon rebooting, Ubuntu no longer boots. Its graphical booting 
> sequence just hangs on the little logo with dots moving along.
>
> In the terminal 1 screen, the following errors are reported:
>
> tpm_tis  A TPM error (6) occurred atempting to read a pcr

OK, so that's failing to talk to the TPM (Trusted Platform Module)

I'm guessing (not having tried any of this) that the problem is that
Ubuntu had installed the secure boot shim and GRUB, and that stuff is
somehow needed for the TPM to work properly, and that having overwritten
that GRUB with Debian's, it won't work.

Depending on whether you're actually using the TPM for anything
important, you might be able to simply turn it off in the BIOS.

Otherwise, you'll presumably want to boot an Ubuntu live CD and
re-install at least GRUB, and perhaps the shim:

  
https://wiki.ubuntu.com/SecurityTeam/SecureBoot#Shim_bootloader_signed_with_Microsoft_key

N.B. This is mostly guesswork based on the symptoms you describe.

HTH

As to fixing the problem (assuming that the cause is as I've guessed) we
should probably try to detect the presence of the shim and refrain from
installing Debian's grub until the user's seen a warning about being
about to break the bootability of the other system.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Processed: Re: Bug#813242: debootstrap: second stage foreign boostrap fails

[Debian Bug Tracking System]

Processing control commands:

> forcemerge 813232 -1
Bug #813232 {Done: Marco d'Itri } [debootstrap] debootstrap: 
Two-staged bootstrapping with --second-stage broken
Bug #813242 [debootstrap] debootstrap: second stage foreign boostrap fails
Marked Bug as done
Marked as fixed in versions debootstrap/1.0.78+nmu1.
Merged 813232 813242

-- 
813232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813232
813242: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813242
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#813242: debootstrap: second stage foreign boostrap fails

[James Clarke]

Control: forcemerge 813232 -1

This does indeed appear to be the same as #813232, which was fixed in 
1.0.78+nmu1. I can no longer reproduce this.

Regards,
James



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#814088: Be cautious about data-loss !!

[Andreas Glaeser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This obviously has been a low-priority project, but I have the box basically up 
and
running now.

If you have a similar scenario as myself, with an external harddisk with data 
on it, that
you want to integrate into a RAID and use as network-storage, don't do it the 
way, I did
it, transferring the data over NFS and then trying to set up the RAID straight 
away.

I lost half of my data that way, because balancing the data over the two disks 
failed due
to read-errors, there were 300+ of them on the new internal SATA-disk, that had 
only 24
hours of operation-time yet. The extended long SMART selftest's result was 
that, the
disk-health is basically good, so actually the failure may be due to bad karma 
mainly and
carelessness.
So I zeroed out the whole drive with dd and tried again, now it seems to work 
well enough.
I set it up the same way and checked, the problem was not due to misaligned 
partitions,
which was not the case, although it's an advanced format disk with 4k blocks, 
cfdisk did
the partitioning job quite well, that was checked on afterwards with parted.

If you have data you cannot afford to lose, connect the external USB-disk 
directly to the
NAS-box and transfer the data manually on the terminal using SSH, not with the 
graphical
file-manager of your choice, say '$ cp -av .. ..' for instance.
Then balance the data on the internal drive in order to check for errors:
#  btrfs balance start -v /mnt/sata

If that goes well, you are most probably fine to add the external disk to the 
RAID and
re-balance it as RAID1:
#  btrfs device add -f /dev/sdd1 /mnt/sata/
#  btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/sata/

When spreading out the existing data over the two devices is finished, you can 
start
populating the disk with other data over NFS, I did a reboot first.

One problem, which actually appeared chronologically first is the question about
permissions. I introduced a special group for network-storage on the NAS and 
wanted to
add users on the network, who are allowed to write on it to that same group 
with the same
GID, but that doesn't work over NFS. If you need something like it, you may 
have to deal
with NFS-ACLs and the package fs4-acl-tools on the clients:

> Package: nfs4-acl-tools  
> State: not installed
> Version: 0.3.3-2.1
> Priority: extra
> Section: admin
> Maintainer: Anibal Monsalve Salazar 
> Architecture: amd64
> Uncompressed Size: 104 k
> Depends: libattr1 (>= 1:2.4.46-8), libc6 (>= 2.14)
> Description: Commandline and GUI ACL utilities for the NFSv4 client
>  This package contains commandline and GUI ACL utilities for the Linux NFSv4 
> client.
> Homepage: http://www.citi.umich.edu/projects/nfsv4/linux/

But since I essentially have a single-user network and since NFS-ACLs are 
beyond LPIC-2
level, I simply used my primary UID and GID on the NAS and mapped root-access 
to the
network-storage group only, which works just fine.





-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlblhVUACgkQ5+rBHyUt5wu5igCdHhj5VhUeMbw3XrkbWKKugzH5
fuwAn1Bbicvn32S2j3vR/O1K/H2p2/AJ
=D2I4
-END PGP SIGNATURE-

Re: Merging libnss-dns-udeb and libnss-files-udeb back into libc6-udeb

[Aurelien Jarno]

On 2016-03-13 02:26, Aurelien Jarno wrote:
> Hi,
> 
> For historical reason, disk space on boot floppies, the libnss_dns.so.2 
> and libnss_files.so.2 libraries are in separate udeb packages, namely
> libnss-dns-udeb and libnss-files-udeb. This is not the case of the deb
> package, where everything is in the libc6 package.
> 
> In practice these libraries are really small by nowadays standards (22kB
> and 47kB uncompressed), and moreover libnss-dns-udeb is already included 
> in all images. In addition these libraries are tightly coupled to the
> libresolv library which is in libc6-udeb. The recent CVE-2015-7547 has
> shown that, and Ubuntu hit a bug by having the two out of sync in their
> installer [1]. We would have got the same if debian-installer was pulling
> its udeb from debian-security.

Thinking a bit more about that we'll have the same problem. Our 8.3
debian-installer images will likely break when 8.4 is released.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: own cloud task in tasksel?

[Charles Plessy]

Le Sat, Mar 12, 2016 at 10:40:30PM +0800, James Bromberger a écrit :
> On 12/03/2016 9:19 PM, Charles Plessy wrote:
> > The Debian images on the Amazon cloud are of the "minbase" variant, and 
> > extra
> > packages are added.  (James, I lost track on where to find this information 
> > in
> > the source code of bootstrap-vz, or on the Debian wiki, can you remind me 
> > the
> > information ?)  For the other cloud images, I am not familiar enough to be 
> > sure
> > if they also use debootstrap's minbase variant or not.  They will also 
> > install
> > extra packages, some platform-specific, and some common with the other 
> > images.
> 
> Configuration of packages included in images made by bootstrap-vz are in
> the manifest file (eg manifests/official/ec2/...) for the image being
> generated. It's a simple YAML file that you add the lines of what
> additional package(s) you want in their own base image.

Hi James,

I do not see python-boto, awscli, etc in 
`manifests/official/ec2/ebs-jessie-amd64-hvm.yml`.

Am I searching in the wrong place, or are you using ad-hoc command-line 
arguments ?

Cheers,

-- 
Charles

Re: own cloud task in tasksel?

[Charles Plessy]

Control: close 696154

Le Sat, Mar 12, 2016 at 04:15:08PM +, Anders Ingemann a écrit :
> 
> Just a quick note (I'm on the go). EC2 images are *not* using the minbase
> variant since we need networking and all that other nifty stuff for the
> image to work. The only image that bootstrap-vz builds with minbase is
> docker.

Indeed, thanks for the correction and sorry for the noise.

Which means that 'less' and other packages of Important priority are installed,
therefore I can close #696154 :)

Have a nice Sunday,

-- 
Charles

Bug#818065: #818065 - console-setup does not work correctly

[Thilo Six]

Hello Thomas,

i saw similar problems with console not being set up correctly.
Take a look into '/etc/console-setup/', all files in there should be 644.

% l /etc/console-setup/*.gz
-rw-r--r-- 1 root root 2,4K  2016-03-12 17:23
/etc/console-setup/cached_Lat15-Fixed16.psf.gz
-rw-r--r-- 1 root root 4,6K  2016-03-12 17:23
/etc/console-setup/cached_UTF-8_del.kmap.gz

But lately i found a file with *600* in there.

According to my own tests it is save to 'rm /etc/console-setup/*.gz' (obviously
keeping backups of those files somewhere is always a good habbit) and then to 
do a:

root ~ # command dpkg-reconfigure --priority=low --frontend=dialog console-setup

This will recreate those '/etc/console-setup/*.gz' files. After doing so over
here all was good again.



kind regards,

 Thilo

Re: Install into subdirectory of existing file system?

[Ian Campbell]

On Sat, 2016-03-12 at 08:52 -0800, Jack Bates wrote:
> How do I coax Debian-Installer into installing into a subdirectory of
> an 
> existing file system?
> 
> /dev/sda1 is an existing ext4 file system and I want to install into an 
> e.g. /stretch subdirectory of that file system.

This is not (AFAIK) something which d-i can do, and I don't think such
an arrangement would be directly bootable by Linux either (you'd need
some additional initramfs magic to boot with root in a subdirectory of
the root device).

If what you want is a chroot type thing then I think most people would
lean towards using debootstrap.

Ian.

Bug#788062: #788062 - os-prober corrupts partitions

[Thilo Six]

Hello RMs,
Hello SRMs,
Hello D-I folks,


i dare to write on this channels because there is a IMHO rather serious bug in
os-prober which up to now went below the radar of everyone it seems.
So this email in the first place is ment to make more people aware of this issue
and here is hope that someone will catch this up and fix it.

os-prober corrupts partitions
https://bugs.debian.org/788062

This bug leads to serious data loss and is TTBOMK also present in stable.
The original bugreport talks about LVM partitions being corrupted but to my
observations also simple partition layouts with extented partitions are being
hosed. Attached you will find a matching snippet from syslog where sda4 is a
extended partition.
Note the line where is says:
>>>WARNING<<< Wrong ufstype may corrupt your filesystem

IIRC i saw other messages where it talked s.th. about not valid QNX4 format.

On upgrading one machine jessie -> stretch grub asked me to choose the partition
to install so, because it said the ID/number of original partition would have
changed.

To sum it up: This one is set _valid_ to highest bug priority debian knows.


Side note:
Here i want to make crystal clear i do not blame maintainers or any other debian
folks. I am just saying there i a rather unfortunate situation which i hope will
now be handled.
Thanks for your time.


kind regards,

 Thilo
Mar 12 06:56:39 tosh os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/sda4
Mar 12 06:56:39 tosh kernel: [ 1919.296306] EXT4-fs (sda4): unable to read 
superblock
Mar 12 06:56:39 tosh kernel: [ 1919.299097] EXT4-fs (sda4): unable to read 
superblock
Mar 12 06:56:39 tosh kernel: [ 1919.302061] EXT4-fs (sda4): unable to read 
superblock
Mar 12 06:56:39 tosh kernel: [ 1919.311096] XFS (sda4): Invalid superblock 
magic number
Mar 12 06:56:39 tosh kernel: [ 1919.319151] FAT-fs (sda4): utf8 is not a 
recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Mar 12 06:56:39 tosh kernel: [ 1919.319345] FAT-fs (sda4): bogus number of 
reserved sectors
Mar 12 06:56:39 tosh kernel: [ 1919.320495] FAT-fs (sda4): Can't find a valid 
FAT filesystem
Mar 12 06:56:39 tosh kernel: [ 1919.323291] FAT-fs (sda4): utf8 is not a 
recommended IO charset for FAT filesystems, filesystem will be case sensitive!
Mar 12 06:56:39 tosh kernel: [ 1919.323478] FAT-fs (sda4): bogus number of 
reserved sectors
Mar 12 06:56:39 tosh kernel: [ 1919.324698] FAT-fs (sda4): Can't find a valid 
FAT filesystem
Mar 12 06:56:39 tosh kernel: [ 1919.334709] MINIX-fs: unable to read superblock
Mar 12 06:56:39 tosh kernel: [ 1919.340084] attempt to access beyond end of 
device
Mar 12 06:56:39 tosh kernel: [ 1919.340093] sda4: rw=16, want=3, limit=2
Mar 12 06:56:39 tosh kernel: [ 1919.340098] hfsplus: unable to find HFS+ 
superblock
Mar 12 06:56:39 tosh kernel: [ 1919.343453] qnx4: no qnx4 filesystem (no root 
dir).
Mar 12 06:56:39 tosh kernel: [ 1919.347670] You didn't specify the type of your 
ufs filesystem
Mar 12 06:56:39 tosh kernel: [ 1919.347670]
Mar 12 06:56:39 tosh kernel: [ 1919.347670] mount -t ufs -o 
ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
Mar 12 06:56:39 tosh kernel: [ 1919.347670]
Mar 12 06:56:39 tosh kernel: [ 1919.347670] >>>WARNING<<< Wrong ufstype may 
corrupt your filesystem, default is ufstype=old
Mar 12 06:56:39 tosh kernel: [ 1919.353385] hfs: can't find a HFS filesystem on 
dev sda4


root ~ # fdisk -l /dev/sda
Disk /dev/sda: 238,5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x14e852ea

Device BootStart   End   Sectors   Size Id Type
/dev/sda1  *2048  31250431  31248384  14,9G 83 Linux
/dev/sda2   31250432  56641535  25391104  12,1G 83 Linux
/dev/sda3   56641536  97656831  41015296  19,6G 82 Linux swap / Solaris
/dev/sda4   97658878 500117503 402458626 191,9G  5 Extended
/dev/sda5   97658880 500117503 402458624 191,9G 83 Linux

Re: Merging libnss-dns-udeb and libnss-files-udeb back into libc6-udeb

[Philipp Kern]

On Sun, Mar 13, 2016 at 02:26:26AM +0100, Aurelien Jarno wrote:
> For historical reason, disk space on boot floppies, the libnss_dns.so.2 
> and libnss_files.so.2 libraries are in separate udeb packages, namely
> libnss-dns-udeb and libnss-files-udeb. This is not the case of the deb
> package, where everything is in the libc6 package.
> 
> In practice these libraries are really small by nowadays standards (22kB
> and 47kB uncompressed), and moreover libnss-dns-udeb is already included 
> in all images. In addition these libraries are tightly coupled to the
> libresolv library which is in libc6-udeb. The recent CVE-2015-7547 has
> shown that, and Ubuntu hit a bug by having the two out of sync in their
> installer [1]. We would have got the same if debian-installer was pulling
> its udeb from debian-security.
> 
> That's why I would like to propose to merge back libnss-dns-udeb and
> libnss-files-udeb back into libc6-udeb. The idea is to make libc6-udeb
> to provide them, it seems udpkg supports that. The only packages having
> a dependency on libnss-files-udeb are espeakup-udeb, rdnssd-udeb,
> open-iscsi and openssh-client-udeb, and none of them has a versioned
> dependency. None of the udeb have a dependency on libnss-files-udeb.
> 
> Any opinion on that?

It sounds like a good idea to me. :)

Kind regards
Philipp Kern

Bug#818065: console-setup is not read correctly at boottime and must be started manually

[Thomas Schmidt]

Package: console-setup
Version: 1.138
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Not reproduceable

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Restarting /etc/init.d/console-setup.sh helps, renaming console-setup.sh to
console-setup doesn't. 

   * What was the outcome of this action?

After /etc/init.d/console-setup.sh restart, everything is fine.

   * What outcome did you expect instead?

Not to do the restart.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable')
Architecture: i386 (i686)

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

Versions of packages console-setup depends on:
ii  console-setup-linux 1.138
ii  debconf 1.5.58
ii  keyboard-configuration  1.138
ii  xkb-data2.17-1

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.21-9
ii  lsb-base  9.20160110

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.58
ii  liblocale-gettext-perl  1.07-1+b1

Versions of packages console-setup-linux depends on:
ii  console-tools   1:0.2.3dbs-70
ii  initscripts 2.88dsf-59.3
ii  kbd-compat [kbd]1:0.2.3dbs-70
ii  keyboard-configuration  1.138

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
ii  console-common0.7.89
ii  console-data  2:1.12-5
ii  console-tools 1:0.2.3dbs-70
pn  gnome-control-center  
ii  kbd-compat [kbd]  1:0.2.3dbs-70
ii  systemd   229-2

-- debconf information:
* keyboard-configuration/other:
  console-setup/fontsize: 8x16
  console-setup/charmap47: UTF-8
  keyboard-configuration/unsupported_layout: true
  console-setup/guess_font:
* keyboard-configuration/variantcode:
* keyboard-configuration/xkb-keymap: de
  keyboard-configuration/unsupported_options: true
* keyboard-configuration/optionscode:
  keyboard-configuration/unsupported_config_layout: true
  console-setup/store_defaults_in_debconf_db: true
  console-setup/fontsize-fb47: 8x16
  console-setup/fontface47: Terminus
  debian-installer/console-setup-udeb/title:
  console-setup/codesetcode: Lat15
* keyboard-configuration/toggle: No toggling
* keyboard-configuration/compose: No compose key
* keyboard-configuration/store_defaults_in_debconf_db: true
  console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic 
languages
* keyboard-configuration/modelcode: pc105
* keyboard-configuration/switch: No temporary switch
* keyboard-configuration/layout:
  console-setup/fontsize-text47: 8x16
* keyboard-configuration/altgr: The default for the keyboard layout
  console-setup/framebuffer_only:
  keyboard-configuration/ctrl_alt_bksp: false
* keyboard-configuration/layoutcode: de
  keyboard-configuration/unsupported_config_options: true
* keyboard-configuration/variant: Deutsch
* keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl)
  console-setup/use_system_font: