Hi,
thank you for your reply.
I understand your point, I will try to see if the RT patch works as expected and if I get an improvement in the performance of my system without making too many changes. I will let you know!
[giuliano0697] giuliano0697 https://forum.snapcraft.io/u/giuliano0697
April 15Hi,
thank you for your reply.
I understand your point, I will try to see if the RT patch works as
expected and if I get an improvement in the performance of my system
without making too many changes. I will let you know!
RT wonāt improve performance per se, it just improves the latency
characteristics, namely reduced ālong latencyā outliers and improved
preemption compared to generic. RT and Low-latency kernels actually
reduce performance because of overhead of the extra the preemption
points in the kernel.
Colin
1 Like
quoting from the documentation page i linked:
-
kernel-initrd-modules(array of string)
List of modules to include in initrd. Note: kernel snaps do not provide the core boot logic which comes from Ubuntu Core OS snap.
Include all modules you need for mounting rootfs here.
so add all the module names that are required to find the rootfs device (for USB sticks, āusb-storageā at least) ā¦
1 Like
Hi @ogra,
I added the following to my snapcraft.yaml (by taking the cue from your advice and from https://github.com/muthiahn/ant-kernel-n/blob/5a7af7fcc64f68cb260991a7372a7adb7e83c5b1/snapcraft.yaml):
kernel-initrd-modules:
- ahci
- libahci
- usb-storage
- nls_iso8859-1
- virtio_scsi
- sdhci
- sdhci-pci
- sdhci-acpi
- mmc-block
- hv_storvsc
- hv_vmbus
Now I was able to correctly configure Ubuntu Core.
Although, after performing few operations, I get the error:
No left space on device
This seems quite strange to me, since I performed the same operations with the alredy provided UC18 generic X86 image and everything went smooth, and since when using the $ df command I get that there is still much space on the USB device.
I also tried $ sudo umount /tmp, but nothing changes.
Do you have any idea about why this can happen?
UC16 and 18 resize the writable partition on first boot to the full device size (UC20 works differently and actually creates new partitions from scratch) ā¦ might be that the resizing did not properly work, compare the partition table with the actual filesystem size on the booted device ā¦ as a quick hack to get more space in your image you can define a minimal size, there is an ubuntu-image option that makes sure writable comes up with a minimum ā¦
I tried to look for it at this link (http://manpages.ubuntu.com/manpages/bionic/man1/ubuntu-image.1.html), I suppose it is the āimage-size optionā¦ So I used the following command:
$ ubuntu-image snap --extra-snaps my-custom-kernel.snap --image-size 6G my-model.model
Unfortunately, I still get the same issueā¦
IIRC there are logs in /run/initramfs (only right after the first boot !!) that might have some more info about resize issues ā¦
OK I paste here the contents of the files that are in that folder:
fsck-writable
1618829641: start
/dev/sdb3 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!
1618829641: end
new-gpt-table.txt
Disk /dev/sdb: 30031872 sectors, 14.3 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 0C75F009-7D0A-46E3-B844-1C9C7D36B065
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30031838
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02 BIOS Boot
2 4096 106495 50.0 MiB EF00 EFI System
3 106496 30031838 14.3 GiB 8300 writable
old-table.txt
BYT;
/dev/sdb:15376318464B:scsi:512:512:gpt:SanDisk Ultra:;
1:1048576B:2097151B:1048576B::BIOS Boot:bios_grub;
2:2097152B:54525951B:52428800B:fat32:EFI System:boot, esp;
3:54525952B:1040996351B:986470400B:ext4:writable:;
resize-writable.txt
fixing backup GPT
The operation has completed successfully.
Deleting partition 3
The operation has completed successfully.
Creating partition 3 at 106496
The operation has completed successfully.
Setting GUID of partition 3 to 8A005E3F-5F77-4BB5-BCB7-AC4683ACBF1F
The operation has completed successfully.
Setting name of 3 to writable
Setting name!
partNum is 2
REALLY setting name!
The operation has completed successfully.
e2fsck 1.42.13 (17-May-2015)
/dev/sdb3 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!
Moreover, using $ lsblk I saw that the /dev/sdb3 partition is the /writable one.
What do you suggest to fix the issue?
hmm, are you using the ubuntu-image snap (as you should) or some outdated deb version ?
(the snap should ship a more recent e2fsprogs inside)
to hack around this you should be able to disable metadata_csum on the writable partition of the USB stick right after flashing it on your PC:
sudo tune2fs -O ^metadata_csum /dev/<whatever device the writable partiton of the USB stick has>
Yes I am, in particular I use the command:
$ ubuntu-image snap --snap my-custom-kernel.snap my-model.model
I installed the ubuntu-image snap using $ sudo snap install ubuntu-image --classic
To perform this step, I connected the USB stick to a Ubuntu 18.04, and then I used:
$ sudo tune2fs -O ^metadata_csum /dev/sdb3
I got the following āerrorā message:
tune2fs 1.44.1 (24-Mar-2018)
This operation requires a freshly checked filesystem.
Please run e2fsck -f on the filesystem.
So, I used:
$ sudo umount /dev/sdb3
$ sudo su
# e2fsck -f /dev/sdb3
In this way I got:
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: 43/60288 files (4.7% non-contiguous), 167673/240839 blocks
And then I was able to use # sudo tune2fs -O ^metadata_csum /dev/sdb3, yielding:
tune2fs 1.44.1 (24-Mar-2018)
Disabling checksums could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) <proceeding>
Although, when booting UC again, I still get the same issue.
I have also tried to use ubuntu-image to build a custom UC 18 image that uses pc-kernel instead of my custom kernel and the issue remains, so I suppose that it is due to ubuntu-imageā¦
Instead, using the UC 18 generic X86 image does not cause the issue.
EDIT: if I build the image using another computer I do not get the issue, I do not know why since the ubuntu-image version is the sameā¦