Re: How to properly import the configuration of the Buster kernel into own development ?
Hi, so i went back to the original configuration for exactly one kernel build and installation. Full make lasts 70 minutes, a development cycle lasts more than 3 minutes, even after running scripts/config --disable DEBUG_INFO It builds our universe and a few alternative ones too. So for the time of hacking, i am back to the sparse configuration from "make localmodconfig" (plus some manual widening). A build lasts about 1 minute, if no widely used header files got changed. (Times are measured without make option -j, because of the current environment heat.) I wrote: > > > -rwxr-xr-x 1 root root 35424 Aug 26 1904 /mnt/iso/victim > > -rwxr-xr-x 1 root root 35424 Oct 1 2040 /mnt/iso/victim songbird wrote: > always interesting! :) I have more: - The classic CD read-ahead bug (nearly as old as Linux is): CD burned with write type TAO get reported by about 80 percent of all drives with a readable size that is 1 or 2 blocks too large. Linux is credulent and courageous enough to then produce i/o errors at the attempt to read the last blocks ahead of the request of the filesystem. - Burning more than one DVD or BD simultaneously is darn slow. - Automatic CD/DVD/BD tray loading on read attempt happens, but the attempt fails immediately with a "no medium" error. dd if=/dev/sr0 of=/dev/null Retry succeeds after the drive had time to examine the medium. - Blank CD, DVD, or BD are reported by lsblk with a size 2048 bytes. But readable are 0 bytes. - An empty drive tray gets reported by lsblk with the size of the previously inserted medium. Default at boot time is 1024M. - mount -t iso9660 option -o session=N does not work for DVD and BD. (Have dust masks ready when entering this part of the kernel's basement.) - Filenames of length 254 or 255 in mounted ISO 9660 (with Rock Ridge) get truncated to some much shorter length. (Permissible are 255 bytes of name length. Truncation should aim for that length.) - Burn programs have no means to tell the kernel that readable size or content of CD, DVD, or BD have changed. (One has to eject and re-load.) Now i run out of bugs and wishes. Thus i will have to begin exploring life with an upstream development kernel. Have a nice day :) Thomas
Re: How to properly import the configuration of the Buster kernel into own development ?
Thomas Schmitt wrote: ... > More progress: > > i wrote: >> > $ ls -l /mnt/iso/victim >> > -rwxr-xr-x 1 root root 35424 Aug 26 1904 /mnt/iso/victim > > Now > > $ ls -l /mnt/iso/victim > -rwxr-xr-x 1 root root 35424 Oct 1 2040 /mnt/iso/victim > > (What a difference time64_t instead of int can make ...) > > -- > > Have a nice day :) always interesting! :) songbird
How to properly import the configuration of the Buster kernel into own development ?
Hi, i wrote: > > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html > > "generate a configuration based on the running kernel and the currently > >loaded modules (make localmodconfig)" n...@dismail.de wrote: > If you want to save yourself some trouble with localmod, start with a > known good distribution config (like debian's) and plug in all devices > you will ever use before you run make localmodconfig Ah. That explains a lot. I had not enough RAM disks and loop devices so that not enough kernel modules were autoloaded to be considered important enough for my new configuration. (A bigger warning sign than the clause "loaded" with "modules" would have been nice.) > [...] /boot/config-(versioan and variant) [...] > Copy this config to your source tree as .config. > Then update your config with: > make oldconfig Again enlightening. (I saw a warning in .config that one should not fiddle with it by hand but did not provide enough wetware stack to make the link between "reuse an old configuration file by placing it as a .config" and 10 lines later "Instead of nconfig one can use oldconfig".) The Wanderer wrote: > I've > done similar builds directly from upstream kernel.org source many times > via a similar methodology. Then i know whom to ask when i try to get the changes in shape for submission to the kernel. Afaik this procedure includes using a kernel from the module maintainers' git. -- More progress: i wrote: > > $ ls -l /mnt/iso/victim > > -rwxr-xr-x 1 root root 35424 Aug 26 1904 /mnt/iso/victim Now $ ls -l /mnt/iso/victim -rwxr-xr-x 1 root root 35424 Oct 1 2040 /mnt/iso/victim (What a difference time64_t instead of int can make ...) -- Have a nice day :) Thomas
Re: How to properly import the configuration of the Buster kernel into own development ?
On 2020-08-09 at 07:14, Thomas Schmitt wrote: > Hi, > > are people here who make their own kernels and know how to import the > configuration of the originally installed kernel ? > > I got lured by > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html > into following > "generate a configuration based on the running kernel and the currently >loaded modules (make localmodconfig)" > which was obviously a poor decision. > > What should i do in order to bring the configuration of the original Buster > kernel 4.19.0 to my experimental kernel which stems from the Buster package > "linux-source-4.19" ? I'm not 100% sure how things are laid out in that Debian version, but generally speaking, what you want to do is grab the kernel config file which was used to build your current kernel, and drop that into place in your kernel source tree (or more specifically, your kernel *build* tree, which can be different) under the filename '.config'. IIRC, at one point in the past, Debian had the necessary kernel config options enabled for this config file to be available (compressed) under the name '/proc/config.gz'. However, in current Debian testing, that file isn't present. (If it's there on your system, just decompress it and skip the next three paragraphs.) Instead, the config is available under /boot, in a filename matching the kernel version (or at least the name of the kernel package). On my system: $ uname -r 5.7.0-1-amd64 $ ls /boot/*`uname -r`* | grep config /boot/config-5.7.0-1-amd64 A quick look at this latter confirms that it has what look like the correct contents to be a kernel config file. Just copy that to $KERNELSOURCE/.config , run your choice of Kconfig interface (I prefer 'make menuconfig', but many seem to recommend 'make oldconfig') to make sure it's up to date with any changes that may have been made in the kernel source you're drawing on, and you should be good to go. I haven't done this with kernel source from a Debian package, but I've done similar builds directly from upstream kernel.org source many times via a similar methodology. > (There seem to be some new configuration options in the source > kernel.) That's what the final 'make menuconfig' / 'make oldconfig' / etc. is there for. If memory serves, 'make oldconfig' specifically asks you only about options which aren't already answered in the existing config file. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: How to properly import the configuration of the Buster kernel into own development ?
On Sun, Aug 09, 2020 at 13:14:19 +0200, Thomas Schmitt wrote: > Hi, > > are people here who make their own kernels and know how to import the > configuration of the originally installed kernel ? > > What should i do in order to bring the configuration of the original Buster > kernel 4.19.0 to my experimental kernel which stems from the Buster package > "linux-source-4.19" ? > (There seem to be some new configuration options in the source kernel.) For Debian systems the kernel config is shipped in /boot as /boot/config-(versioan and variant). You can use this as a basis, if you are on stable, maybe grab a newer config from unstable or testing first to reduce the config-differences between mainline and Debian's config. Copy this config to your source tree as .config. Then update your config with: make oldconfig You'll be asked what to do about new config options that arent already ruled out by other selected options. (If you just want to select default for everything: make olddefconfig) Now you can treat it like every other (probably valid) config. > I got lured by > https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html > into following > "generate a configuration based on the running kernel and the currently >loaded modules (make localmodconfig)" > which was obviously a poor decision. If you want to save yourself some trouble with localmod, start with a known good distribution config (like debian's) and plug in all devices you will ever use before you run make localmodconfig, to make sure necessary modules are loaded. You might still need to reenable some filesystems afterwards, if they weren't in use. Nito
How to properly import the configuration of the Buster kernel into own development ?
Hi, are people here who make their own kernels and know how to import the configuration of the originally installed kernel ? I got lured by https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html into following "generate a configuration based on the running kernel and the currently loaded modules (make localmodconfig)" which was obviously a poor decision. What should i do in order to bring the configuration of the original Buster kernel 4.19.0 to my experimental kernel which stems from the Buster package "linux-source-4.19" ? (There seem to be some new configuration options in the source kernel.) - Long story: After happily hacking on the CDROM bugs i now look at ISO 9660 (year 2038 is near). At that occasion i am faced with no loop devices for mounting my test ISO 9660 images. Some googling brought me to diffing the configuration reports at boot time of the original Buster kernel 4.19.0 and my hack which stems from the Buster package "linux-source-4.19": diff -puN /boot/config-4.19.0-9-amd64 /boot/config-4.19.118-ts That diff is huge and reveils a massacre with CONFIG_BLK_DEV options. -CONFIG_BLK_DEV_LOOP=m ... -CONFIG_BLK_DEV_RAM=m ... +# CONFIG_BLK_DEV_LOOP is not set +... +# CONFIG_BLK_DEV_RAM is not set and many more. I hope to have now enabled the old CONFIG_BLK_DEV settings. But the reason why they were unset is obscure to me and i don't know which of the many other differences will bite me when this kernel goes into real use. Well, at least i can mount my ISO images now. This here is in need to be fixed: $ xorriso -outdev test.iso \ -blank as_needed \ -map /bin/true /victim \ -alter_date m 'Oct 01 22:06:12 2040' /victim -- # mount /home/thomas/test.iso /mnt/iso $ ls -l /mnt/iso/victim -rwxr-xr-x 1 root root 35424 Aug 26 1904 /mnt/iso/victim (The error to map everything above 2028 to 1970 was fixed since kernel 3.16. But the function iso_date() still returns int, which rolls over in 2038. https://github.com/torvalds/linux/blob/master/fs/isofs/util.c line 19. ) - Have a nice day :) Thomas
