1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Nach Upgrade: Kernelmodul kaputt und baut nicht / Header werden nicht gefunden

Dieses Thema im Forum "FreeBSD - Anwendungen und Ports" wurde erstellt von Rosendoktor, 7 August 2017.

  1. Rosendoktor

    Rosendoktor Member

    Registriert seit:
    15 Mai 2016
    Beiträge:
    64
    Hallo,

    wie nach dem Upgrade 10.3 -> 11.0 ist beim Upgrade 11.0 -> 11.1 das Kernelmodul pefs-kmod kaputt. Das Binary aus den Packages passt nicht mehr zum Kernel, ich musste es aus den Ports selbst bauen.

    Das hat beim 10.3 -> 11.0 Upgrade auch für zwei 64bit und ein 32bit System funktioniert. Jetzt geht es nur bei den 64bit Systemen, beim 32bit System bricht der Compiler wegen fehlender Header ab, hier der um irrelevante Passagen gekürzte Output:

    Code:
    root@alderamin:/usr/ports/sysutils/pefs-kmod# make clean
    ===>  Cleaning for pefs-kmod-2017.06.20
    root@alderamin:/usr/ports/sysutils/pefs-kmod# make
    ===>  License BSD2CLAUSE accepted by the user
    ===>   pefs-kmod-2017.06.20 depends on file: /usr/local/sbin/pkg - found
    ===> Fetching all distfiles required by pefs-kmod-2017.06.20 for building
    ===>  Extracting for pefs-kmod-2017.06.20
    => SHA256 Checksum OK for pefs-2017-06-20.tar.gz.
    ===>  Patching for pefs-kmod-2017.06.20
    ===>  Applying FreeBSD patches for pefs-kmod-2017.06.20
    ===>  Configuring for pefs-kmod-2017.06.20
    ===>  Building for pefs-kmod-2017.06.20
    ===> sys/modules/pefs (all)
    machine -> /usr/src/sys/i386/include
    x86 -> /usr/src/sys/x86/include
    awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -p
    awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -q
    awk -f /usr/src/sys/tools/vnode_if.awk /usr/src/sys/kern/vnode_if.src -h
    Warning: Object directory not changed from original /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs
    cc -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs/../../ -I. -I/usr/src/sys -fno-common   -MD  -MF.depend.pefs_subr.o -MTpefs_subr.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body  -Wno-error-parentheses-equality -Wno-error-unused-function  -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs/../../fs/pefs/pefs_subr.c -o pefs_subr.o
    [...]
    cc -O2 -pipe -fno-strict-aliasing  -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I/usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs/../../ -I. -I/usr/src/sys -fno-common   -MD  -MF.depend.sha512c.o -MTsha512c.o -mno-mmx -mno-sse -msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__  -Wmissing-include-dirs -fdiagnostics-show-option  -Wno-unknown-pragmas  -Wno-error-tautological-compare -Wno-error-empty-body  -Wno-error-parentheses-equality -Wno-error-unused-function  -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999 -c /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs/../../crypto/sha2/sha512c.c -o sha512c.o
    ld -d -warn-common -r -d -o pefs.kld pefs_subr.o pefs_vfsops.o pefs_vnops.o pefs_xbase64.o pefs_crypto.o pefs_dircache.o pefs_xts.o vmac.o crypto_verify_bytes.o hmac_sha512.o sha512c.o
    :> export_syms
    awk -f /usr/src/sys/conf/kmod_syms.awk pefs.kld  export_syms | xargs -J% objcopy % pefs.kld
    ld -Bshareable -d -warn-common -o pefs.ko pefs.kld
    objcopy --strip-debug pefs.ko
    ===> sbin/pefs (all)
    echo pefs: /usr/lib/libc.a /usr/lib/libutil.a >> .depend
    Warning: Object directory not changed from original /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sbin/pefs
    cc -O2 -pipe  -fno-strict-aliasing -I/usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sbin/pefs/../../sys   -MD  -MF.depend.pefs_ctl.o -MTpefs_ctl.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter  -Qunused-arguments  -c pefs_ctl.c -o pefs_ctl.o
    pefs_ctl.c:28:10: fatal error: 'sys/cdefs.h' file not found
    #include <sys/cdefs.h>
             ^~~~~~~~~~~~~
    1 error generated.
    *** Error code 1
    
    Stop.
    make[3]: stopped in /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sbin/pefs
    *** Error code 1
    
    Stop.
    make[2]: stopped in /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20
    *** Error code 1
    
    Stop.
    make[1]: stopped in /usr/ports/sysutils/pefs-kmod
    *** Error code 1
    
    Stop.
    make: stopped in /usr/ports/sysutils/pefs-kmod
    root@alderamin:/usr/ports/sysutils/pefs-kmod# 
    
    Die Datei /usr/src/sys/sys/cdefs.h ist vorhanden, an anderen Stellen gibt's die ebenfalls. Wenn ich in /usr/ports/sysutils/pefs-kmod/work/pefs-2017-06-20/sys/modules/pefs einen Symlink setze findet er zwar die cdefs.h, dann aber eine andere nicht die unter /usr/include liegt.

    Was ich schon probiert habe: Die Kernelsource komplett neu heruntergeladen und entpackt. Die Ports ebenfalls komplett gelöscht und mit portsnap neu geholt. Nchts hilft.

    Warum findet das 32bit System die Header nicht? Bei den 64bit Systemen geht's ja auch.

    Ich weiß nicht was ich noch machen kann, weiß jemand Rat?

    Grüße,

    Robert
     
  2. pit234a

    pit234a Well-Known Member

    Registriert seit:
    8 Juli 2006
    Beiträge:
    3.064
    ich nicht, nicht wirklich. Aber ich habe schon mal von Cross-compiling gehört und dass man auch Pakete für 32Bit auf einem 64Bit Rechner bauen kann. Vielleicht wäre das eine Lösung für dich.

    Dass ein Paket nicht zu einer Version von FreeBSD passt, ist nicht gut und dem sollte man zunächst auf den Grund gehen und gegebenenfalls Meldung machen.
     
  3. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.747
    Ort:
    Schleswig-Holstein
    Das ist nicht böse gemeint, aber ich glaube diese "ich mal gehört, dass"-Antworten nicht unbedingt hilfreich sind. Hier wird Cross-Compiling nicht helfen, ich würde eher vermuten(!) das entweder der Port oder das Build-System von pefs selbst auf 32-Bit Systemen einfach kaputt ist. Leider beginnt FreeBSD/i386 teilweise doch merklich Verfallserscheinungen zu zeigen...
     
  4. Rosendoktor

    Rosendoktor Member

    Registriert seit:
    15 Mai 2016
    Beiträge:
    64
    Danke Euch erst mal. Ich bin eben dahintergekommen warum es nicht gebaut hat, unter /usr/include/ hat beim i386 System das Unterverzeichnis sys gefehlt, welches auf den amd64 Systemen dort vorhanden ist. Ich habe dann in /usr/include/ einen Symlink mittels "ln -s /usr/src/sys/sys sys" gesetzt, dann hat das pefs-kmod gebaut und wird beim Booten auch geladen.

    Bleibt die Frage warum das sys Unterverzeichnis verschwunden ist? Beziehungsweise, was genau an den Dateisystem- oder Includepfaden da kaputtgegangen sein kann. Das Upgrade mit freebsd-update lief jedenfalls sauber durch, wie auf den amd64 Systemen auch, und alle Packages sind auch aktuell.
     
    foxit gefällt das.
  5. Crest

    Crest rm -rf /*

    Registriert seit:
    25 Juni 2008
    Beiträge:
    1.549
    Ort:
    /dev/random
    Yamagi: Vllt. wäre es einfach mal an der Zeit den 32 Bit Support zu überdenken.
     
  6. Yamagi

    Yamagi Possessed With Psi Powers Mitarbeiter

    Registriert seit:
    14 April 2004
    Beiträge:
    8.747
    Ort:
    Schleswig-Holstein
    Zumindest sollte man ernsthaft diskutieren, ob FreeBSD/i386 nicht auf Tier-2 degradiert werden kann. Aus zwei Gründen. Der erste ist, das FreeBSD/i386 durch sein Alter ein einziger, großer Sonderfall ist. Es hat diverse Sonderlocken im Bootprozess, schleppt Unmengen Altlasten mit (z.B. aout-Support oder Rückkompatibilität zum 2^16 breiten pid_t) mit sich herum und zumindest das 32 Bit time_t Problem muss demnächst irgendwie gelöst werden. Alle mit Tier-1 verträglichen Vorschläge waren bisher eher eklig. Der andere Grund ist, dass wir dank FreeBSD/aarch64 nun zum ersten Mal drei Tier-1 Architekturen haben, was an diversen Stellen ein Drittel mehr Manpower bindet. Ähnlich wie seinerzeit FreeBSD/alpha zugunsten von FreeBSD/amd64 degradiert (und letztendlich mit dem Aussterben der Hardware eingestellt) wurde, könnte man zu besseren Ressourcennutzung beim "einer kommt, einer geht" bleiben, ohne allzu vielen Nutzern wehzutun.
     
  7. Vril

    Vril Member

    Registriert seit:
    4 August 2016
    Beiträge:
    234
    Ein paar Tage sind es ja schon noch ... bis zum
    7. 02.2036, 06:28:16 Uhr UTC ;-)