Hello community, here is the log from the commit of package mkdud for openSUSE:Factory checked in at 2020-03-05 23:21:09 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/mkdud (Old) and /work/SRC/openSUSE:Factory/.mkdud.new.26092 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "mkdud" Thu Mar 5 23:21:09 2020 rev:30 rq:781547 version:1.48 Changes: -------- --- /work/SRC/openSUSE:Factory/mkdud/mkdud.changes 2019-09-25 08:20:50.630445985 +0200 +++ /work/SRC/openSUSE:Factory/.mkdud.new.26092/mkdud.changes 2020-03-05 23:21:20.297279770 +0100 @@ -1,0 +2,7 @@ +Wed Mar 4 14:13:49 UTC 2020 - [email protected] + +- merge gh#openSUSE/mkdud#32 +- updated troubleshooting section in HOWTO +- 1.48 + +-------------------------------------------------------------------- Old: ---- mkdud-1.47.tar.xz New: ---- mkdud-1.48.tar.xz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ mkdud.spec ++++++ --- /var/tmp/diff_new_pack.PqN8ut/_old 2020-03-05 23:21:22.797281146 +0100 +++ /var/tmp/diff_new_pack.PqN8ut/_new 2020-03-05 23:21:22.797281146 +0100 @@ -30,7 +30,7 @@ Summary: Create driver update from rpms License: GPL-3.0-or-later Group: Hardware/Other -Version: 1.47 +Version: 1.48 Release: 0 Source: %{name}-%{version}.tar.xz Url: https://github.com/openSUSE/mkdud ++++++ mkdud-1.47.tar.xz -> mkdud-1.48.tar.xz ++++++ diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/mkdud-1.47/HOWTO.md new/mkdud-1.48/HOWTO.md --- old/mkdud-1.47/HOWTO.md 2019-09-23 15:12:48.000000000 +0200 +++ new/mkdud-1.48/HOWTO.md 2020-03-04 15:13:49.000000000 +0100 @@ -181,17 +181,303 @@ ``` -## Debug problems +## Troubleshooting -Sometimes things just don't work as expected. Here's what to do: +Sometimes things just don't work as expected. Here is a detailed guide that walks you through the entire update process +and shows what exactly to expect. -- use `mkdud --show foo.dud` to get an overview of what's inside the driver update -- make sure the product specified with `--dist` matches the intended product +For illustrating purposes a driver update for [libparted0](https://software.opensuse.org/package/libparted0) +(the library containing the core functionality of [parted](https://software.opensuse.org/package/parted)) is used. -If you see the driver update loaded but it's apparently not applied, do this: +The latest version of libpart0 is (at the time I'm writing this) contained in package `libparted0-3.3-1.1.x86_64.rpm`. -- start the installation with the `startshell=1` boot option; this will open a shell instead of starting the installer (the regular -workflow continues when you exit this shell) -- there must be an `/update` directory with subdirectories for each driver update; if it's missing, your driver update has not been recognized -- check the correct product: the `UpdateDir` entry in `/linuxrc.config` contains the expected string -- have a look at `/var/log/linuxrc.log` to see what linuxrc did with the driver update so far +One last note before we start: + +- 'installation system' refers to the small system the installer runs in during the installation +- 'target system' refers to the system that gets finally installed + +### Creating the driver update + +Let's make a driver update for Tumbleweed of our package: + +```sh +> mkdud --create foo.dud --dist tw libparted0-3.3-1.1.x86_64.rpm +=== Update #1 === + [openSUSE Tumbleweed (x86_64)] + Name: + libparted0-3.3-1.1.x86_64 Wed Jan 15 15:33:15 2020 + ID: + c599d3ac-9bf7-48cb-b593-bd6612388049 + Packages: + libparted0-3.3-1.1.x86_64.rpm (Wed Jan 15 15:33:15 2020) + - install methods: instsys, repo, rpm (repo priority 50) + Scripts: + update.pre, update.post2 + Installation System: + /usr/lib64/libparted-fs-resize.so.0.0.2 + /usr/lib64/libparted.so.2.0.2 +``` + +You can use `mkdud --show foo.dud` to get the same overview of what's inside the driver update. + +It is important that the argument to `--dist` is the correct product. Driver updates are always for a specific product. +Use `--dist` several times to make an update that applies to more than one product. + +`foo.dud` is a compressed CPIO archive. Looking inside shows this: + +```sh +> zcat foo.dud | cpio -tv +drwxr-xr-x 1 root root 0 Mar 4 12:12 . +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse/x86_64-tw +-rw-r--r-- 1 root root 134 Mar 4 12:12 linux/suse/x86_64-tw/dud.config +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse/x86_64-tw/install +-r--r--r-- 1 root root 240304 Mar 4 12:12 linux/suse/x86_64-tw/install/libparted0-3.3-1.1.x86_64.rpm +-rwxr-xr-x 1 root root 191 Mar 4 12:12 linux/suse/x86_64-tw/install/update.post2 +-rwxr-xr-x 1 root root 910 Mar 4 12:12 linux/suse/x86_64-tw/install/update.pre +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys +-rw-r--r-- 1 root root 26 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys/.update.c599d3ac-9bf7-48cb-b593-bd6612388049 +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys/usr +drwxr-xr-x 1 root root 0 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys/usr/lib64 +lrwxrwxrwx 1 root root 28 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys/usr/lib64/libparted-fs-resize.so.0 -> libparted-fs-resize.so.0.0.2 +-rwxr-xr-x 1 root root 88504 Jan 15 16:35 linux/suse/x86_64-tw/inst-sys/usr/lib64/libparted-fs-resize.so.0.0.2 +lrwxrwxrwx 1 root root 18 Mar 4 12:12 linux/suse/x86_64-tw/inst-sys/usr/lib64/libparted.so.2 -> libparted.so.2.0.2 +-rwxr-xr-x 1 root root 395056 Jan 15 16:35 linux/suse/x86_64-tw/inst-sys/usr/lib64/libparted.so.2.0.2 +1422 blocks +``` + +- Note the `x86_64-tw` directory. `tw` comes directly from the `--dist` argument. `x86_64` is the architecture of the RPM. +- Everything below `inst-sys` is the part going to be used to update the installation system. +- The RPM in the `install` subdirectory is the package used by the installer for updating the target system. +- The `update.pre` and `update.post2` scripts are auto-generated to create resp. remove a temporary repository that contains this RPM. +- The `.update.XXX` file is added to the installation system and contains the RPM version. This way you easily see which +updates have been used to update the installation system. + +### Using the driver update + +Driver updates are used with the `dud` boot option as explained above. + +There are two ways you can update the installation system: you can (a) pass an url pointing to +a driver update or (b) pass an url pointing to a plain RPM. In both cases slightly different things happen. Let's deal with +both cases individually. + +To analyze issues with driver updates start the installation with the +`startshell=1` boot option. If you have network access (or simply prefer working that way) add `sshd=1 password=XXXXX` to +activate SSH access to your machine. + +With `startshell=1`, the installation process is interrupted at the point +just before the installer would run. The installation system has been fully set up and any driver updates have been applied. +Once you exit the shell that has been started, the installation process continues. + +#### Using a proper driver update + +If everything went fine, looking around you should see: + +```sh +0:vm0259:~ # ls -l /update/000/ +total 4 +-rw-r--r-- 1 root root 134 Mar 4 11:22 dud.config +drwxr-xr-x 3 root root 80 Mar 4 11:22 inst-sys +drwxr-xr-x 2 root root 100 Mar 4 11:22 install +drwxr-xr-x 2 root root 60 Mar 4 11:22 repo +``` + +This is the very content of `foo.dud`. Driver updates are stored in an +`/update` directory in the installation system. Each in its own subdirectory. + +There is also an `/.update.XXX` file containing the package version used in the update: + +```sh +0:vm0259:~ # ls -l /.update.* +lrwxrwxrwx 1 root root 65 Mar 4 11:22 /.update.c599d3ac-9bf7-48cb-b593-bd6612388049 -> /update/000/inst-sys/.update.c599d3ac-9bf7-48cb-b593-bd6612388049 +0:vm0259:~ # cat /.update.c599d3ac-9bf7-48cb-b593-bd6612388049 +libparted0-3.3-1.1.x86_64 +``` + +If `/update` is missing, no driver update has been applied. Either because +none was downloaded or the product or architecture did not match. + +You can check which product and architecture combination is expected +by looking at the `UpdateDir` entry in `/linuxrc.config`: + +```sh +0:vm0259:~ # grep UpdateDir /linuxrc.config +UpdateDir: /linux/suse/x86_64-tw +``` + +This must be the same directory you saw earlier in the cpio output of `foo.dud`. + +Check `/proc/cmdline` that you passed the correct option: + +```sh +0:vm0259:~ # cat /proc/cmdline +initrd=initrd startshell=1 sshd=1 password=xxxxx dud=ftp://example.com/dud/foo.dud +``` + +If that's ok, check `/var/log/linuxrc.log` to see what happened. It should say the driver update +has been downloaded and log that it has been applied. Like this: + +```sh +0:vm0259:~ # less /var/log/linuxrc.log +[...] +11:22:27 <4>: url = ftp://example.com/dud/foo.dud +11:22:27 <2>: loading ftp://example.com/dud/foo.dud -> /download/file_0000 +11:22:27 <2>: sha1 655fb3c1df7aa7e27507e7db4b97ce96 +11:22:27 <2>: sha256 8dc36c673e74b323f1f4707fc64ea4a7 +11:22:27 <2>: digest not checked +[...] +11:22:30 <2>: dud 0: ftp:/linux/suse/x86_64-tw +11:22:30 <2>: (id c599d3ac-9bf7-48cb-b593-bd6612388049) +11:22:30 <2>: +11:22:30 <2>: dud 0: +11:22:30 <2>: libparted0-3.3-1.1.x86_64 Wed Jan 15 15:33:15 2020 +11:22:30 <1>: Driver Update: libparted0-3.3-1.1.x86_64 Wed Jan 15 15:33:15 2020 +11:22:30 <1>: Driver Updates added: +11:22:30 <1>: libparted0-3.3-1.1.x86_64 Wed Jan 15 15:33:15 2020 +[...] +``` + +If that's all fine but things don't work as expected, check that the driver update has been properly integrated and +the updated files are actually used. + +Files in the installation system are updated by replacing them with symlinks to the driver update. So if you expect +file `bar` to have been updated, it must be a symlink from `bar` to somewhere below `/update`. For example, let's +check if parted is using an updated libparted0: + +```sh +0:vm0259:~ # type parted +parted is /usr/sbin/parted +0:vm0259:~ # ldd /usr/sbin/parted + linux-vdso.so.1 (0x00007ffe741ce000) + libc.so.6 => /lib64/libc.so.6 (0x00007f717f3a0000) + libparted.so.2 => /usr/lib64/libparted.so.2 (0x00007f717f33a000) +[...] +0:vm0259:~ # ls -l /usr/lib64/libparted.so.2 +lrwxrwxrwx 1 root root 18 Mar 4 11:22 /usr/lib64/libparted.so.2 -> libparted.so.2.0.2 +0:vm0259:~ # ls -l /usr/lib64/libparted.so.2.0.2 +lrwxrwxrwx 1 root root 49 Mar 4 11:22 /usr/lib64/libparted.so.2.0.2 -> /update/000/inst-sys/usr/lib64/libparted.so.2.0.2 +``` + +As you can see, `/usr/lib64/libparted.so.2.0.2` links to `/update/000/inst-sys/usr/lib64/libparted.so.2.0.2` which is +the file from our driver update. + +This proves the driver update has been applied properly. + +#### Using an RPM package + +This works a bit differently compared to using a proper driver update. The idea here is to provide a convenient way +to update the installation system using just an RPM. The RPM is unpacked into some temporary directory and +files in the installation system are updated by replacing them with symlinks to this temporary directory. + +There is no `/update` directory involved as described in the previous section. + +But let's look at our example. + +Check `/proc/cmdline` that you passed the correct option: + +```sh +0:vm1479:~ # cat /proc/cmdline +initrd=initrd startshell=1 sshd=1 password=xxxxx dud=ftp://example.com/dud/libparted0-3.3-1.1.x86_64.rpm + +``` + +If that's ok, check `/var/log/linuxrc.log` to see what happened. It should say the RPM +has been downloaded and log that it has been unpacked. Like this: + +```sh +0:vm1479:~ # less /var/log/linuxrc.log +[...] +11:15:40 <4>: url = ftp://example.com/dud/libparted0-3.3-1.1.x86_64.rpm +11:15:40 <2>: loading ftp://example.com/dud/libparted0-3.3-1.1.x86_64.rpm -> /download/file_0000 +11:15:40 <2>: sha1 ee17a0800d6697e8a4acb5999d443c81 +11:15:40 <2>: sha256 b1e8d4b229bcd219417212b96afcff59 +11:15:40 <2>: digest not checked +[...] +11:15:44 <1>: ftp://example.com/dud/libparted0-3.3-1.1.x86_64.rpm: adding to installation system +11:15:44 <2>: ftp://example.com/dud/libparted0-3.3-1.1.x86_64.rpm -> /download/dud_0000: converting dud to squashfs +[...] +11:15:44 <1>: Driver Updates added: +11:15:44 <1>: dud/libparted0-3.3-1.1.x86_64.rpm +[...] +``` + +If that's all fine but things don't work as expected, check that the RPM has been properly integrated and +the updated files are actually used. + +Files in the installation system are updated by replacing them with symlinks to the temporary directory into +which the RPM has been unpacked. + +```sh +0:vm1479:~ # type parted +parted is /usr/sbin/parted +0:vm1479:~ # ldd /usr/sbin/parted + linux-vdso.so.1 (0x00007ffeab1e2000) + libc.so.6 => /lib64/libc.so.6 (0x00007f5fb9d3e000) + libparted.so.2 => /usr/lib64/libparted.so.2 (0x00007f5fb9cd8000) +[...] +0:vm1479:~ # ls -l /usr/lib64/libparted.so.2 +lrwxrwxrwx 1 root root 18 Mar 4 11:15 /usr/lib64/libparted.so.2 -> libparted.so.2.0.2 +0:vm1479:~ # ls -l /usr/lib64/libparted.so.2.0.2 +lrwxrwxrwx 1 root root 44 Mar 4 11:15 /usr/lib64/libparted.so.2.0.2 -> /mounts/mp_0006/usr/lib64/libparted.so.2.0.2 +``` + +Notice that `libparted.so.2.0.2` is a symlink to somehwhere below `/mounts/mp_0006`. + +But that's similar also for other files! For example: + +```sh +0:vm1479:~ # ls -l /usr/lib64/libzypp.so.1722.0.0 +lrwxrwxrwx 1 root root 45 Mar 4 11:22 /usr/lib64/libzypp.so.1722.0.0 -> /mounts/mp_0001/usr/lib64/libzypp.so.1722.0.0 +``` + +This is because the installation system consists of several parts put together by symlinking files. + +You have to make sure that `/mounts/mp_0006` is not some regular part of the installation system but is really +your updated RPM. + +One way to do this is: + +```sh +0:vm1479:~ # findmnt --real +TARGET SOURCE FSTYPE OPTIONS +/parts/mp_0000 /dev/loop0 squashfs ro,relatime +/parts/mp_0001 /dev/loop1 squashfs ro,relatime +/var/adm/mount /dev/disk/by-id/scsi-3a849dd62eb66473d-part2 + iso9660 ro,relatime,nojoliet,check=s,map=n,blocksize=2048 +/mounts/mp_0000 /dev/loop2 squashfs ro,relatime +/mounts/mp_0001 /dev/loop3 squashfs ro,relatime +/mounts/mp_0002 /dev/loop4 squashfs ro,relatime +/mounts/mp_0003 /dev/loop5 squashfs ro,relatime +/mounts/mp_0004 /dev/loop6 squashfs ro,relatime +/mounts/mp_0006 /dev/loop7 squashfs ro,relatime +0:vm1479:~ # losetup -l +NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC +/dev/loop1 0 0 0 1 /parts/01_usr 0 512 +/dev/loop6 0 0 0 1 /download/file_0007 (deleted) 0 512 +/dev/loop4 0 0 0 1 /download/file_0004 (deleted) 0 512 +/dev/loop2 0 0 0 1 /download/file_0002 (deleted) 0 512 +/dev/loop0 0 0 0 1 /parts/00_lib 0 512 +/dev/loop7 0 0 0 1 /download/dud_0000 0 512 +/dev/loop5 0 0 0 1 /download/file_0006 (deleted) 0 512 +/dev/loop3 0 0 0 1 /download/file_0003 (deleted) 0 512 +``` + +You see that `/mounts/mp_0006` is from mounting `/dev/loop7` which is the loop device for `/download/dud_0000`. + +If you want to know what the other parts of the installation system are, you can look at `/etc/instsys.parts`: + +```sh +0:vm1479:~ # cat /etc/instsys.parts +boot/x86_64/common /mounts/mp_0000 +boot/x86_64/root /mounts/mp_0001 +boot/x86_64/cracklib-dict-full.rpm /mounts/mp_0002 +boot/x86_64/bind /mounts/mp_0003 +boot/x86_64/yast2-trans-en_US.rpm /mounts/mp_0004 +boot/x86_64/control.xml?copy=1 /mounts/mp_0005 +``` + +It's pretty safe to assume that `/download/dud_0000` belongs to the updated RPM and is not a regular installation +system part. You can check `/var/log/linuxrc.log` as shown above to make sure, though. + +Again, all the above proves the driver update has been applied properly. diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/mkdud-1.47/VERSION new/mkdud-1.48/VERSION --- old/mkdud-1.47/VERSION 2019-09-23 15:12:48.000000000 +0200 +++ new/mkdud-1.48/VERSION 2020-03-04 15:13:49.000000000 +0100 @@ -1 +1 @@ -1.47 +1.48 diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/mkdud-1.47/changelog new/mkdud-1.48/changelog --- old/mkdud-1.47/changelog 2019-09-23 15:12:48.000000000 +0200 +++ new/mkdud-1.48/changelog 2020-03-04 15:13:49.000000000 +0100 @@ -1,3 +1,7 @@ +2020-03-04: 1.48 + - merge gh#openSUSE/mkdud#32 + - updated troubleshooting section in HOWTO + 2019-09-23: 1.47 - merge gh#openSUSE/mkdud#31 - adjust spec file to build on SLE-11
