Saturday 27 June 2020

Demonstrating the usage of 'ISO' tools with a real-life example

This is the final of three posts about my 'ISO' tools that include 'isorespin.sh', 'isocomparepkgs.sh' and 'isomimicpkgs.sh' scripts and in it I will demonstrates their usage with a worked example.

The example is about a testing PC that is currently running Ubuntu 18.04 LTS and now that Ubuntu 20.04 LTS has been released I'm considering how to upgrade it.

Normally Ubuntu does not prompt you to upgrade until the first point release becomes available (in this case 20.04.1) so in theory I could use the interim to plan however I want to upgrade now.

I'm considered two approaches to perform the upgrade. The first is the accepted way of upgrading where you simply run a command or use the Ubuntu update manager and upgrade the currently installed Ubuntu (i.e. 18.04 to 20.04). The second approach is arguably more of a migration where you backup your data then install a clean Ubuntu 20.04 and then restore your data which despite semantics is still effectively upgrading from 18.04 to 20.04.

Canonical provide good documentation on how to perform upgrades (e.g. How to upgrade from Ubuntu 18.04 LTS to 20.04 LTS today) however one point that must not be overlooked is whether your upgraded system will still have the same functionality of your existing one.

Like most users besides the applications or packages provided by the base installation I've also added packages and an upgrade will likely affect them. Unfortunately some packages are tied to a release version so maybe unavailable in a new releases or unsupported at best.

When you perform a upgrade traditionally you would remove obsolete packages in order to get a clean system and in part that is why planning for an upgrade is necessary.

The alternative approach of restoring your data after a fresh install also isn't just that simple as besides restoring your data you then need to install all the packages you added to the previous release albeit bearing in mind that not all packages may be available.

One key issue you face with the second approach is knowing what packages you have currently installed and of them which were manually installed subsequent to the initial base installation.

Looking at the second approach first, lets start by identifying the packages that will be required to be additionally installed.

On Debian and other dpkg-based distributions which includes Ubuntu you could try running the following command to gather this information:

grep " install" /var/log/dpkg.log

However this only works if the log file hasn't been rotation in which case you need:

grep " install" /var/log/dpkg.log /var/log/dpkg.log.1

But again this isn't that simple as older log files get compressed and worse still eventually deleted by log rotation (take a look at your '/etc/logrotate.d/dpkg' file) so it can't be used as a way to give you the entire history of your system.

As a simple alternative you can use my 'isocomparepkgs.sh' to compare the packages currently installed with those included in the installation ISO.

First I need to find out which ISO was used for the initial install as looking at '/etc/os-release' will only show the current version (in my case 18.04.4). Looking at '/var/log/installer/media-info' shows the release version (mine was 18.04) and release date (20180426). This indicates that the installation was done from the 'ubuntu-18.04-desktop-amd64.iso' ISO and this can be confirmed by comparing with the ISO's '.disk/info':

if [ "$(cat /var/log/installer/media-info)" == \
     "$(7z x -so ubuntu-18.04-desktop-amd64.iso .disk/info)" ]; then \
        echo is the ISO
else
        echo not the ISO
fi

However since its installation multiple 'apt upgrade' commands have upgraded my system from 18.04 to 18.04.4 so to ensure I make a true comparison I should first use 'isorespin.sh' to upgrade an 18.04 ISO the same way (as remember that point releases also introduce the HWE stack so an upgraded 18.04.4 is not exactly the same as a release 18.04.4 ISO).

Therefore I need to first simulate the elapsed upgrades with:

isorespin.sh -i ubuntu-18.04-desktop-amd64.iso -b GRUB-64 --dist-upgrade


after which I renamed the resultant ISO as 'dist-upgraded-ubuntu-18.04-desktop-amd64.iso' and then compare with my existing system:

isocomparepkgs.sh dist-upgraded-ubuntu-18.04-desktop-amd64.iso

The resultant 'isocomparepkgs.log' contains a list of packages that are only locally installed:


Even now it is not that simple as the list of packages is very long as it includes package dependencies including libraries but at least I have a list which could be used for the second approach.

This is where 'isomimicpkgs.sh' comes in useful. It will take that long list of packages and try and identify which core packages would achieve the same result if installed using 'apt' from Ubuntu sources as well as identifying those which require manual installation. So it is just a simple question of running:

isocomparepkgs.sh dist-upgraded-ubuntu-18.04-desktop-amd64.iso

and the log file shows:


A point to note here is that at some stage during using Ubuntu 18.04 I installed the 'lxde' package and later purged 'youtube-dl'. It also looks like a package dependency changed with respect to PHP as if I follow the suggested purge command exactly then I will also remove a package I want to keep ('phoronix-test-suite') again because of package dependencies (see my documentation on 'isomimicpkg.sh' for more details).

Another observation to make here is that three packages were identified as requiring manually installation.

So after verifying and running the appropriate 'apt install' and 'apt purge' commands I then renamed the resultant ISO as 'localised_18.04.iso' which is an ISO that effectively reflects my current environment (less chome, megasync and xnview).

Therefore if I was to adopt the second approach to upgrading from 18.04 to 20.04 I could use these two 'apt' commands as a basis of what to install over a clean 20.04 installation. Obviously some packages like 'linux-headers-4.15.0-99-generic' are not required whereas others like 'edid-decode' I may decide I no longer require and some packages like 'phoronix-test-suite' are just not available. But at least it is a starting point.

However the first approach was to upgrade 18.04 using the command line. Now that I have an ISO that mimics my current environment I can install this on a separate test box, run the upgrade and observe what happens without the need of lengthy data backups or restores. This way I can see what happens during the upgrade.

Or I can manually upgrade this ISO. However because of 'snaps' not working in an 'chroot' environment the upgrade is slightly more convoluted.

First I need to replace the 'bionic' repositories with the 'focal' ones:

isorespin.sh -i localised_18.04.iso -b GRUB-64 -r "--remove deb http://archive.ubuntu.com/ubuntu/ bionic main restricted" -r "--remove deb http://security.ubuntu.com/ubuntu/ bionic-security main restricted" -r "--remove deb http://archive.ubuntu.com/ubuntu/ bionic-updates main restricted" -r "deb http://archive.ubuntu.com/ubuntu/ focal main restricted" -r "deb http://security.ubuntu.com/ubuntu/ focal-security main restricted" -r "deb http://archive.ubuntu.com/ubuntu/ focal-updates main restricted"

after which I rename the resultant ISO as 'interim_first_localised_pseudo_20.04.iso'. Then in theory I could perform a 'dist-upgrade' on this ISO however this fails due to a problem with the 'texlive-binaries' package. So instead I purge that package and then perform the upgrade:

isorespin.sh -i interim_first_localised_pseudo_20.04.iso -b GRUB-64 -e texlive-binaries --dist-upgrade

creating a new ISO I call 'interim_second_localised_pseudo_20.04.iso' and renaming the log file as 'interim_second_localised_pseudo_20.04.iso.isorespin.log'. I then add back in packages removed as a result of '-e texlive-binaries' with:

isorespin.sh -i interim_second_localised_pseudo_20.04.iso -b GRUB-64 -p '"'$(sed -n '/The following packages will be REMOVED/,/The following NEW packages will be installed/p;/The following NEW packages will be installed/q' interim_second_localised_pseudo_20.04.iso.isorespin.log | sed '1d;$d;s/\*//g' | xargs | sed 's/libsynctex1 //' | sed 's/libtexlua52 //')'"' --debug

which is a command derived through trial and error as a couple of the packages must be excluded in order to successfully add back the packages. I rename the final ISO as 'localised_pseudo_20.04.iso'.

At this point I can now mimic a standard Ubuntu 20.04 ISO from this localised pseudo 20.04:

isomimicpkgs.sh localised_pseudo_20.04.iso ubuntu-20.04-desktop-amd64.iso

to give me the 'apt' commands to create a localised Ubuntu 20.04 ISO from the localised pseudo Ubuntu 20.04 ISO:

$(grep "^isorespin.sh" isomimicpkgs.log | head -1) --debug
isorespin.sh -i linuxium-ubuntu-20.04-desktop-amd64.iso -b GRUB-64 -e "libxfce4util-bin python3-pyxattr rtmpdump youtube-dl"

which I triumphantly name 'localised_20.04_from_pseudo_20.04.iso'.

Finally I can compare this 'localised_20.04_from_pseudo_20.04.iso' with the earlier 'localised_pseudo_20.04.iso' to shows me the new packages installed as part of Ubuntu 20.04 and the packages I loose as part of the upgrade:


and importantly for me this includes loosing 'phoronix-test-suite'.

This still leaves me the option of manually installing my mimic'ed Ubuntu 18.04 testing environment and performing the upgrade the official Ubuntu way.  However before doing this I want to make sure that I create the most similar environment as possible prior to the upgrade so first I capture the full list of installed packages on Ubuntu 18.04 with:

dpkg-query -Wf '${db:Status-Abbrev}${Package}\n' | grep '^ii' | awk '{print $2}' | sort > source_locally_installed_packages.18.04

Now I can install my 'localised_18.04.iso' on the separate test box. Once installed I need to examine the installation log as 'ubiquity' (Ubuntu's installer) removes some packages it believes are not required:

grep -i removed /var/log/installer/syslog

and I need to re-install them with:

sudo apt install apt-clone cifs-utils dmeventd dpkg-repack gparted grub-efi-amd64 kpartx lvm2 python-crypto python-ldb python-samba python-tdb qt5-gtk-platformtheme qttranslations5-l10n samba-common samba-common-bin

I also need to remove any packages added by 'ubiquity' so I compare the output of running a 'dpkg-query' with the previous 'source_locally_installed_packages.18.04' output and see that I need to:

sudo apt purge grub-pc-bin

As a check I can then compare the 'localised_18.04.iso' with newly locally installed packages using:

isocomparepkgs.sh localised_18.04.iso

which confirms that I have successfully replicated the environment:



Now I can perform the upgrade with

(Alt+F2) update-manager -c -d



As I perform the upgrade I am given the opportunity to monitor what will happen:



and make important decisions:



Once complete I can then mimic the resultant environment to a standard Ubuntu 20.04 ISO with:

isomimicpkgs.sh ubuntu-20.04-desktop-amd64.iso

creating a final 'localised_20.04.iso'.

I can then compare this ISO with the ones created earlier (i.e. 'localised_pseudo_20.04.iso' and 'localised_20.04_from_pseudo_20.04.iso') and see more implications and effects of upgrading for use in my final planning of which approach to use and what information I need to successfully upgrade my testing PC from Ubuntu 18.04 to 20.04.

Hopefully this worked example show the usefulness of my 'ISO' tools and how they can be applied to everyday problems rather than just being used to boot Ubuntu on a 32-bit device.

Please donate if you find the scripts useful using the following link http://goo.gl/nXWSGf as everything helps with development costs.

26 comments:

Luca said...

Hello, I have a question.
I have the famous minix z64a (with the Intel Atom Baytrail Z3735F) and the normal ubuntu server 20.04 installation works fine. The only issue is that when I issue the "poweroff" command, the server doesn't shut down but issues a normal restarts.
It is the famous ACPI problem? How can I fix this?

Linuxium said...

Try "sudo halt -p" without the quotes.

Luca said...

Unfortunately it doesn't work. It keeps restarting. It seems that the hardware interprets the "poweroff" as "reboot". I've tried either with the standard Ubuntu 20.04 kernel and the 5.7.7 kernel

Linuxium said...

What about "sudo poweroff -f"?

Luca said...

Same result, unfortunately.
I see in the `dmesg` this grub command:

Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.7-050707-generic root=UUID=d0d221e6-89d5-4a24-a410-4d1219a059eb ro acpi=force

as you see, "acpi=force" is present.

Linuxium said...

This is starting to sound familiar. I seem to remember also adding "reboot=cold" as a boot parameter fixed it.

Luca said...

Unfortunately, not working again.
I added reboot=cold as dmesg reports:

[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.7.7-050707-generic root=UUID=d0d221e6-89d5-4a24-a410-4d1219a059eb ro acpi=force reboot=cold
[ 0.041723] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.7.7-050707-generic root=UUID=d0d221e6-89d5-4a24-a410-4d1219a059eb ro acpi=force reboot=cold


Tried with poweroff and poweroff -f
same result. It doesn't power off.

Samson said...

Any idea what's wrong?

./isorespin.sh -i ubuntu-20.04.2.0-desktop-amd64.iso -k v5.4.114
Extracting isorespin files ...
Extracting ISO ...
Parallel unsquashfs: Using 2 processors
184068 inodes (204175 blocks) to write

[=========================================================================================================================================|] 204175/204175 100%

created 154818 files
created 19119 directories
created 29137 symlinks
created 8 devices
created 0 fifos
Adding 32-bit GRUB packages ...
Fetching mainline kernel packages ...
Installing mainline kernel packages ...
Processing bootloader/bootmanager ...
cp: error writing 'mnt/efi/boot/grubx64.efi': No space left on device
cp: error writing 'mnt/efi/boot/mmx64.efi': No space left on device
cp: error writing 'mnt/efi/boot/bootia32.efi': No space left on device
Updating ISO repositories ...

Linuxium said...

Are you using the latest version of 'isorespin.sh' i.e. 8.7.0 as I've just run the exact command and it worked.

Samson said...

Yes...
# ./isorespin.sh -v
isorespin.sh: Version: 8.7.0

and apart from that it's seems completed okay.
Inode table size 2343870 bytes (2288.94 Kbytes)
26.45% of uncompressed inode table size (8862288 bytes)
Directory table size 2390950 bytes (2334.91 Kbytes)
41.30% of uncompressed directory table size (5788606 bytes)
Xattr table size 46 bytes (0.04 Kbytes)
38.33% of uncompressed xattr table size (120 bytes)
Number of duplicate files found 37006
Number of inodes 242959
Number of files 186511
Number of fragments 11510
Number of symbolic links 29537
Number of device nodes 8
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 26903
Number of ids (unique uids + gids) 36
Number of uids 14
root (0)
ntp (112)
systemd-timesync (119)
statd (114)
uuidd (100)
usbmux (105)
nvidia-persistenced (118)
avahi (106)
man (6)
unknown (125)
colord (109)
systemd-resolve (121)
systemd-bus-proxy (122)
sshd (104)
Number of gids 27
root (0)
dip (30)
shadow (42)
scanner (113)
nogroup (65534)
lp (7)
audio (29)
netdev (102)
utmp (43)
tty (5)
fuse (105)
pulse (118)
messagebus (106)
mail (8)
staff (50)
rtkit (120)
man (12)
kvm (125)
bluetooth (116)
libvirtd (126)
systemd-timesync (130)
nvidia-persistenced (127)
ssl-cert (124)
sambashare (111)
adm (4)
uuidd (101)
lpadmin (110)
xorriso 1.4.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:../../linuxium-v5.4.114-ubuntu-20.04.2.0-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 1347g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text is too long for Joliet (26 > 16)
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/PoolRZ1x4/Backups/V11Pro/isorespin/iso-directory-structure'
xorriso : UPDATE : 1256 files added in 1 seconds
xorriso : UPDATE : 1256 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 512 bytes from file '/PoolRZ1x4/Backups/V11Pro/isorespin/isohdpfx.bin'
libisofs: WARNING : Cannot add /dists/stable to Joliet tree. Symlinks can only be added to a Rock Ridge tree.
libisofs: WARNING : Cannot add /dists/unstable to Joliet tree. Symlinks can only be added to a Rock Ridge tree.
libisofs: WARNING : Cannot add /ubuntu to Joliet tree. Symlinks can only be added to a Rock Ridge tree.
libisofs: NOTE : Automatically adjusted MBR geometry to 1021/186/32
libisofs: NOTE : Aligned image size to cylinder size by 1435 blocks
xorriso : UPDATE : 0.44% done
xorriso : UPDATE : 9.66% done
xorriso : UPDATE : 16.66% done, estimate finish Fri Apr 23 10:39:46 2021
...
...
xorriso : UPDATE : 99.05% done
xorriso : UPDATE : 99.89% done
ISO image produced: 1519248 sectors
Written to medium : 1519248 sectors at LBA 0
Writing to 'stdio:../../linuxium-v5.4.114-ubuntu-20.04.2.0-desktop-amd64.iso' completed successfully.

Linuxium said...

I'm not sure what the error is however if you respin again and get the same messages about 'cp: error writing' then try these commands:

sed '3578s/)/+512)/' isorespin.sh > test-isorespin.sh
chmod 755 test-isorespin.sh
./test-isorespin.sh -i ubuntu-20.04.2.0-desktop-amd64.iso -k v5.4.114

This will give the file slightly more space and hopefully will fix the issue.

Linuxium said...

Can you also post the results of:

du -sx --block-size=1 ubuntu-20.04.2-desktop-amd64.iso
ls -l ubuntu-20.04.2-desktop-amd64.iso

Samson said...

# ./test-isorespin.sh -i ubuntu-20.04.2.0-desktop-amd64.iso -k v5.4.114
Extracting isorespin files ...
Extracting ISO ...
Parallel unsquashfs: Using 2 processors
184068 inodes (204175 blocks) to write

[=========================================================================================================================================-] 204175/204175 100%

created 154818 files
created 19119 directories
created 29137 symlinks
created 8 devices
created 0 fifos
Adding 32-bit GRUB packages ...
Fetching mainline kernel packages ...
Installing mainline kernel packages ...
Processing bootloader/bootmanager ...
cp: error writing 'mnt/efi/boot/grubx64.efi': No space left on device
cp: error writing 'mnt/efi/boot/mmx64.efi': No space left on device
cp: error writing 'mnt/efi/boot/bootia32.efi': No space left on device
Updating ISO repositories ...

# du -sx --block-size=1 ubuntu-20.04.2.0-desktop-amd64.iso
2865394688 ubuntu-20.04.2.0-desktop-amd64.iso

# ls -l ubuntu-20.04.2.0-desktop-amd64.iso
-rwxrw-rw- 1 nobody nogroup 2877227008 Apr 13 17:35 ubuntu-20.04.2.0-desktop-amd64.iso

Linuxium said...

Can you try:
du -sx --apparent-size --block-size=1 ubuntu-20.04.2-desktop-amd64.iso

Linuxium said...

And then try these commands:

rm -f test-isorespin.sh
sed '/EFI_.*du/s/--block-size=1/-b/' isorespin.sh > test-isorespin.sh
chmod 755 test-isorespin.sh
./test-isorespin.sh -i ubuntu-20.04.2.0-desktop-amd64.iso -k v5.4.114

and see if this fixes the 'cp: error writing' messages.

Samson said...

# du -sx --apparent-size --block-size=1 ubuntu-20.04.2.0-desktop-amd64.iso
2877227008 ubuntu-20.04.2.0-desktop-amd64.iso

Waiting for the result of test-isorespin.sh ...

Samson said...

Passed... Many thanks!

# sed '/EFI_.*du/s/--block-size=1/-b/' isorespin.sh > test-isorespin.sh
# chmod 755 test-isorespin.sh
# ./test-isorespin.sh -i ubuntu-20.04.2.0-desktop-amd64.iso -k v5.4.114
Extracting isorespin files ...
Extracting ISO ...
Parallel unsquashfs: Using 2 processors
184068 inodes (204175 blocks) to write

[=========================================================================================================================================-] 204175/204175 100%

created 154818 files
created 19119 directories
created 29137 symlinks
created 8 devices
created 0 fifos
Adding 32-bit GRUB packages ...
Fetching mainline kernel packages ...
Installing mainline kernel packages ...
Processing bootloader/bootmanager ...
Updating ISO repositories ...
Spinning ISO ...
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on iso-directory-structure/casper/filesystem.squashfs, block size 131072.

Samson said...

I suppose the following warnings can be ignored?

Drive current: -outdev 'stdio:../../linuxium-v5.4.114-ubuntu-20.04.2.0-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 1347g free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text is too long for Joliet (26 > 16)
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/PoolRZ1x4/Backups/V11Pro/isorespin/iso-directory-structure'
xorriso : UPDATE : 1250 files added in 1 seconds
xorriso : UPDATE : 1250 files added in 1 seconds
xorriso : NOTE : Copying to System Area: 512 bytes from file '/PoolRZ1x4/Backups/V11Pro/isorespin/isohdpfx.bin'
libisofs: WARNING : Cannot add /dists/stable to Joliet tree. Symlinks can only be added to a Rock Ridge tree.
libisofs: WARNING : Cannot add /dists/unstable to Joliet tree. Symlinks can only be added to a Rock Ridge tree.
libisofs: WARNING : Cannot add /ubuntu to Joliet tree. Symlinks can only be added to a Rock Ridge tree.

Linuxium said...

Yes these warnings can be safely ignored as they do not affect the respun ISO.

Samson said...

Thanks Linuxium!

20.04 installed got successfully installed in my Dell Venue 11 Pro 5130. I can get both WiFi and sound working but not Bluetooth. Do you have any advices on how I can get the UART based Bluetooth device working (Dell Wireless 1538 with Bluetooth chip Atheros AR3002 HCI-UART interface).

To get Bluetooth services show up I have to manually `modprobe ath3k`:

~# dmesg | grep -i bluetooth
[ 235.086534] Bluetooth: Core ver 2.22
[ 235.086636] Bluetooth: HCI device and connection manager initialized
[ 235.086643] Bluetooth: HCI socket layer initialized
[ 235.086647] Bluetooth: L2CAP socket layer initialized
[ 235.086654] Bluetooth: SCO socket layer initialized
[ 555.213276] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 555.213280] Bluetooth: BNEP filters: protocol multicast
[ 555.213288] Bluetooth: BNEP socket layer initialized

~# rfkill
ID TYPE DEVICE SOFT HARD
0 wlan phy0 unblocked unblocked
1 nfc nfc0 unblocked unblocked

~# rfkill list
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no

1: nfc0: NFC
Soft blocked: no
Hard blocked: no

that's all I can get and no matter what I did I cannot see the buletooth device show up, GUI settings show no Bluetooth interface available.

Linuxium said...

Can you reboot your device and then run 'modprobe ath3k' and then post a link (pastebinit) to a 'dmesg'?

Samson said...

:~# modprobe -v ath3k insmod /lib/modules/5.4.114-0504114-generic/kernel/crypto/ecc.ko
insmod /lib/modules/5.4.114-0504114-generic/kernel/crypto/ecdh_generic.ko
insmod /lib/modules/5.4.114-0504114-generic/kernel/net/bluetooth/bluetooth.ko
insmod /lib/modules/5.4.114-0504114-generic/kernel/drivers/bluetooth/ath3k.ko

https://paste.ubuntu.com/p/FsQj8ZbNCz/

Linuxium said...

The 'dmesg' looks okay so I can only suggest you try blacklisting the module on boot (add 'modprobe.blacklist=ath3k' or 'ath3k.blacklist=yes' as kernel parameters in GRUB) and then once booted try loading the module (with 'modprobe ath3k'). If that doesn't help then I'm out of ideas.

Samson said...

Problem is unrelated with ath3k. I figured out ttyS4 is the Bluetooth interface of Atheros AR3002 HCI-UART chip.

~# dmesg | grep tty
[ 0.102628] printk: console [tty0] enabled
[ 0.729596] serial8250: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[ 4.735517] 80860F0A:00: ttyS4 at MMIO 0x9094d000 (irq = 16, base_baud = 2764800) is a 16550A
[ 4.735701] serial serial0: tty port ttyS4 registered

However,
~# ls -l /dev/ttyS4
ls: cannot access '/dev/ttyS4': No such file or directory

ttyS0-3, ttyS5-31 are all available but not ttyS4.

Linuxium said...

Can you manually attach to 'ttyS0' with the command 'hciattach -s 115200 /dev/ttyS0 ath3k'?

Samson said...

~# hciattach -s 115200 /dev/ttyS0 ath3k
Initialization timed out.

Looks to me /dev/ttyS4 being assigned to somethings else, without a correct device name as an argument, cannot make use of btattach or hciattach to connect the serial UART to the Bluetooth stack for service initialization.

Post a Comment