Bug#827072: kfreebsd-10: use notify-reboot-required

[Steven Chamberlain]

Control: tags -1 + pending

Hi,

Jon Boden wrote:
> notify-reboot-required is the Ubuntu way packages tell the user that a
> reboot is required (usually after an upgrade).

Patch applied in SVN, thanks!

Debian has this too (update-notifier-common) but I'm not sure if
it is typically installed.  If the reboot-required notification turns
out to be annoying for users, we can reconsider how to handle this, but
I'm happy to apply it in the meantime.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Processed: Re: Bug#827072: kfreebsd-10: use notify-reboot-required

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #827072 [kfreebsd-10] kfreebsd-10: use notify-reboot-required
Added tag(s) pending.

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

Bug#827072: kfreebsd-10: use notify-reboot-required

[Jon Boden]

Package: kfreebsd-10
Version: 10.3~svn300087-1
Tags: patch

Hi

If it's not too much noise, could you merge this small patch?

https://bazaar.launchpad.net/~ubuntubsd/ubuntubsd/kfreebsd-10/diff/692?context=3

notify-reboot-required is the Ubuntu way packages tell the user that a reboot 
is required (usually after an upgrade).

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD

Bug#827070: kfreebsd-10: please use LDADD instead of LDFLAGS for aicasm

[Jon Boden]

Package: kfreebsd-10
Version: 10.3~svn300087-1
Tags: patch

Hi

When building kfreebsd-10 on ubuntuBSD, at least with current toolchain (and 
possibly on Debian eventually), it fails with linker errors because the -lbsd 
-ldb flags are not with the rest of the flags (-ll) and for some reason the 
linker can't find symbols on those libraries (bsd_getopt, etc).

This can be fixed by using LDADD instead. Could you include the patch? 
https://bazaar.launchpad.net/~ubuntubsd/ubuntubsd/kfreebsd-10/diff/694?context=3

I've also sent the Makefile part to FreeBSD: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210221

Thanks!

-- 
Jon Boden

ubuntuBSD -- The power of FreeBSD kernel with familiarity of Ubuntu OS!

http://www.ubuntubsd.org/ -- https://twitter.com/ubuntuBSD

Re: Installer for stable or testing

[Steven Chamberlain]

Hi,

Philipp Martis wrote:
> besides the problems I mentioned in my previous two mails from today
> and yesterday, the netboot daily images don't allow for installing a
> version other than sid.

There isn't a kfreebsd "testing" suite at the moment.  Only:
wheezy, jessie-kfreebsd, and sid.

> (I'm a bit confused since Steven prefigured it for "1-2 weeks" on 24th 
> November).

It has always been 1-2 weeks away ;)  I think I first said that in April
2015...

The finished jessie-kfreebsd system, including installer, is staged in
jessie-kfreebsd-proposed-updates suite.  But I haven't been able to get
it copied into the main jessie-kfreebsd suite though, which prevents us
from building official images.

I opened an ftpmaster bug ticket open for that:
https://bugs.debian.org/819253 but there a few people who could action
it, and it is probably a non-trivial thing we are asking of them.

What I did in the meantime is build a custom installer image with
the jessie-kfreebsd-proposed-updates suite enabled.  You can find it
here:
http://jenkins.kfreebsd.eu/jenkins/job/debian-installer_jessie-kfreebsd/ws/debian-8.4-kfreebsd-amd64-CD-1.iso

SHA-256: dae659788f2fd7d92e59a0a62f3144887d7a44f308703a93a46d3b7bca10ab2e

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: kfreebsd -- encryption options

[Steven Chamberlain]

Hello,

Philipp Martis wrote:
> I checked a few other images, namely the daily netboot builds from
> 05/12, 05/18, 06/05 and 06/11 (today).   They all have the same
> problem: "physical volume for encryption" doesn't show up during
> partitioning,

I should probably write this up in the Wiki...

We don't support it yet in the installer, but it is potentially
possible, if you install some part that is unencrypted and set up
encrypted partitions later.

My laptop boots a very small unencrypted root (similar to an initramfs).
An early /etc/rcS.d script prompts me to unlock a geli partition, inside
which I have a ZFS pool which is mounted after that.

The (encrypted) ZFS filesystems can be mounted anywhere - you could
encrypt only /home if you prefer - or even over the top of /usr or /
(the latter would be similar to doing a pivot_root, which is how
full-disk encryption is usually implemented on Linux).

Remember to move /lib/modules into /boot in this case, and put a symlink
back from /lib/modules -> /boot/modules

There are still other ways.  Regular OpenSSH can be used for a
dropbear-type setup.  The FreeBSD kernel has some way to mount an
encrypted root partition by itself;  and GRUB2 supports encryption and
GPG verification of things it loads too.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Installer for stable or testing

[Philipp Martis]

Hi,

besides the problems I mentioned in my previous two mails from today and 
yesterday, the netboot daily images don't allow for installing a version other 
than sid.
Hence, I tried the "official build" again, but it still only allows for 
installing wheezy.
Can you estimate when a new version of the installer supporting more recent 
versions and finally a Jessie release will be out? (I'm a bit confused since 
Steven prefigured it for "1-2 weeks" on 24th November).

Cheers,
Philipp

Re: kfreebsd -- encryption options

[Philipp Martis]

Hi,

I checked a few other images, namely the daily netboot builds from 05/12, 
05/18, 06/05 and 06/11 (today).
They all have the same problem: "physical volume for encryption" doesn't show 
up during partitioning, neither with crypto-modules-10.3.0-amd64-di, nor with 
crypto-dm-modules-10.3.0-amd64-di, nor with both loaded.
Also, zfs encryption doesn't seem to work (`zfs create -o encryption=on ...` 
gives "cannot create 'bsdpool/bsdroot': invalid property 'encryption'".

Kind regards,
Philipp


On Fri, 10 Jun 2016 16:12:23 +0200 UTC,
Philipp Martis  wrote:
> Hi,
> 
> basically, it should already work out of the box, at least that's how it is 
> described in the Installation Guide:
> https://www.debian.org/releases/stable/kfreebsd-amd64/ch06s03.html.en#partman-crypto
> 
> Unfortunately, it doesn't work, neither with crypto-modules, nor with 
> dm-crypto-modules, nor with both loaded.
> Also, zfs encryption doesn't seem to work.
> I tested it with the daily build from today.
> Is there any way I could help or could somebody describe a solution to get it 
> to work?
> 
> Kind regards,
> Philipp Martis
> 
> 
> >To: debian-bsd@lists.debian.org
> >Subject: kfreebsd -- encryption options
> >From: Andrew McGlashan 
> >Date: Wed, 30 Mar 2016 11:23:25 +1100
> >Message-id: <56fb1c7d.9070...@affinityvision.com.au>
> >
> >Hi,
> >
> >Having a Debian Linux installation with dropbear for pre-boot unlocking
> >of encrypted partitions (including root [and everything except for
> >/boot] on LVM).  The disk partitions actually being mirrors created
> >using mdadm (RAID1) and then encrypted using cryptsetup (dm-crypt).
> >
> >How would one go about getting the same sort of set up in Debian /
> >kFreeBSD ?
> >
> >Thanks
> >AndrewMM
> 

Re: Bug#826906: uid-wrapper: FTBFS[!linux]: only supports libc.so.[0-9] filename

[Guillem Jover]

Hi!

On Fri, 2016-06-10 at 02:20:15 +0100, Steven Chamberlain wrote:
> Package: uid-wrapper
> Version: 1.2.0+dfsg1-1
> Severity: normal
> Tags: patch
> User: debian-bsd@lists.debian.org
> Usertags: kfreebsd

> I found this happens because src/uid_wrapper.c doesn't detect the libc's
> filename.  It matches libc.so.[0-9] whereas on kfreebsd it is named
> libc.so.0.1 currently.
> 
> The same problem will affect hurd too, which has libc.so.0.3 (although
> there are other reasons for FTBFS on hurd).
> 
> Please consider the attached patch to detect libc.so.0.[0-9] as well.
> Unless there is some neater way to do this.  Thanks a lot!

Yeah, I think the initial approach is just wrong. Consider if we ever
had an (unlikely) SONAME bump for libc, the library might end up linked
against libc.so.7 and the code loading libc.so.6. Depending on the
intended usage there are possibly better ways to achieve that.

If the library is supposed to be pre-loaded then using RTLD_NEXT as
the handle is way better, and avoids having to use an explicit library
name.

If it's not, on GNU systems we can always use LIBC_SO and LIBPTHREAD_SO
from , for example. Otherwise on non-GNU ELF systems,
we could link a small program and then readelf (or objdump) it to find
the NEEDED entry for libc. Or we could also try to readlink the libc.so
symlink and make sure it's an ELF object at build time to try to get the
SONAME (this will fail on at least GNU systems as the libc.so is a linker
script there).

Thanks,
Guillem