@robert key,
Please post a link here to that new bug report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer works
To
Will do.
Rob
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer works
To manage notifications about this bug go to:
On Tue, 9 Jun 2020 at 21:31, robert key <1863...@bugs.launchpad.net>
wrote:
> I have also had this persistence problem with ubuntu 20.04.
> Casper will not load a file labelled Casper-rw. It does use a partition
> labelled Casper-rw.
> Ubuntu 19.04 persistence works with files and partitions
I changed the file name from casper-rw to writable and now it works. Thanks.
Took me 5 days to realise there was a bug :)
Rob
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new'
I have also had this persistence problem with ubuntu 20.04.
Casper will not load a file labelled Casper-rw. It does use a partition
labelled Casper-rw.
Ubuntu 19.04 persistence works with files and partitions labelled casper-rw.
Rob
--
You received this bug notification because you are a member
@sudodus:
20.04 is the first Ubuntu version to have "maybe-ubiquity" in grub.cfg.
previously Ubuntu's grub had an "Install Ubuntu" menuentry option.
>From Ubuntu 19.10:
linux /casper/vmlinuz file=/cdrom/preseed/ubuntu.seed only-ubiquity
quiet splash ---
This would make the Try/Install
@ C.S.Cameron (cscameron),
I think I understand now. You can remove the boot option maybe-ubiquity
from the 'linux line' of grub.cfg:
from
menuentry "Ubuntu - persistent live" {
search --set=root --fs-uuid 2020-04-23-07-51-42-00
set gfxpayload=keep
linux
Best I think if the Disk check only ran once on the first boot of a new
Live or Persistent USB drive and then vanished forever. Is there really
any need for it to run every boot?.
It also seems that the Try Ubuntu / Install Ubuntu screen is back with a
vengeance. It disappeared from persistent
@ Michael Hudson-Doyle,
When booting a live system of Ubuntu 20.04 there is file and disk
checking.. Not just with Live USB but with Persistent USB also.
If not fast enough with ctrl-C it runs until over 80% complete. Very
irritating. If it was just a run once it would not be so bad.
Is there
Since there has been no follow up from Michael on this critical
question, I have opened a request to drop or alter 'writable' as a new
persitent label in
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1872065.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Not sure how this will paste/read, but my findings..
(original can be viewed at
https://docs.google.com/spreadsheets/d/18-XMDjy5lWiHFqFww_865jR6hbcHf00MI_Z92PayDMM/edit#gid=0
)
hp dc7900, 1x dell 755, dell 790
box (copied from list; most detail from lshw) debug (/cow size) start
For those who have dad a problem with scrolling when shutting down, I
noticed that pressing enter shuts things down.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new'
The package casper version 1.445 is bundled with the current Lubuntu iso
file dated 2020-04-09. I tested it (made a persistent live USB-connected
SSD) in one of my computers that were affected by this bug, the Toshiba.
Persistence works with the label 'casper-rw' :-)
So my alert in comment #62
By the way, today and during the weekend (Easter) 3 more persons are
testing your 'hack', capeer-initrd.gz. We have found a few more
computers that are affected by this bug, and your hack works in those
computers. You find some results via
https://ubuntuforums.org/showthread.php?t=2440260
So it
So it seems our request not to use 'writable' is being ignored still,
and that Ubuntu is just going to go ahead and introduce support for a
completely new label that, not only no other distro appears to be using,
but also nobody has really been asking for:
It seems to me that the description of the bug-fix does not match this
bug.
Are you describing a fix for another bug, or is it only the description,
that is wrong or difficult to understand?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This bug was fixed in the package casper - 1.445
---
casper (1.445) focal; urgency=medium
* Fix segfault in casper-md5check when plymouth is not installed (i.e.
Ubuntu Server).
-- Michael Hudson-Doyle Thu, 09 Apr 2020
10:48:20 +1200
** Changed in: casper (Ubuntu)
... or like asking the US to change the name of the 'dollar' to
'valuable' ;-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no
Sort of like asking the British to change the name of the pound to
dollar.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer
> If it ain't broke, don't fix it.
Then that makes 3 of us making that point now. ;)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10
Ubuntu has been using casper-rw and home-rw ever since it was changed
from casper-cow back around 7.04.
If it ain't broke, don't fix it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
> However home-rw partitions still work when the other persistent
file/partition is named writable.
Again, why would this not work when the other partition is named
'persistence' instead of 'writable'?
I still fail to see the point you are trying to make. Can you please
elaborate on the issue
The persistent file/partition names casper-rw and home-rw should be retained.
However home-rw partitions still work when the other persistent file/partition
is named writable.
It is nice having the option for a home-rw file/partition. It is
interchangeable with /home partition in a Full install
I'll let Michael elaborate but I really don't see how that wouldn't
work.
20.04 is introducing *NEW* alternative 'writable' label for persistent
partitions. This is a brand new label that is being introduced.
So my take on this is that, if we are introducing a brand new label for
persistent
@Akeo Not sure renaming the persistent partitions to persistent works.
There are two kinds of persistent file or partition in Ubuntu. casper-rw
is the catch all and takes new programs, data and settings, when there
is no home-rw persistent partition. When there is a home-rw partition,
home-rw
Thanks for testing the casper-rw fallback. I'll get that uploaded.
I see "ln: /tmp/mountroot-fail-hooks.d/scripts/init-premount/lvm2: No
such file or directory" message sometimes, I think it's harmless
(although I guess someone should look into it).
The superblock stuff does sound a bit worrying
Completed my testing on the 3 UEFI machines I have that were displaying
the symptoms before (2 intel NUCs and one ASUS based UEFI PCs, ranging
from 2-cores to 6-cores, and ranging from 2010 to 2020), and I am happy
to report that, no matter how many times I boot the system, the 'casper-
rw'
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer works
To manage notifications about this bug go to:
I tested with the current casper-initrd with a current Lubuntu Focal
persistent live system, and it works with a 'casper-rw' partition also
in the computers where it did not work before as described in post #25:
1. a Toshiba laptop with an Intel i5 generaton 3 CPU (in BIOS mode and
UEFI mode)
> I'm seeing "access beyond end of device" for /dev/sda and
> "I/O error while writing superblock" for /dev/sda2
> (peristent partition) on powerdown/reboot.
I can confirm this. I have tested in several computers and it happens in
all of them.
--
You received this bug notification because you
Thanks for the update.
Initial testing seems to indicate that the extra delaying appears to
work, but I still need to check this out a bit more.
I will point out that during one boot (after rebooting the same machine
a few times), I got the following fatal error:
ln:
Here's the debdiff of my proposed fix
** Patch added: "lp-1863672.diff"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5348574/+files/lp-1863672.diff
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Hi, I've uploaded yet another initrd -- I think this one might fix the
bug, hopefully. It seems that for whatever reason, it takes a long time
for the block device to show up at all in your system (seems it's more
the kernel being slow rather than udev lagging behind which is what I
suspected at
Here you go. If you really need the full content of /run let me know.
** Attachment added: "udev-files-nuc10i7-20200406-3.zip"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5348128/+files/udev-files-nuc10i7-20200406-3.zip
--
You received this bug notification
Hmm this is interesting, and maybe points to a bug in initramfs-tools :(
That /dev/disk/by-label directory should be populated by the time init-
top/udev exits.
Can you download and try again (added a bit more logging)? The zip of
all of /run is perfect.
--
You received this bug notification
Oh, and since I managed to get one occurrence where persistence worked
with the same drive (all I did was reboot a few times), I'm attaching
the same data from a session where 'casper-rw' was mounted. The most
obvious difference I can see is that this time, udev-ls.txt was not
empty.
**
Thanks Michael.
As you know, I would strongly favour reverting the problematic changes
so that everybody has more time to analyse where the issue lies (and
especially why some machines don't seem to be affected), but I think I
made my position clear already so I'll leave you and the release team
I'll have a conversation with the release team about this. In the mean
time, I've updated https://people.canonical.com/~mwh/casper-initrd.gz
with one that might work better (no need to uncompress it btw).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
> So can we please revert support for 'writable' in 20.04, and use the next
> release to try to fix the issues with trying to support 2 partition labels?
...
> Again, unless you have confidence that you know precisely what the issue is,
> and should be able to fix it right now, I would advocate
Hi Michael, thanks for looking into this.
> I don't think anyone can claim with a straight face that casper-rw is
> anything other than opaque.
It is still a lot more searchable than 'writable'. As I explained above,
'writable' yields next to nothing in terms of letting users understand
why a
I tried (and failed) with the current Focal iso files of Ubuntu and
Lubuntu. Should I try with Ubuntu 19.10 or specifically with Ubuntu
Focal Beta?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
@Michael Hudson-Doyle,
I have tried but cannot boot with your casper-initrd file. I extracted
it (with gunzip) and pointed to it in grub.cfg with a custom menuentry.
I come to Busybox:
(initramfs) unable to find a medium containing a live file system
The 'standard' menuentry works (with
First of all, I'm sorry I appear to have been neglecting this bug. It's
hard to debug something you can't see! And I've had lots of other things
on my plate unfortunately.
I don't think anyone can claim with a straight face that casper-rw is
anything other than opaque. We could have an argument
** Changed in: casper (Ubuntu)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer works
To
Please do not go to release with this issue!
This is a MAJOR regression compared to 19.10, and considering the amount
of pain the previous persistent issue with LTS has caused (just go to
reddit, superuser or askubuntu and search for "mounting /cow on
/root/cow failed" reports to get an idea of
@Michael Hudson-Doyle,
I am willing to help you (to respond as soon as possible to requests for
testing in my computers). But I am also ready to release tools that can
identify 20.04 and modify the label accordingly.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
I definitely hope to fix the bug before release. But not being able to
reproduce it does make it hard.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method
@Brian Murray,
As a developer and maintainer of software to create persistent live
drives, I have to consider the race condition affecting several
computers, when using the old 'casper-rw' label. Can I expect that you
will let soneone spend time trying to fix the bug, or should I modify my
** Tags added: rls-ff-incoming
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10 no longer works
To manage notifications about this
'casper-rw' was not a name which is easily understood while 'writable'
is and given that the partition is being used more (with the new server
installer) a decision was taken to rename it to something that was more
understandable. Additionally, 'writable' is also used with the images we
produce
I agree with Sudodus, when I started using Ubuntu the persistent partition was
labeled casper-cow.
I have finally gotten used to casper-rw.
Why change it to writable, It seems to be identical to casper-rw and works the
same way with home-rw.
Are we going to change the name of home-rw to
@Michael Hudson-Doyle,
Why have you changed to 'writable' as the primary label of the partition
for persistence?
How committed are you to use 'writable' instead of 'casper-rw'?
By the way, are you aware of the current Debian corresponding label,
'persistence'? Debian uses the boot option
** Attachment added: "journalctl.log"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5332775/+files/journalctl.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Quiet is always removed when persistent live by mkusb-plug because
'quiet splash' is replaced by 'persisstent '. Anyway, I ran the same
Xubuntu Focal system, that I tested according to comment #25 in the
Toshiba laptop
http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/
in
Yes, so roughly speaking it works on faster machines and fails on slower
machines. (I also tested your steps on my laptop, and it worked there --
but my laptop is a t480s with nvme so that's consistent). I do have a
slower machine that I use for testing but I'm travelling and so don't
have access
@Michael Hudson-Doyle,
After some more testing I have to add some (maybe confusing, maybe
helpful) information:
A - The bug appears in
1. a Toshiba laptop with an Intel i5 generaton 3 CPU (in BIOS mode and
UEFI mode)
http://www.toshiba.se/laptops/satellite-pro/c850/satellite-pro-c850-19w/
@Michael Hudson-Doyle,
The bug might not appear in your VM.
I think a very very detailed instruction to do what I did is to
1. Work in *buntu 18.04.x LTS which is updated and full-upgraded to be
up to date
2. Install mkusb-plug according to comment #14
3. zsync any current Ubuntu desktop
typing error in the previous comment:
change 'after re-labeling the drive to 'writable' and reboot'
to 'after re-labeling the partition for persistence to 'writable' and reboot'
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So I tried to reproduce this in a VM and failed. This is what I did:
$ cd ~/isos/
$ zsync
http://cdimage.ubuntu.com/ubuntu-server/daily-live/pending/focal-live-server-amd64.iso.zsync
[...]
$ cd ~/images/
$ truncate -s 1G casper-rw.img
$ truncate -s 1G root.img
$ parted --script --align optimal
This bug has been reported on the Ubuntu ISO testing tracker.
A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1863672
** Tags added: iso-testing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Argh sorry I've been meaning to look into this but other things keep coming
up. To be clear: an existing casper-rw partition *should* be being used.
It's a bug that it is not.
On Fri, 28 Feb 2020, 21:25 sudodus, <1863...@bugs.launchpad.net> wrote:
> > I noticed that the version of casper has
> I noticed that the version of casper has changed from 1.438build1
(when it worked) to 1.439 so I > suspect that this has caused the
failure.
Today I tested the Lubuntu Focal daily iso file with caxper version
1.441. It is still affected by this bug: There is no persistence with
the label
@C.S.Cameron,
Thanks for testing mkusb including the combo "writable & home-rw" :-)
I will wait a while to see if 'casper-rw' will be revived (alongside
'writable') in Focal, or if I have to make a check for the version of
Ubuntu or casper in my programs to select between 'casper-rw' and
Tried mkusb persistent using focal-desktop-amd64 20200223, changing
partition label from "casper-rw" to "writable". This time it worked, Now
have persistent partition labeled writable. Home stuff and installed
programs are persistent.
Create an additional partition labeled home-rw, home stuff
Made a Live drive using balenaEtcher.
Changed the label on focal-desktop-amd64 20200223 writable partition to
home-rw, resulted in a partition that was persistent for home stuff, wallpaper,
etc, but not for new installed programs, as would be expected for a home-rw
partition.
Made a persistent
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: casper (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
No I don't know how to make changes to the initramfs in a live system. I
have done it in an installed system long ago, and can follow
instructions, at least when I am not too tired :-P
So that is one possibility.
The other one is that you install and use mkusb-plug according to this
link (either
So it seems to me that the problem for the community flavours is the
label. The are not accepting the old casper-rw. By the way, what about
home-rw. Will it be recognized by this new version?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
and a file corresponding to the file in comment #2
** Attachment added: "lubuntu-2020-02-17-18-40-46-00_label-writable_works.txt"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5329099/+files/lubuntu-2020-02-17-18-40-46-00_label-writable_works.txt
--
You received
Sorry for the misunderstanding alias careless reading of your
instructions. I got it now, and Lubuntu works, when I modified the label
to 'writable' (and kept the boot option persistent). To make things
complete I will give you the log file for this case too.
** Attachment added: "casper.log2"
"Warning: Unable to find the persistent medium" is the message
indicating failure.
Do you know how to make changes to the initramfs? (I know it's not the
simplest procedure)
If you do, can you insert "ls -l /dev/disk/by-label/" just above the "if
[ ! -e "/dev/disk/by-label/${root_persistence}" ]
and a file corresponding to the file in comment #2
** Attachment added: "lubuntu-2020-02-17-18-40-46-00.txt"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5329097/+files/lubuntu-2020-02-17-18-40-46-00.txt
--
You received this bug notification because you are a
Here is the logfile for the boot options writable and verbose (Lubuntu
still failing). Do you want results from the working Ubuntu with the
same date? That way we might help the developers of Lubuntu and Xubuntu
(and maybe also the other community flavours, that I have not tested).
** Attachment
The Lubuntu iso file dated 2020-02-17 17:40 fails too. I added
casper.log from this one, with the boot options persistent and verbose.
The live drive is still the same in my Toshiba laptop, where I run the
tests: /dev/sdc.
** Attachment added: "casper.log"
I bet it's a race and sometimes it works and sometimes it doesn't with
the new casper (which of course can drive anyone trying to figure out
what is going on crazy)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Strange results from the continued testing:
The Xubuntu iso file dated 2020-02-17 01:04 fails too (like the
Lubuntu iso filefrom Febr.16)
The Ubuntu iso file dated 2020-02-1707:50 succeeds (there is
persistence with this method)
Lubuntu is updated:
The Lubuntu iso file dated 2020-02-17
Hmm. You're almost certainly right that it was the casper upload that
caused this.
I changed casper so that it creates a filesystem with the label
"writable" but it should still mount a pre-existing filesystem with
label "casper-rw" (and there are autopkgtests that it does this). There
could be a
I add a couplt of text files with output explaining what is different
between the working version and the no longer working version of Lubuntu
Focal Fossa. First the working one from Febr.12.
** Attachment added: "lubuntu-2020-02-12-17-00-33-00-persistent-live.txt"
And then the no longer working version from Febr.16
** Attachment added: "lubuntu-2020-02-16-17-16-24-00-not-persistent-live.txt"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5329077/+files/lubuntu-2020-02-16-17-16-24-00-not-persistent-live.txt
--
You received
79 matches
Mail list logo
