I have a true very simple idea how to decide the importance of this bug,
just add a field of how much time and money we lost with this shitty
bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1489855
> So is there still a bug with 20.04 as you suggest?
At the time I posted my comment, yes there absolutely was.
A regression had been introduced in the daily 20.04 builds, that made
persistence consistently fail on some machines. This was confirmed by
other people too.
Now, since I added my
So is there still a bug with 20.04 as you suggest? If the bug was only
squashed with 19.10 are you going to give up on persistence for Rufus
and just wait for the bug to get fixed? Perhaps another five years.
Seems better to me to work with what we have rather that wait for a
perfect world.
--
> Making a Grub2 booter that uses Persistent partitions is not a problem
[if you create 4 partitions in a very specific way and with this
specific file system for the content extracted from the ISO]
I hope you can see the issue with the above because then I could add:
As demonstrated above,
Making a Grub2 booter that uses Persistent partitions is not a problem.
Start with a 1MB grub2 core.img partition flagged bios_grub. Add a 250MB
FAT32 EFI partition flagged boot,esp. next add an ext4 partition large
enough for the Ubuntu ISO's contents and finish with a ext4 casper-rw
partition
I added a persistent partition to a UNetbootin focal-desktop-
amd64-20200325 install and it works okay. Just like pre-14.04.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1489855
Title:
Change to
Actually, no, the success I got was actually a fluke. This is currently
broken again in 20.04, as per
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
After some additional tests, it seems I was a bit too hasty to declare
that there exists a regression, as, even though a similar error is
displayed as the one from the original bug, the persistent partition
appears to be mounted regardless.
For the record however, `/var/log/boot.log` displays the
Please note that this appears to be broken again in Ubuntu 20.04!
Could the Ubuntu maintainers please treat this bug, which have been very
negatively affecting scores of Ubuntu users a bit more seriously?
By the looks of it, the plight of 18.04 LTS users will continue in 20.04
when it comes to
I hoped that you (the developers) had upgraded casper in 18.04.4 LTS.
But if it is too late for that, I ask you to prepare the the upgrade
well in time for 18.04.5 LTS.
I am willing to test that the iso file works correctly, both 'as usual'
and to create persistent live drives using the new
Since the patch didn't make it in time for 18.04.3 but 18.04 is the
latest LTS release available before 20.04, I'd wager there'd be at least
a few others looking to create a persistent LTS USB drive facing this
issue. Also, I spent a few hours figuring this out so hopefully this
saves someone some
Hi, is this change effective for other Ubuntu flavors?
I tried booting Xubuntu 19.10 prepared with Rufus but despite
persistence being enabled the casper-rw remained unmounted in live
system. The same thing works with offical Ubuntu 19.10 image.
--
You received this bug notification because you
This bug was fixed in the package casper - 1.414
---
casper (1.414) eoan; urgency=medium
* Use udev-created symlinks to find filesystems by label.
* Fix find_cow_device and find_files to not unmount filesystems that were
already mounted (LP: #1489855)
-- Michael
Ah great, thanks for testing! I've uploaded the fix to eoan just now. I
guess after some testing we should think about backporting to bionic
(although it's too late to try to get it into 18.04.3 now)
And it's interesting to hear why you're interest. The reason I am
interested in this sort of
> the ones that matter are in the initrd (casper/initrd in this case).
D'oh! Of course they are... The way I was trying to test your changes
was indeed pointless.
> OK, that wasn't so bad:
https://code.launchpad.net/~mwhudson/ubuntu/+source/casper/+git/casper/+merge/370351
Awesome.
I just
OK, that wasn't so bad:
https://code.launchpad.net/~mwhudson/ubuntu/+source/casper/+git/casper/+merge/370351
It seems to work for your test case, my test case (where you dd the
image then create a partition), and even for the case where you create a
file called casper-rw containing an ext4
On Thu, 18 Jul 2019 at 23:40, Akeo wrote:
> Thanks for looking into this.
>
> I've been trying to validate the above fix, but I'm still seeing the
> same issue. In other words, Ubuntu Live still seems to bail out to the
> busybox console as soon as you use add 'persistent' to the Kernel
>
Thanks for looking into this.
I've been trying to validate the above fix, but I'm still seeing the
same issue. In other words, Ubuntu Live still seems to bail out to the
busybox console as soon as you use add 'persistent' to the Kernel
options.
Here's what I did:
- Extracted the content of
This bug was fixed in the package casper - 1.413
---
casper (1.413) eoan; urgency=medium
* Fix ftbfs by restoring empty conf.d missing from git import.
-- Michael Hudson-Doyle Tue, 16 Jul 2019
13:40:33 +1200
** Changed in: casper (Ubuntu)
Status: Confirmed => Fix
There's a lot going on in this bug but I've just uploaded a change to
casper that fixes at least something in the right area. With this
change, I can run this script on an ISO:
#!/bin/bash
ISO=$1
truncate -s 1G $ISO
maxend=$(sfdisk $ISO -l -q -o end | tail -n +2 | sort -n | tail -n1)
I gave up on this bug. My workaround is to install a full system onto a
USB. 2 USBs required for the setup.
I create the boot media as per general instructions. Last time I used
Rufus.
And I set my target to 2nd empty USB, using the custom partition
options.
--
You received this bug
** Tags added: id-5cfac2e9c17e1d85a84198b8
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1489855
Title:
Change to mount sequence order breaks persistence on casper-rw
partitions
To manage
This is a pretty serious and rather obvious bug, once you understand
what's going on.
As pointed out by @DC-THINK, whom I will mostly be paraphrasing here,
the gist of it is: /usr/share/initramfs-tools/scripts/casper-helpers may
unmount a previously mounted device, that it should *NOT* leave
look into the code, u can also see the fault posted debug log above:
when using a USB HDD(/dev/sdb) partition /cdrom(/dev/sdb1 vfat) casper-
rw(/dev/sdb2 ext2)
1. mount /dev/sdb1 /cdrom (/casper is exist(will load filesystem.squashfs
lately))
2. find casper-rw(file and partition in same
this is really disappointing...
mount: mounting /cow on /root falied: invalid argument overlay mount
failed
i just changed the lines in /usr/share/initramfs-tools/scripts/casper and the
live system booted without any problems...
could you please finally fix this bug !!
@seann-giffin i
I've been tracking this bug for a few years now. For a bug of such HEAT
shouldn't it by now at least have an importance other than UNDECIDED?
And shouldn't the bug have enough information to be TRIAGED instead of
CONFIRMED. It just seems this bug is not moving forward and just going
to sit in it's
On ext4, the journal is written to the same location over and over
again, which can have a seriously negative impact on the lifespan of the
flash memory. If you want your USB stick to last longer, consider using
ext2 instead because it doesn't use journaling. Otherwise, well done
Pankaj!
--
You
There is a workaround for avoiding this bug when creating such pen-
drives. You should create three partitions : 1) A fat32 formatted 350MB
for storing 'boot' and 'EFI' folders, 2) An ext4 formatted 2GB for
storing the rest of Ubuntu's ISO content & 3) An ext4 formatted and
labelled as 'casper-rw'
well.. no.. if you change the squashfs file you replace the whole
system.. you will then have ubuntu 14.04 and NOT 16.04
just use the information from post #14 (the path to the file in
question) and replace the faulty version of the function setupunionfs()
with the one i attached to post #15
Does this mean I can, say, take the squashfs from a broken Kubuntu 16 live usb
& replace the aquashfs of a working kubuntu 14 usb? Or will that break
everything else in sight?
Because, I am NFI on how/where to find Casper.
Molto congrats on finding the solution!
--
You received this bug
please fix this bug with already! proposed fix. this bug is (let's say
it one more time) CRITICAL!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1489855
Title:
Change to mount sequence order breaks
ok... i ran into this bug AGAIN and i was dumb enough to think that this
would definitely be resolved by now (since the bugfix is already
provided here) i lost hours with debugging until i finally realized
that this bug is still there..
could you please fix this ? it's 2 minutes work ... copy
32 matches
Mail list logo
