Originally Posted by
C.S.Cameron
Computer 1: HP, Elitebook, 8560W, i7, BIOS, 24 GB RAM, Nvidia Quadro 2000, Windows 10 installed,
Computer 2: Acer 8572, i5, BIOS, 8GB RAM, Ubuntu 18.04 upgraded from 16.06 (Unity) installed,
Focal-desktop-amd64-2020-02-23, Tested "Persistent" and "usbdata" installs, 4GB Kingston Data Traveler USB2.
After starting I get: "Oh no! Something has gone wrong... log out", with both 2.6.0 mkusb-plug "usbdata" and "persistent" installs. First few runs only.
When shutting down I get ... Access beyond end of device, that scrolls for five to ten minutes. with persistent installs but not usbdata installs.
When quitting Guidus12.4.4 Persistent, it now has message: "Please remove the installation medium then press enter" for both for both persistent and usbdata installs, I think this was happening with previous version also.
All above items happen with both the HP and Acer.
Originally Posted by
C.S.Cameron
- Ran mkusb-plug in the Elitebook from Full install of 18.04.3 in 32GB DataTraveler3.
- Have not tried running mkusb-plug in Ubuntu Focal yet.
- I ran mkusb-plug in Ubuntu 18.04 upgraded from 16.04.6 in the Acer.
- I have tested with 'English US' only.
-I made a live and persistent live drive of Ubuntu Focal using both guidus and mkusb-plug. Only the persistent mkusb-plug says ... Access beyond end of device. I will try installing to a different USB today.
A race condition?
I tested with a system created for this purpose in my Toshiba computer with a generation 3 Intel i5 CPU and 4 GB RAM booted in BIOS mode. This is different from your Acer, but maybe good enough for a comparison.
- Ubuntu desktop 16.04.6 LTS and release-upgraded to 18.04 LTS and made up to date (with the 4.15.0-91 kernel series.
-
- Set up ppa:mkusb/unstable and installed mkusb mkusb-plug usb-pack-efi
- Zsynced Ubuntu Focal iso file dated 2020-03-25 'focal-desktop-amd64.iso'
Code:
$ md5sum focal-desktop-amd64.iso
99a91ca69ee9af5d6ff427d56cabcf8a focal-desktop-amd64.iso
- Used the USB 2 drive Kingston Datatraveler_G3 (an old and slow USB 2 drive with 4 GB, as similar as possible to what you used in your test).
0. I wiped the whole Kingston USB device to make the conditions as good as possible.
1. I used mkusb-plug making a live-only system with an NTFS partition:
Everything worked as expected (as I wanted it to work) both when running mkusb-plug and when booting into the live-only system and running it.
2. mkusb-plug making a persistent live system:
Creating the system had this problem:
partprobe could not refresh the partition table after creating the partition for persistence. There was an output from function 'prober' in 'mkusb-sedd':
Code:
function prober {
pcnt=0
partnr=/dev/$(lsblk -lno name "${target}" | sort | tail -n1)
while [ "$partnr" == "$partn0" ]
do
if [ $pcnt -gt 10 ]
then
echo -e "$redback prober: cannot identify new partition made by fdisk $resetvid"
echo -e "$redback This can sometimes be fixed via two steps $resetvid"
echo -e "$redback 1. wipe the first mibibyte with mkusb-dus $resetvid"
echo -e "$redback 2. unplug and replug the target drive. $resetvid"
echo -e "$redback Sometimes, if the drive is getting slow, $resetvid"
echo -e "$redback you need to wipe the whole target drive, $resetvid"
echo -e "$redback or reboot the computer to make this work. $resetvid"
exit
elif [ $pcnt -gt 8 ]
then
echo -en "$redback Please unplug and replug the target drive, $resetvid
$trgtxt
$redback and then press the Enter key to continue $resetvid"
read
sleep 4
umount "${target}*" 2> /dev/null
fi
partprobe 2> /dev/null
delay=$(( 4 + pcnt ))
sleep "$delay"
pcnt=$((pcnt + 1))
partnr=/dev/$(lsblk -lno name "${target}" | sort | tail -n1)
echo "prober: $partnr for persistence"
done
}
I followied the advice from 'prober': Unplugging and replugging did not help, but wiping the first mibibyte and rebooting helped. After that mkusb-plug worked as expected. I have seen this problem before (that is why I created the function 'prober'). There are less problems with fresh and responsive drives (so I recommend a fast USB 3 drive for persistence and/or other read-write partitions, but all drives can get tired, and then wiping the whole device will often help).
The persistent live system had this problem:
It seemed to work correctly when booted, but at shutdown there was the following complaint:
Code:
EXT4-fs error (device sdb3): ext4_free_branches:1019: inode £32962: block 133124: comm systemd-journal: Read failure
This was preceded by several buffer I/O errors on dev sdb device sdb3.
The error outputs were preceded by the output text "Please remove the installation medium, then press ENTER:"
I pressed the Enter key and rebooted into the persistent live drive.
The persistent live system could reboot and what I had saved was there (the bash history and a created text file).
My experience is that mkusb-plug and persistent live systems are reliable with a faster and more responsive USB drive than this old USB 2 drive, but also an originally fast USB 3 pendrive (for example Sandisk Extreme) may need wiping (wipe the whole device with mkusb-dus).
I repeated shutdown and had the error output again. But when tested in my main computer the file system seemed good,
Code:
$ LANG=C sudo e2fsck -f /dev/sdc3
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
writable: 1370/73872 files (6.0% non-contiguous), 138723/294912 blocks
I will test with the same Ubuntu system and some other USB drives and update this post ...
Edit 1:
Test with a Kanguru SS3 14,8GiB (16GB) USB 3 drive creating the drive was successful (without wiping the drive before).
But running the persistent live system has problems at shutdown. After the system has written "Please remove the installation medium, then press ENTER:" there is some maybe(?) harmless output: 'I/O error', but after a few more seconds there will be a lot of output about trying where it should not try,
Code:
Access beyond end of device
Access beyond end of device
...'
and there are errors in the persistent file system,
Code:
$ sudo e2fsck -f /dev/sdc3
e2fsck 1.44.1 (24-Mar-2018)
Superblockets senaste monteringstid ligger i framtiden.
(med mindre än en dag, förmodligen för att hårdvaruklockan går fel)
Superblockets skrevs senast i framtiden.
(med mindre än en dag, förmodligen för att hårdvaruklockan går fel)
Pass 1: Kontrollerar inoder, block och storlekar
Pass 2: Kontrollerar katalogstruktur
Pass 3: Kontrollerar katalogförbindelser
Pass 4: Kontrollerar referensräknare
Pass 5: Kontrollerar gruppsammanfattningsinformation
Antal fria block är fel (3079575, räknade=2995601).
Fixa<j>? ja
Antal fria inoder är fel (796853, räknade=796697).
Fixa<j>? ja
writable: ***** FILSYSTEMET MODIFIERADES *****
writable: 1415/798112 filer (5.6% ej sammanhängande), 191599/3187200 block
But the persistent live system works as expected. The history and a saved file is still there.
I have not seen this before, and it seems to be an error that is caused by a new bug maybe in the iso file, maybe in mkusb-plug. I will continue testing ...
Edit 2:
Test with a Sandisk Extreme 14,9GiB (16GB) USB 3 drive creating the drive was successful (without wiping the drive before).
The result is the same with the Sandisk USB 3 drive as with the Kangaroo USB 3 drive (except that the numbers of free blocks are different, which is easy to understand because the exact sizes are different and other conditions may differ too).
Code:
$ sudo e2fsck -f /dev/sdc3
[sudo] lösenord för olle:
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Kontrollerar inoder, block och storlekar
Pass 2: Kontrollerar katalogstruktur
Pass 3: Kontrollerar katalogförbindelser
Pass 4: Kontrollerar referensräknare
Pass 5: Kontrollerar gruppsammanfattningsinformation
Antal fria block är fel (3036205, räknade=3033889).
Fixa<j>? ja
Antal fria inoder är fel (806528, räknade=806514).
Fixa<j>? ja
writable: ***** FILSYSTEMET MODIFIERADES *****
writable: 1326/807840 filer (6.0% ej sammanhängande), 192245/3226134 block
I have the following focal iso files, and can try to find out if there is a difference between the oldest and newest versions, and in that case where the problem appeared. I would guess that the flavour makes no difference, but I can check for that too.
Code:
$ ls -ltr ../*/focal-desktop-amd64*.iso|cut -d ' ' -f 6-
feb 6 07:01 ../ubuntu/focal-desktop-amd64-2020-02-06.iso
feb 7 07:32 ../xubuntu/focal-desktop-amd64-2020-02-07.iso
feb 12 16:00 ../lubuntu/focal-desktop-amd64-2020-02-12.iso
mar 12 04:36 ../kubuntu/focal-desktop-amd64.iso
mar 25 01:29 ../xubuntu/focal-desktop-amd64.iso
mar 25 07:27 ../ubuntu/focal-desktop-amd64.iso
mar 25 17:08 ../lubuntu/focal-desktop-amd64.iso
Edit 3 and 4:
In order to do things faster I tested in a Kingston SV300S37A60G SSD with 60 GB via a USB to SATA adapter:
- Ubuntu Focal dated Februay 6 (before switching to 'writable', so uses 'casper-rw')
- Kubuntu Focal dated March 12 (after switching to 'writable')
work as expected (the bug described above does not affect these versions. Unfortunately I have saved no iso files between March 12 and March 25 (because I did not expect this bug to appear).
This was promising. Then I tested also Lubuntu Focal dated March 25 (the same date as that of Ubuntu that failed. It worked in the SSD, but when tested in a 16 GB pendrive (the Kanguru drive described earlier) it failed. Is this a race condition like the problem that 'casper-rw' (now a second choice after 'writable') works only in some computers? Also the Kubuntu persistent live system is affected by this bug, when installed in the Kanguru pendrive.
I tested the persistent live drives in two computers, a Dell Latitude E7240 and a Lenovo V130-14IKB both with Intel i5 processors and 8 GiB RAM.
Edit 5:
I continued testing on March 27, this time with a persistent live drive made from Ubuntu 20.04 LTS amd64 2020-02-06-08 in a Sandisk Extreme USB 3 16 GB pendrive, that was wiped (totally overwritten with zeros to be as responsive as possible.
I created the persistent live drive in my main computer with Lubuntu 18.04.x, originally installed as 18.04.1 LTS and kept with the 4.15 kernel series. I used mkusb-plug.
Such a persistent live drive has worked before, and the casper package is the old one inherited from Eoan using casper-rw. So I had to re-label the partition for persistence.
I booted into the persistent live system in the Lenovo V130 (which I used also yesterday). There was persistence as expected.
Normally I have pressed the Enter key, when "Please remove the installation medium, then press ENTER:" was written to the terminal window, and things were looking good. With the experiences from yesterday I waited a while, and yes, the spamming with
Code:
Access beyond end of device
Access beyond end of device
...'
started also in this case.
The computer was shut off directly after pressing the enter key. After that I moved the pendrive to the main computer and checked the file system of the partition for persistence. I repeated the procedure above adding some data to persist, and the file system was clean.
Code:
$ sudo e2fsck -f /dev/sdc3
e2fsck 1.44.1 (24-Mar-2018)
Pass 1: Kontrollerar inoder, block och storlekar
Pass 2: Kontrollerar katalogstruktur
Pass 3: Kontrollerar katalogförbindelser
Pass 4: Kontrollerar referensräknare
Pass 5: Kontrollerar gruppsammanfattningsinformation
casper-rw: 1626/811008 filer (7.0% ej sammanhängande), 177838/3242006 block
So my conclusion is that this 'access beyond end of device' is a bug, but maybe a bug we can live with because it appears only after the system is ready for shutdown/reboot. In some cases the number of free blocks and free inodes are correct, in other cases they are not correct, but persistence seems to work and the mismatches can be corrected without damaging the stored data.
Edit 6:
The beta versions of the Focal iso files are still suffering from this bug, but I have a feeling that they behave slightly better than the iso files made one or two weeks earlier.
sutireme
Adv Reply
Bookmarks